Open Bug 1394448 Opened 7 years ago Updated 1 year ago

Cannot install Addon with privacy.resistFingerprinting==true

Categories

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

Product:
Core
Component:
DOM: Security
Version:
57 Branch
Type:
defect

Tracking

()

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

People

(Reporter: leifeld, Unassigned)

References

(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: 7 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: 7 years ago → 7 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
status-firefox55: --- → unaffected
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox-esr52: --- → unaffected
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.
Blocks: uplift_tor_fingerprinting
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-firefox56: affected → fix-optional
status-firefox57: affected → fix-optional
Flags: needinfo?(amckay)
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]
Depends on: 1404017
P2 based on this one being pretty bad.
Priority: P3 → P2
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.
Blocks: fingerprinting-breakage
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]
Priority: P2 → P3

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.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 10 votes.
:freddy, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(fbraun)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(fbraun)
You need to log in before you can comment on or make changes to this bug.