Open Bug 1450398 Opened 2 years ago Updated 25 days ago

Resist Fingerprinting Mode should allow finer control of applicability

Categories

(Core :: Security, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: tjr, Unassigned)

References

(Depends on 4 open bugs)

Details

(Whiteboard: [fingerprinting][fp-triaged])

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?)
Flags: needinfo?(tanvi)
Flags: needinfo?(ckerschb)
(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...
(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.
(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.
(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
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
Flags: needinfo?(ckerschb)
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.
Flags: needinfo?(tanvi)
Depends on: 1453916
Product: Toolkit → WebExtensions
Also see Bug 1222285
^^ edit: also see https://bugzilla.mozilla.org/show_bug.cgi?id=1222285#c76 : keyboard spoof affects extensions
No longer blocks: uplift_tor_fingerprinting
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
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.

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.
Summary: Resist Fingerprinting Mode should not affect Web Extensions → Resist Fingerprinting Mode should allow finer control of applicability

Yes, that sounds much better

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

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

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.

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

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.

(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/

(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.

Depends on: 1635603
Component: General → Security
Product: WebExtensions → Core
Depends on: 1588548
You need to log in before you can comment on or make changes to this bug.