1453988 - NoScript may fail to operate on Mozilla domains in Tor Browser

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement)

Description

[Tom Ritter [:tjr]]

In Bug 1384330 we introduced privacy.resistFingerprinting.block_mozAddonManager so Tor Browser could block mozAddOnManager and prevent Mozilla from being able to fingerprint users.

When we did that, we introduced a _side effect_ that Web Extensions could then inject (and possibly perform other actions?) on AMO (when they previously could not).

That Side Effect was realized at the time, but ended up being noticed and discussed in Bug 1406795. Discussion focused on the risks of the side effect and ultimately was resolved as WONTFIX.

However, the side effect could be viewed in another light (when consider Tor Browser): that the side effect was in fact intentional, because we want to allow NoScript (and/or other WebExtensions) to affect AMO and other Mozilla domains to protect the user from them.  (I haven't tested this, but I think it's correct that NoScript relied on this side effect to be able to block script execution on AMO.)


In Bug 1415644 we improved our protection from malicious Web Extensions by extending the coverage to other domains, and in the process of doing so removed the side effect where Web Extensions could affect the Mozilla domains. Removing the side effect also removed the ability for NoScript to block script execution on those domains (as I understand it.)

There is a work-around: one can clear the list of domains in the pref introduced in that bug. In Firefox, this would be a security concern - malicious web extensions should not be able to affect those domains, it's why we put the list there to begin with. 

But in Tor Browser, it may be permissible to clear the list, given Tor Browser users probably aren't/shouldn't be using Mozilla services or even installing extensions?

But it may not be okay to clear the list either, in which case we _may_ need something else?

At this point, I think this bug is in Tor's court to determine what their needs are, at which point we can prioritize things based on how urgent/complicated it is.

Comment 1

[Jonathan Kingston [:jkt] he/him]

Sorry I should have highlighted this to you :tjr.
I suspect Tor should make the pref default to empty and we don't ever expose this as an API.

Comment 2

[Thorin [:thorin]]

If I understand correctly, users would have to flip privacy.resistFingerprinting.block_mozAddonManager=true **and** edit extensions.webextensions.restrictedDomains in order to allow extensions to function on AMO - right?

Comment 3

[Tom Ritter [:tjr]]

(In reply to Simon Mainey from comment #2)
> If I understand correctly, users would have to flip
> privacy.resistFingerprinting.block_mozAddonManager=true **and** edit
> extensions.webextensions.restrictedDomains in order to allow extensions to
> function on AMO - right?

block_mozAddonManager may not be necessary anymore. I think the behavior was moved entirely to extensions.webextensions.restrictedDomains.  But I could be wrong, you might still need both.

Comment 4

[Georg Koppen]

(In reply to Simon Mainey from comment #2)
> If I understand correctly, users would have to flip
> privacy.resistFingerprinting.block_mozAddonManager=true **and** edit
> extensions.webextensions.restrictedDomains in order to allow extensions to
> function on AMO - right?

I think you are right, the IsValidHost(In reply to Jonathan Kingston [:jkt] from comment #1)
> Sorry I should have highlighted this to you :tjr.
> I suspect Tor should make the pref default to empty and we don't ever expose
> this as an API.

I fell like this might be a workaround which we are okay with while we are thinking about a better solution.

Comment 5

[Georg Koppen]

(In reply to Simon Mainey from comment #2)
> If I understand correctly, users would have to flip
> privacy.resistFingerprinting.block_mozAddonManager=true **and** edit
> extensions.webextensions.restrictedDomains in order to allow extensions to
> function on AMO - right?

You are correct. IsValidSite() ) and thus IsValidHost()) is not gone but still checked after the whitelist is consulted (in case nothing matches any entry in it).

Comment 6

[Tom Ritter [:tjr]]

Thanks Georg. Until a more concrete plan of action is needed, I'm going to WONTFIX this.

Comment 7

[Thorin [:thorin]]

FYI: upstream Tor Trac: https://trac.torproject.org/projects/tor/ticket/26114