Opened 9 months ago

Last modified 6 months ago

#31582 new enhancement

Consider disabling AMO search field in add-ons dialog

Reported by: JeremyRand Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The Tor developers advise against installing extensions from AMO, due to potential anonymity risks. Unfortunately, end users don't always listen to this advice. It might be a good idea for Tor Browser to consider disabling the AMO search field in the add-ons dialog, which would make it somewhat less easy for users to shoot themselves in the foot. This behavior could be controlled by an about:config pref, so that the few users who actually need to install AMO add-ons can still get the old behavior back. (Making it controlled by a pref would also make it possible to upstream the patch to Firefox.)

A side benefit of this change (not related to anonymity) is that Tor Browser's status in terms of the GNU FSDG is borderline, because AMO contains non-free add-ons. Removing the AMO search field by default would make Tor Browser compliant with the GNU FSDG, which would enable FSF-endorsed distros to distribute Tor Browser.

Because of the relevance to GNU FSDG, GNU IceCat actually already carries a patch for this. See https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat?id=6634ee332979f7a78b11cbf09a77364143a981ed#n532 . This might be a good starting point for a proper patch that is controlled by a pref and would therefore be upstreamable to Firefox (thus benefiting both Tor Browser and GNU IceCat).

Child Tickets

Change History (4)

comment:1 Changed 9 months ago by cypherpunks

I believe this has already been proposed in another ticket, though I can't find it now.

comment:2 in reply to:  1 Changed 9 months ago by gk

Replying to cypherpunks:

I believe this has already been proposed in another ticket, though I can't find it now.

I was under the same impression but could not find it either. I am not sure about disabling the field yet. I wonder whether we should instead try the warning approach (#30032).

Last edited 9 months ago by gk (previous) (diff)

comment:3 Changed 9 months ago by cypherpunks

BTW don't forget #19508 ;)

comment:4 Changed 6 months ago by GNUtoo

Hi,

Freedom and privacy are often deeply related to each other.
For instance we can see here that nonfree addons conflict with both users freedom and privacy.

For users of fully free GNU/Linux distributions and device manufacturers like puri.sm privacy is also very important.
The GNU FSDG (https://www.gnu.org/distros/free-system-distribution-guidelines.html) are guidelines that fully free distributions approved by the FSF have to follow.

The nonfree addon repository in the tor-browser is in conflict with such guidelines. This is why the tor-browser installer is not packaged in any of theses distributions. The tor-browser installer has even been removed from PureOS for this reason. This is really problematic because users also use such distributions for privacy reasons, and making users choose between freedom and privacy is not a good idea.

One way to deal with that from our side would be to include a patched version of the tor-browser in such distributions with the add-on settings being changed.

However if we choose to do it in this way we would need a way to make sure that the tor-browser shipped in such distributions cannot be distinguished (by a website or the network) from either the stock tor-browser or the one used in Tails (depending on if we want an add blocker or not). If there is a way to do that (by running tests or something like that) it would be good enough for us as we care less about reproducible builds.

Is something like panopticlick.eff.org a good enough test to make sure of that?

Another way that would permit such distributions to package the tor-browser or the tor-browser installer would be to make sure that the tor-browser add-on manager doesn't point to nonfree addons, either by disabling it or pointing to a repository that only has free addons.

Removing the add-on manager would also make things more clear for end users as having a warning would probably end up providing conflicting information to users. For instance for the fullscreen feature, the tor-browser now makes sure that users are still protected even if it is fullscreen.

However on another hand this would probably create issues for users that depend on specific addons. I've no idea if it's possible to get more information on what would make the most sense for the tor-browser project or what its users are expecting or how much they understand the consequences of installing add-ons.

For instance for the fullscreen mode I was unaware that it was also possible to get the information through CSS when using the safest mode, despite knowing about the fingerprinting techniques and how tor works in more details that what is usually explained when presenting it.

Do you have some pointers on what would be the best way to advance on that issue?

Denis.

Note: See TracTickets for help on using tickets.