Hi,
I propose to disable Tor Browser's automatic extension update, effectively freezing extension versions between releases. This would, among other things, get rid of a fingerprintable difference between mainline TB and TB with an immutable extensions directory, such as sandboxed-tor-browser, Split Browser for Qubes[1], or Tails[2].
(Currently, mainline TB uses extensions.update.enabled=true. Of the included extensions, HTTPS Everywhere and NoScript actually update, whereas Torbutton and TorLauncher already opt out by setting a bogus updateURL.)
So when e.g. HTTPS Everywhere at some point updates itself to a version with new rules, a website affected by the rule changes (as a first party or as a third party) can distinguish which version is active. For NoScript, fingerprinting different versions is less obvious, but probably still possible when an update breaks or fixes some content.
Downsides of disabling:
- Minor improvements to HTTPSE/NoScript take a little longer to reach the user. (If there's a _serious_ security or usability issue, the TB version would have to be bumped anyway.)
Upsides:
- More uniform fingerprint for mainline and immutable TB - More reproducible environment for bug reports - Not affected by vulnerabilities in the extension updater - Slightly reduced exit traffic :)
Rusty
1. https://github.com/rustybird/qubes-split-browser 2. Although Tails can of course be distinguished by its ad blocker.
Rusty Bird:
Hi,
I propose to disable Tor Browser's automatic extension update, effectively freezing extension versions between releases. This would, among other things, get rid of a fingerprintable difference between mainline TB and TB with an immutable extensions directory, such as sandboxed-tor-browser, Split Browser for Qubes[1], or Tails[2].
(Currently, mainline TB uses extensions.update.enabled=true. Of the included extensions, HTTPS Everywhere and NoScript actually update, whereas Torbutton and TorLauncher already opt out by setting a bogus updateURL.)
So when e.g. HTTPS Everywhere at some point updates itself to a version with new rules, a website affected by the rule changes (as a first party or as a third party) can distinguish which version is active. For NoScript, fingerprinting different versions is less obvious, but probably still possible when an update breaks or fixes some content.
Downsides of disabling:
- Minor improvements to HTTPSE/NoScript take a little longer to reach the user. (If there's a _serious_ security or usability issue, the TB version would have to be bumped anyway.)
Upsides:
- More uniform fingerprint for mainline and immutable TB
- More reproducible environment for bug reports
- Not affected by vulnerabilities in the extension updater
- Slightly reduced exit traffic :)
We won't disable extension updates by flipping some preference in Tor Browser. Users who install extensions which we don't ship (even though this is strongly discouraged) should get updates. However, it is planned at least since the AMO pinning fiasco we witnessed last year (see #20146) that we essentially prevent all extensions *we* ship from auto-updating. We'll start with doing so for HTTPS-Everywhere (#10394) which is currently blocked on HTTPS-Everywhere getting the ruleset updates disentangled from the extension updates. Once we are done with HTTPS-Everywhere and got some experience what this means for our releases we'll do the same with NoScript.
Georg
On Fri, 21 Apr 2017 09:51:00 +0000 Georg Koppen gk@torproject.org wrote:
We won't disable extension updates by flipping some preference in Tor Browser. Users who install extensions which we don't ship (even though this is strongly discouraged) should get updates. However, it is planned at least since the AMO pinning fiasco we witnessed last year (see #20146) that we essentially prevent all extensions *we* ship from auto-updating. We'll start with doing so for HTTPS-Everywhere (#10394) which is currently blocked on HTTPS-Everywhere getting the ruleset updates disentangled from the extension updates. Once we are done with HTTPS-Everywhere and got some experience what this means for our releases we'll do the same with NoScript.
The sandbox has a different threat model than Tor Browser does, and I don't particularly see a need for behavior to be consistent.
In the future, after none of the built in addons are auto-updated, I may consider re-enabling the addon updater depending on how the user configures the extension directory (if it's read-only, there's no point in doing checks, obviously).
Regards,
Georg Koppen:
We won't disable extension updates by flipping some preference in Tor Browser. Users who install extensions which we don't ship (even though this is strongly discouraged) should get updates.
Oh right, my bad for not thinking of that. It makes extensions.update.enabled=false a non-starter, for sure.
However, it is planned at least since the AMO pinning fiasco we witnessed last year (see #20146) that we essentially prevent all extensions *we* ship from auto-updating.
Even better!
We'll start with doing so for HTTPS-Everywhere (#10394) which is currently blocked on HTTPS-Everywhere getting the ruleset updates disentangled from the extension updates. Once we are done with HTTPS-Everywhere and got some experience what this means for our releases we'll do the same with NoScript.
Thanks for the pointer to #10394.
Separate ruleset updates would be #2161, "Allow subscription to external rule feeds"? Have you considered punting on that... I'm obviously biased because my niche use case is a completely stateless Tor Browser, and ruleset changes between releases would mean I'd have to write yet another standalone updater (welp) to avoid the fingerprinting issue. But the ticket also hasn't been modified in 3 years.
Rusty
Rusty Bird:
Georg Koppen:
We won't disable extension updates by flipping some preference in Tor Browser. Users who install extensions which we don't ship (even though this is strongly discouraged) should get updates.
Oh right, my bad for not thinking of that. It makes extensions.update.enabled=false a non-starter, for sure.
However, it is planned at least since the AMO pinning fiasco we witnessed last year (see #20146) that we essentially prevent all extensions *we* ship from auto-updating.
Even better!
We'll start with doing so for HTTPS-Everywhere (#10394) which is currently blocked on HTTPS-Everywhere getting the ruleset updates disentangled from the extension updates. Once we are done with HTTPS-Everywhere and got some experience what this means for our releases we'll do the same with NoScript.
Thanks for the pointer to #10394.
Separate ruleset updates would be #2161, "Allow subscription to external rule feeds"? Have you considered punting on that... I'm obviously biased because my niche use case is a completely stateless Tor Browser, and ruleset changes between releases would mean I'd have to write yet another standalone updater (welp) to avoid the fingerprinting issue. But the ticket also hasn't been modified in 3 years.
So, I think I am not a fan of having the option to subscribe to several external rule feeds. What is going to happen, though, is something outlined in https://trac.torproject.org/projects/tor/ticket/2161#comment:5. However, I think having an option to disable the ruleset updates relying only on the updates that happen via new HTTPS-Everywhere releases does not seem to be unreasonable to me (for a bunch of use-cases). I'll bring that up with the EFF folks and will argue for adding such an option (if it is not already implemented).
Georg
-
Georg Koppen -
Rusty Bird -
Yawning Angel