1394448 - Cannot install Addon with privacy.resistFingerprinting==true

Status: NEW

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

Description

[leifeld]

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.

Comment 1

[leifeld]

I run the current Firefox Nightly with only privacy.resistFingerprinting set to true.

Comment 2

[Kohei Yoshino [:kohei]]

Sorry, but Firefox 50 is no longer supported.

Comment 3

[leifeld]

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.

Comment 4

[Cosmin Muntean [:cmuntean], Ecosystem QA]

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?

Comment 5

[leifeld]

Apparently I have looked at the wrong add-ons.

Comment 6

[Thomas Ludwig]

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

Comment 7

[Cosmin Muntean [:cmuntean], Ecosystem QA]

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?

Comment 8

[Tim Huang[:timhuang]]

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.

Comment 9

[Thomas Ludwig]

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.

Comment 10

[Tom Ritter [:tjr]]

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.

Comment 11

[Panos Astithas (he/him) [:past] (please ni?)]

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?

Comment 12

[Andy McKay]

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.

Comment 13

[Stuart Colville [:muffinresearch]]

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.

Comment 14

[Tom Ritter [:tjr]]

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.

Comment 18

[Tom Ritter [:tjr]]

P2 based on this one being pretty bad.

Comment 21

[ExE Boss]

Maybe the real Firefox version information could be exposed on mozAddonManager, which is available only to AMO and Test Pilot.

Comment 22

[Tom Ritter [:tjr]]

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

Comment 23

[Matth78]

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.

Comment 24

[Thorin [:thorin]]

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

Comment 25

[Kestrel]

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

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 27

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.