== Proposal == I would like to propose a boolean pref, "privacy.resistFingerprinting.pbm". When true, this pref would enable Fingerprinting Resistance in Private Browsing windows only. privacy.resistFingerprinting.pbm: * true: All Private Browsing windows resist fingerprinting; all non-PB windows do not. * false (default): Normal behavior == Background == Firefox currently has a boolean pref called "privacy.resistFingerprinting". The Fingerprinting Resistance mechanism spoofs or hides numerous characteristics of the user's system from content pages, such as screen dimensions, installed fonts, etc. privacy.resistFingerprinting has two values: * true: All content pages resist fingerprinting * false (default): Normal behavior == Purpose == Users expect Private Browsing windows should protect their privacy. According to a recent survey by DuckDuckGo (https://duckduckgo.com/download/Private_Browsing.pdf): """ • 41.0 ±2.5% believe that Private Browsing “Prevents websites from tracking me.” • 39.1 ±2.6% believe that Private Browsing “Prevents ads from tracking me.” """ Providing an option to enable Fingerprinting Resistance in Private Browsing windows will help to meet these user expectations. In the future (not in this ticket), we might consider enabling the proposed pref by default. (See also bug 1397264, where I proposed a pref to lets user enable First-Party Isolation in Private Browsing windows.)
Another alternative would be to convert privacy.resistFingerprinting to an integer. Then the integer could have three values: 0: Fingerprinting Resistance off 1: Fingerprinting Resistance on in all windows 2: Fingerprinting Resistance on in Private-Browsing windows only
I favor the integer approach (and I think this should be the same for the FPI ticket: Bug 1397624)
(In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from comment #0) > (See also bug 1397264, where I proposed a pref to lets user enable > First-Party Isolation in Private Browsing windows.) A typo here. Arthur meant bug 1397624.
(In reply to Simon Mainey from comment #2) > I favor the integer approach (and I think this should be the same for the > FPI ticket: Bug 1397624) +1 for the integer approach. One less preference means less complexity to me. For example, we don't have to deal with the case when "privacy.resistFingerprinting" and "privacy.resistFingerprinting.pbm" are both true.
The next step for this bug is to investigate the callsites of ShouldResistFingerprinting and make a list of the sites where adding OriginAttributes into the callsite will be difficult (because it is not readily available.) This investigation will also inform us of the feasibility of a "Disable ResistFingerprinting for this Origin" feature. Hopefully of the difficult callsites, there is some handy boolean hanging around that tells us if we are in a Private Browsing window or not. (That won't solve the 'for this Origin' problem but let's get the list and evaluate it from there.) I'm passing this bug to Tim for now for the investigation, and when he's able to complete that we can unassign or reassign it.
Assignee: nobody → tihuang
Priority: -- → P2
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp-triaged]
Whiteboard: [tor][fingerprinting][fp-triaged] → [tor][fingerprinting]
No longer blocks: uplift_tor_fingerprinting
Whiteboard: [tor][fingerprinting] → [fingerprinting][fp-triaged]
You need to log in before you can comment on or make changes to this bug.