Open Bug 1394448 Opened 2 years ago Updated 5 months ago

Cannot install Addon with privacy.resistFingerprinting==true

Categories

(Core :: DOM: Security, defect, P3)

57 Branch
defect

Tracking

()

Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- fix-optional
firefox57 --- fix-optional

People

(Reporter: leifeld, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [fp-triaged][domsecurity-backlog1][fingerprinting])

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20100101

Steps to reproduce:

I set privacy.resistFingerprinting to true and tried to install an Addon.


Actual results:

Either the plugin is too old (this is expected) or I cannot download it because addons.mozilla.org my Firefox is too old for Addons with Webextentions.


Expected results:

Either I should be able to install an Addon on addons.mozilla.org if the Firefox version is 50 or the Firefox version with privacy.resistFingerprinting should be increased.
I run the current Firefox Nightly with only privacy.resistFingerprinting set to true.
Sorry, but Firefox 50 is no longer supported.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
I run Firefox Nightly, 57.0a1 (2017-08-28) (64-Bit).
privacy.resistFingerprinting sets my User Agent to Firefox 50, this is the reason you think I run 50.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Firefox: 57.0a1, Build ID: 20170830220349

I have tried to reproduce this issue, but after I set the pref to "true" I was able to install multiple add-ons which are supported in Nightly 57.0a1. I have also installed the add-ons from "https://addons.mozilla.org/en-US/firefox/" website.

@leifeld can you please give me some examples of add-ons that you tried to Install?
Flags: needinfo?(leifeld)
Apparently I have looked at the wrong add-ons.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago2 years ago
Flags: needinfo?(leifeld)
Resolution: --- → INVALID
(In reply to Cosmin Muntean [:CosminMCG], Desktop Engineering QA from comment #4)
> 
> @leifeld can you please give me some examples of add-ons that you tried to
> Install?

That's actualy easy to test (with FF57 Nightly). 
1. Set privacy.resistFingerprinting = false and load
https://addons.mozilla.org/en-US/firefox/search/?tag=firefox57
You'll see that all add-ons are marked as compatible.
2. Set privacy.resistFingerprinting = true and reload above site. You'll see that several add-ons (like uBlock Origin) are now marked as incompatible.
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20170905220108

Thomas, thanks for your reply!

I have retested this issue and I have managed to reproduce it using the provided link. If I set the "privacy.resistFingerprinting" pref to "true" the uBlock Origin, AdBlock for Firefox, Enhancer for YouTube, and others are no longer compatible with Nightly 57.
This issue is not reproducible with Firefox 55.0.3 release. Considering this, using mozregression tool I have performed a regression. Here are the result:

Last good revision: 121b01dc9fdef56da1820520d6130913c5d4c62b
First bad revision: 5131e38858f91107d1d198ffd8a4187be1ed1a87
Pushlog: https://goo.gl/Sr7yKB

Looks like the following bug has the  changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1333651

Tim, can you please take a look at this issue? This is intended?
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(tihuang)
Keywords: regression
Resolution: INVALID → ---
When the 'privacy.resistFingerprinting' set to true, Firefox will spoof the version number down to the nearest ESR version, 52 right now, after Bug 1393283. Before that, it will be spoofed down to the nearest 10, so it will be 50. I think this version spoofing causes this problem since the AMO recognizes a spoofed version number instead of the real one. Because of it, those addons requires a higher version than ESR version will show 'incompatible'. So, I would say that the behavior is intended.
Flags: needinfo?(tihuang)
Tim, if that's what is intended it means that this switch is only useable for users who don't install any add-ons. I cannot imagine that this is the goal of implementing these Tor patches. There has to be a way to whitelist specific sites like AMO, IMO.
Component: Untriaged → DOM: Security
Priority: -- → P2
Product: Firefox → Core
Whiteboard: [tor][fingerprinting][fp-backlog]
What mechanism is AMO using to detect the browser version? Is it the navigator object or the User-Agent?

If it's the navigator object, we recently decided that the mozAddonManager object would not be disabled by resistFingerprinting, and that object is already whitelisted for AMO. So it would be a much simpler change to use an already-whitelisted object to provide a source-of-truth for AMO than to build a whitelisting mechanism into a different object that changes its functionality.
Priority: P2 → P3
Whiteboard: [tor][fingerprinting][fp-backlog] → [tor][fingerprinting][fp-backlog][domsecurity-backlog1]
Whiteboard: [tor][fingerprinting][fp-backlog][domsecurity-backlog1] → [tor][fingerprinting][fp:m4][domsecurity-backlog1]
P3 -> fix-optional for 56/57

(In reply to Tom Ritter [:tjr] from comment #10)
> What mechanism is AMO using to detect the browser version? Is it the
> navigator object or the User-Agent?
> 
> If it's the navigator object, we recently decided that the mozAddonManager
> object would not be disabled by resistFingerprinting, and that object is
> already whitelisted for AMO. So it would be a much simpler change to use an
> already-whitelisted object to provide a source-of-truth for AMO than to
> build a whitelisting mechanism into a different object that changes its
> functionality.

Perhaps Andy knows?
Status: REOPENED → NEW
At this time AMO is under going a rewrite in its front end so that we can use mozAddonsManager there, it probably makes sense for this to wait for that. But it does mean a bit more complexity on AMOs end.

Bear in mind that any other site that provides add-on installs and sniffs the user agent will have the same problem. A large number of popular add-ons are not listed on AMO (eg 1Password), so they will suffer from the same problem but will not be able to read mozAddonsManager.

Also we do expect compatability to be much less of a problem once everyone is on WebExtensions, its still possible to set strict_min_verisons, but it should be pretty rare.
Flags: needinfo?(amckay) → needinfo?(scolville)
AFAIK The browser version data relevant to add-on installation is not available via the navigator object so we are dependent on using the user-agent to know what version of the browser we are dealing with until we have a viable alternative. This would also apply for the new front-end too.

In addition to this a client-side API isn't helpful for the server-side rendering of the first request so the ideal solution would be to have the version on the server. However if this happened for every site that could potentially be its own privacy concern.
Flags: needinfo?(scolville)
We talked about this a bit in the fingerprinting meeting. 

It's not trivial, but it seems like developing a whitelist for the User-Agent would be valuable, and would fix this problem. But this is a specific instance of the generic desire to to be able to turn off anti-fingerprinting on a per-something (origin, private browsing) basis. We're thinking that passing OriginAttributes to ShouldResistFingerprinting could be the basis for this, which would allow different behavior for different containers, private browsing, origins. 

There is also the need to disable antifingerprinting for any chrome scripts/content. We should behave this way now, but it may be needed going forward for some future issue.
Whiteboard: [tor][fingerprinting][fp:m4][domsecurity-backlog1] → [tor][fingerprinting-breakage][fp:m4][domsecurity-backlog1]
Duplicate of this bug: 1417157
Duplicate of this bug: 1425859
Duplicate of this bug: 1426641
P2 based on this one being pretty bad.
Priority: P3 → P2
Duplicate of this bug: 1447579
Duplicate of this bug: 1449025
Maybe the real Firefox version information could be exposed on mozAddonManager, which is available only to AMO and Test Pilot.
(In reply to ExE Boss from comment #21)
> Maybe the real Firefox version information could be exposed on
> mozAddonManager, which is available only to AMO and Test Pilot.

Comments 10 and 13 indicate this will not be sufficient; unless something has changed recently.
Whiteboard: [tor][fingerprinting-breakage][fp:m4][domsecurity-backlog1] → [tor][fp:m4][domsecurity-backlog1]
Whiteboard: [tor][fp:m4][domsecurity-backlog1] → [tor][fp:m4][domsecurity-backlog1][fingerprinting]
No longer blocks: uplift_tor_fingerprinting
Whiteboard: [tor][fp:m4][domsecurity-backlog1][fingerprinting] → [fp-triaged][domsecurity-backlog1][fingerprinting]

With latest build (can't identify which one but june 1st 2019 is affected) it's not possible anymore to add extension from addons.mozilla.org if privacy.resistFingerprinting.block_mozAddonManager is set to true.
When clicking on "Add Button" Firefox go to a blank page. Besides add button is not switched to remove if it's an extension you have already added.

(In reply to Eriatile from comment #23)

With latest build (can't identify which one but june 1st 2019 is affected) it's not possible anymore to add extension from addons.mozilla.org if privacy.resistFingerprinting.block_mozAddonManager is set to true.
When clicking on "Add Button" Firefox go to a blank page. Besides add button is not switched to remove if it's an extension you have already added.

See bug 1384330 - privacy.resistFingerprinting.block_mozAddonManager is a hidden and undocumented pref which was added for Tor Browser. Don't use it if you don't know what you're doing.

(In reply to Eriatile from comment #23)

With latest build (can't identify which one but june 1st 2019 is affected) it's not possible anymore to add extension from addons.mozilla.org if privacy.resistFingerprinting.block_mozAddonManager is set to true.

Filed as Bug 1556655.

You need to log in before you can comment on or make changes to this bug.