1450398 - (finegrained-rfp) [meta] Resist Fingerprinting Mode should allow finer control of applicability

Status: NEW

(Core :: Security, enhancement, P3)

Description

[Tom Ritter [:tjr]]

We've got several of these bugs on file. 

Perhaps instead of patching each individual location, we should do a comprehensive solution. (And even if we did every individual location, we'd still want to use this bug to make sure we didn't miss any.)

In particular in Bug 1404017 we want to make RFP only apply to private Browsing Mode, and in Bug 1394448 we want to add an exception for version spoofing for AMO.

Christoph/Tanvi - What's the correct mechanism to use for all three use cases (detecting PBM, a WebExtension, and a particular origin)? Principle or OriginAttributes? It seems like we may need to use OA, because we need to detect Private Browsing Mode. But in Bug 1412961 we got the Add-On ID off of the Principle - does OriginAttributes.mAppId represent the same thing (whether or not we are in a Web Extension's Content Script?)

Comment 1

[Kris Maglione [:kmag]]

(In reply to Tom Ritter [:tjr] from comment #0)
> Christoph/Tanvi - What's the correct mechanism to use for all three use
> cases (detecting PBM, a WebExtension, and a particular origin)? Principle or
> OriginAttributes? It seems like we may need to use OA, because we need to
> detect Private Browsing Mode. But in Bug 1412961 we got the Add-On ID off of
> the Principle - does OriginAttributes.mAppId represent the same thing
> (whether or not we are in a Web Extension's Content Script?)

Extension contexts don't have any special origin attributes, nor should they. Their add-on ID comes directly from the principal. I thought the appId origin attribute was gone...

Comment 2

[Thorin [:thorin]]

(In reply to Tom Ritter [:tjr] from comment #0)
> We've got several of these bugs on file. 
> 
> In particular in Bug 1404017 we want to make RFP only apply to private
> Browsing Mode, and in Bug 1394448 we want to add an exception for version
> spoofing for AMO.

Don't forget Bug 1377744

> It seems like we may need to use OA, because we need to detect Private Browsing Mode.

I know that MOzilla want to trial, tweak, and enable this in the future in PB mode only, but please do not limit the extensions exemption based on PB OA. Because then normal windows running RFP will still have any issues.

Comment 3

[Tom Ritter [:tjr]]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #1)
> (In reply to Tom Ritter [:tjr] from comment #0)
> > Christoph/Tanvi - What's the correct mechanism to use for all three use
> > cases (detecting PBM, a WebExtension, and a particular origin)? Principle or
> > OriginAttributes? It seems like we may need to use OA, because we need to
> > detect Private Browsing Mode. But in Bug 1412961 we got the Add-On ID off of
> > the Principle - does OriginAttributes.mAppId represent the same thing
> > (whether or not we are in a Web Extension's Content Script?)
> 
> Extension contexts don't have any special origin attributes, nor should
> they. Their add-on ID comes directly from the principal. I thought the appId
> origin attribute was gone...


Hm. It seems like we may want to pass in a Private Browsing Mode ID from OA, and the Principle then...



(In reply to Simon Mainey from comment #2)
> I know that MOzilla want to trial, tweak, and enable this in the future in
> PB mode only, but please do not limit the extensions exemption based on PB
> OA. Because then normal windows running RFP will still have any issues.

No - Extensions should always be exempt whether they are operating in PBM mode or not or whether or not you have RFP enabled in the entire browser, or PBM only.

Comment 4

[Thorin [:thorin]]

(In reply to Tom Ritter [:tjr] from comment #3)
> No - Extensions should always be exempt whether they are operating in PBM mode or not or whether or not you have RFP enabled in the entire browser, or PBM only.

Good :) I must have misunderstood why you would want the PB OA then

Comment 5

[Christoph Kerschbaumer [:ckerschb}]

As discussed on vidyo it probably makes the most sense to convert nsContentUtils::ShouldResisterFingerPrinting() and all variations of it and have only
  nsContentUtils::ShouldResistFingerPrinting(nsILoadInfo* aLoadInfo);

Using the loadinfo we then have all the information (principal, OA) available to make a good decision. E.g. within CSP we have to do: |BasePrincipal::Cast(aRequestPrincipal)->OverridesCSP(node->NodePrincipal()| and I think we need a very similar thing within ShouldResistFingerPrinting().

I guess for the beginning we could just pass a nullptr in all the cases where we can't query a loadinfo and in those cases we just look at the pref if fingerprinting is enabled or not. Or alternatively, we create a dummyLoadinfo that contains the information needed. E.g. if you query for |secCheckLoadInfo| [1] we have done similar things for explicit content policy checks.

[1] https://dxr.mozilla.org/mozilla-central/search?q=secCheckLoadInfo&redirect=false

Comment 6

[Tanvi Vyas[:tanvi]]

To detect private browsing mode, you can use the Origin Attribute for Private Mode.  I'm not sure if we still have the private mode boolean lurking around, or if that all got cleaned up and fully converted to Origin Attributes.  The Origin Attributes are in the LoadInfo, and I agree with Christoph, that whatever you do, you should make sure you have access to the LoadInfo.  It may help you in future bugs as well.

I'm not sure how to prevent spoofing the user agent for addons.mozilla.org to install an extension.

Comment 7

[Thorin [:thorin]]

Also see Bug 1222285

Comment 8

[Thorin [:thorin]]

^^ edit: also see https://bugzilla.mozilla.org/show_bug.cgi?id=1222285#c76 : keyboard spoof affects extensions

Comment 9

[KOLANICH]

Extensions should be affected by fingerprinting-resistance techniques.
1 Content scripts should be affected the same way the pages they are related to affected.
2 Background scripts and other stuff should be affected too as own origins.
3 There should be an API and a permission to lift specific protection from each particular piece of API 0retected by RFP.

Rationale:
1 extensions can be used to implement some API not currently present in browsers, and we want to be sure that the new API doesn't leak information.
2 Placing burden of reimplementing protections on addons developers will lead to more holes because these protections won't be upgraded with browser.
3 background scripts can also leak data because of programmers errors or because that FP vector was unknown by the time the addon has been developed.

Comment 11

[Tom Ritter [:tjr]]

I'm renaming this to better reflect what we want to do here.

RFP should be able (at least at the code level; ideally exposed to the user somehow) to selectively apply to:

• WebExtensions (it should not apply to them)
• Private Browsing Mode (we should be able to turn RFP on for PBM only)
• FQDN - users should be able to exempt individual sites from RFP.

Comment 12

[u601362]

Yes, that sounds much better

Comment 13

[KOLANICH]

Here is a better idea: https://bugzilla.mozilla.org/show_bug.cgi?id=1553791

Comment 14

[u601362]

Can you explain what is better about that idea? I couldn't even see the relation to this issue here.

Comment 15

[KOLANICH]

This bug is about applying RFP selectively. That bug is about applying protections and mitigations selectively. It proposed to create a special WebExtension with a special permission. Then JavaScript code inside that extension decides what privilege should be given to each webpage for each feature it requests and in which cases. For example it can decide which RFP features apply to which page. For example it should be able to allow canvas and javascript for Firefox built-in pdf.js and deny for everything else not in whitelist (gui for it should be implemented in the extension). Something like noscript on steroids

Comment 16

[vtol]

Not sure that WX should be generally excempted from RFP since eventually accessing/manipulating the DOM.

Why introducing the idea to turn on RFP for PBM only, how does that fit into fine graining?

FQDN is a good idea/step but still does not allow much fine grain, e.g. the matter of not responding to any media@ queries denying dark theme of sites that support it. So either turn off RFP entirely to get a dark themed site displaying it or turn RFP on entirely but miss the dark theming.

Have not looked into TOR, except for glancing at its documentations, but it would seem that its code got some sort of fine grain control over RFP.

Comment 17

[u601362]

Please use the long form of the abbreviations. I cannot understand your comment.
WX=?
PBM=?
TOR=?

Comment 18

[u601362]

Test: as I searched for "resistFingerprinting" as one word and I couldn't find my own issue I hope that writing this word in a comment on this issue saves me a lot of time when trying to find this issue the next time. Sad that I can't edit the original issue.

Comment 19

[Thorin [:thorin]]

(In reply to sunrisechain from comment #17)

Please use the long form of the abbreviations. I cannot understand your comment.

WX= web extension
PBM= private browsing mode
TOR= Tor ( The Onion Router(s) ) .. TBB = Tor Browser Bundle ... TB = Tor Browser - see [1]
RFP= resistfingerprinting

[1] https://www.torproject.org/

Comment 20

[u601362]

(In reply to KOLANICH from comment #15)

This bug is about applying RFP selectively. That bug is about applying protections and mitigations selectively. It proposed to create a special WebExtension with a special permission. Then JavaScript code inside that extension decides what privilege should be given to each webpage for each feature it requests and in which cases. For example it can decide which RFP features apply to which page. For example it should be able to allow canvas and javascript for Firefox built-in pdf.js and deny for everything else not in whitelist (gui for it should be implemented in the extension). Something like noscript on steroids

I like the idea.
The only problem I see with that is that installation automation of this feature could become a bit more complex.
I would have to automate both the installation of the extension as well as it's configuration.
With the user.js file, I could just extend my existing user.js file.

Comment 22

[Jeff Ro]

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #11)

I'm renaming this to better reflect what we want to do here.

RFP should be able (at least at the code level; ideally exposed to the user somehow) to selectively apply to:

• WebExtensions (it should not apply to them)
• Private Browsing Mode (we should be able to turn RFP on for PBM only)
• FQDN - users should be able to exempt individual sites from RFP.

My particular use case:
I really need Gmail, WhatsApp Web and Todoist to have my real timezone. I love FF (esp. for its RFP features), but it's super annoying to have all timestamps shifted 6 hours.

:tjr, this sounds like a good solution. More specifically, I would propose the following ways of conditioning the application of RFP to these 3 categories:

• WebExtensions: Would it be possible to add a "No fingerprint resistance" permission for each WX?
• PBM: This can be a setting in about:config and possibly in the config interface
• FQDN: Add to the permission GUI "Enable fingerprint resistance" (options: "Use default", "Enable", "Disable")

Comment 23

[Tom Ritter [:tjr]]

Linking this comment here for reference:

Even using the inspector (with devtools.inspector.color-scheme-simulation.enabled) is overridden by privacy.resistFingerprinting.

Resist Fingerprinting should not override actions that are explicitly taken using the dev tools.

https://bugzilla.mozilla.org/show_bug.cgi?id=1535189#c19

Comment 25

[owengeorgehayes]

An option to have some sort of url exception list would be great, resistFingerPrinting completely breaks the ui of Pixiv once resistFingerPrinting is enabled you can't even open the burger menu to navigate to other parts of the website

Comment 27

[Tom S. (please needinfo tschuster)]

Seems to me like bug 1635603 implemented this at least partially?

Comment 28

[Tom Ritter [:tjr]]

Yes, Sanketh is a volunteer making progress on this incrementally - it's really exciting.

To set expectations though, this work is super confusing/seems broken right now because it only affects some and certainly not all things that RFP changes. So if you play with this you will wind up in a very weird state.

Comment 30

[Alisha Sharma]

Attachment: Bug 1450398: Apply finer-grained RFP checks to Keyboard Event r?tjr

Depends on D126165

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac146e18ce40
Apply finer-grained RFP checks to Keyboard Event r=tjr

Comment 32

[Tom Ritter [:tjr]]

Oops, I just realized that this patch was landed under this bug instead of Bug 1732578. That's alright, we can handle that, we'll just leave this open as a meta.

Comment 33

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/ac146e18ce40

Comment 34

[Ben]

Attachment: Bug 1450398 - Changed return under KeyboardEvent to access ShouldResistFingerprinting function. r?tjr

Depends on D126290

Comment 35

[Alisha Sharma]

Attachment: Bug 1450398: Cut over Hardware Concurrency to finer-grained RFP Check r?tjr

Comment 36

[Phabricator Automation]

Comment on attachment 9261586 [details]
Bug 1450398: Cut over Hardware Concurrency to finer-grained RFP Check r?tjr

Revision D137481 was moved to bug 1752907. Setting attachment 9261586 [details] to obsolete.

Comment 39

[Forest]

As someone who is impacted by the loss of dark mode when Resist Fingerprinting is enabled, I would like to get a few relevant thoughts on record.

Background:

In bug 1535189, comment 6, tjr notes, "Eventually, something will make us reconsider this position, but I don't think this one is high value enough to do so."

In bug 1535189, comment 20, Joseph Carter later points out, "this is an accessibility thing. Ask a legally blind guy who has photophobia."

I believe Mr. Carter's point has sufficient value to warrant said reconsideration.

Some people need dark mode. It's not merely a style preference, but rather the difference between reading comfortably vs. straining against an eye-watering, headache-inducing interrogation lamp, or worse. For such people (and for those who just strongly prefer dark themes) a privacy setting that breaks prefers-color-scheme is a privacy setting that will not be used. I think Firefox can do better than that.

It occurs to me that the RFP policy to block media queries was likely made with high-variance queries in mind. For example, color-index, resolution, and height have many possible values, translating into many bits of data that can contribute to a fingerprint, so disabling them in RFP mode makes sense. On the other hand, supporting prefers-color-scheme requires only two possible values; a single bit. Since it has a uniquely high impact on usability and low value to fingerprinting, I think it deserves special treatment.

Suggestion 1 (Easy): Always support prefers-color-scheme. Note that while this would split the RFP "bucket" of users into two buckets, it would also increase the total number of RFP users, further reducing this single bit's already-low value to fingerprinting.

Suggestion 2 (Hidden Option): Make prefers-color-scheme support a hidden optional setting in RFP mode. This would make RFP viable for people who need dark mode, again adding to the total number of RFP users, but without significantly reducing the number of users in the main bucket.

Suggestion 3 (Balancing): Make prefers-color-scheme support an optional setting in RFP mode, as visible or hidden as the RFP setting itself, and disabled by default. For those who do not enable it, randomly choose light or dark mode, and make it persist across sessions for UX consistency. The idea here is to allow people who need dark or light mode to have what they need, while randomly distributing people who don't care among the two buckets.

Comment 40

[Thorin [:thorin]]

Some people need dark mode

You can use a dark theme for your UI. And for web content, use an extension. This is not to belittle accessibility issue, but to show that you have options. Besides, prefers-color-scheme is not a universal solution , as it is entirely up to the website to implement. What you are after is css-colors-adjust

Also see

• https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40337
• https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41026

Comment 41

[Tom Ritter [:tjr]]

(In reply to Forest from comment #39)

As someone who is impacted by the loss of dark mode when Resist Fingerprinting is enabled, I would like to get a few relevant thoughts on record.

I appreciate your comments. I'm going to link to them in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41026 which is really the best place to advocate for this, I think. Ultimately, the RFP mode in Firefox is made for Tor and when the path forward is debatable or less-than-ideal Firefox will (unless for technical reasons) follow Tor's decision process.

Comment 42

[Forest]

(In reply to Simon Mainey from comment #40)

You can use a dark theme for your UI.

I think my comment made it clear that I was not talking about the UI.

And for web content, use an extension.

In my experience, dark mode browser extensions are hit-and-miss. They often work badly, causing various problems ranging from extreme contrast to nearly invisible page elements. They are seldom as good as site-provided dark color schemes, and they are never what the site designer intended.

Moreover, adding extensions expands the browser's attack surface, and last time I checked, each extension's presence also expanded the browser fingerprint.

prefers-color-scheme is not a universal solution , as it is entirely up to the website to implement.

Obviously, but that is irrelevant to my comments. I am not seeking a universal sledgehammer to force sites into dark mode. I simply want accessibility features not to break when privacy features are enabled, wherever possible. I believe this is achievable in this case.

(Since you mention it, though, I do implement prefers-color-scheme on my sites, and more site authors are gradually doing the same as they become aware of it and find time to adopt it. I would like my users to benefit from that work, including those who are privacy-conscious.)

What you are after is css-colors-adjust

No. Although that might be a useful tool, it is not what I am after here. See my above comments.

Comment 43

[Forest]

(In reply to Tom Ritter [:tjr] (sec-approvals paused until after release) from comment #41)

I appreciate your comments. I'm going to link to them in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41026 which is really the best place to advocate for this, I think.

Thanks, Tom. Please feel free to copy my comments from here to that issue if it helps visibility/readability.

Comment 44

[Thorin [:thorin]]

Sorry, Forest. Not here to argue :) And I'm all for increasing accessibility. Fingerprinting these suck, and I wish it wasn't so. But I do need to play devil's advocate.

I was not talking about the UI
Yup, was for other readers, and probably desirable anyway

dark mode browser extensions are hit-and-miss
Indeed, but it is a current solution that is at least universal, i.e can be applied to all pages, and allow exceptions

I still think the best way forward is to relax RFP's hold on stand-in colors, with some conditions maybe: if accessibility features are enabled?, if user selects Only with High Contrast Themes (settings>general>colors...)? But I am not an accessibility expert

I simply want accessibility features
Sure, I get that, but prefers-color-mode is not an accessibility feature IMO - it's just a feature, e.g. switch to dark mode during night-time, match system theme, etc. Standins are.

This deserves it's own ticket, with copied over relevant comments, rather than be lumped under granularity of RFP. e.g Revisit RFP accessibility locks - Forest, care to open one?

Comment 45

[Thorin [:thorin]]

clearing ni - if anything is to be done with accessibility it will need it's own ticket and someone can open one

Comment 46

[Forest]

Created bug 1777614, as requested.