Open Bug 1450398 Opened Last year Updated 2 months ago

Resist Fingerprinting Mode should not affect Web Extensions

Categories

(WebExtensions :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: tjr, Unassigned)

References

(Depends on 2 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
See Also: → 1404017
Also see Bug 1222285
^^ edit: also see https://bugzilla.mozilla.org/show_bug.cgi?id=1222285#c76 : keyboard spoof affects extensions
See Also: → 1397624, 1506947
No longer blocks: uplift_tor_fingerprinting
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
See Also: → 1394448
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.
You need to log in before you can comment on or make changes to this bug.