Fantastic! Thank you so much.
Hi! Is query parameter stripping going to be introduced in Tor Browser? I see it enabled in Mullvad Browser, but not Tor Browser: https://privacytests.org/
See also: tor-browser#41092 (closed)
Hi! At Brave we have been investigating a side-channel cross-site tracking attack that is a common privacy issue for many browsers. In short, some global resource pools can be abused to send short messages between different websites. In Tor Browser (and Firefox) we were able to show that the WebSocket resource pool, which has a maximum size of 200, can be successfully used to send a 35-bit cross-site messages in 7 seconds. (A Web Worker pool attack also works in Firefox, but I wasn't able to get it to work in Tor Browser for unclear reasons.)
Brave's approach to protecting against pool party attacks is to partition the resource pool by eTLD+1. Full details are in the draft paper: https://arxiv.org/pdf/2112.06324.pdf. We also reported this bug at Firefox here: https://bugzilla.mozilla.org/show_bug.cgi?id=1730797
Of course I'll be very happy to discuss the attack and mitigations.
I wonder if it would be better to simply merge the patch into the codebase? I haven't looked at it for many months, but I imagine it would be harmless to the functionality for non-namecoin websites. Merging would make maintenance easier, I expect. Let me know what you think!
Awesome! Thanks all! 🧅
Results from https://privacytests.org/android.html indicate that the Tor Browser Android favicon cache is not partitioned by first-party domain. That means that the favicon cache can be used to track users between sites. (This leak does not exist in Tor Browser desktop.)
Now that HTTPS-Only Mode is enabled by default in Tor Browser Desktop (#19850), it would be good to enable it by default in Tor Browser Android as well, to protect users against SSL strip attacks by hostile exit nodes. Note the feature is already enabled by default in Firefox Focus Android and Mull Browser Android (see https://privacytests.org/android.html), so I expect it should be fairly straightforward to enable this setting.
See this thread where a user reports seeing trackers in Tor Browser Android: https://twitter.com/BillSte51511520/status/1554648190560964608
See the page here: https://reports.exodus-privacy.eu.org/en/reports/177119/#trackers
While I understand that the team already confirmed in #40009 and child tickets that these trackers have been disabled, I think it would still be better to remove these code modules from the build altogether. There are a couple of reasons:
URL query parameters (aka URL search parameters) are a major vector for cross-site tracking. They comprise what is perhaps the most significant category of cross-site tracking vector that remains unblocked in Tor Browser.
Fortunately, Firefox has announced that they will be enabling tracking query parameter stripping for Strict mode and Private mode. (As of Firefox 103, this protection seems to be enabled in Strict Mode only in Release.) It would be great if Firefox's feature can be enabled in Tor Browser and expanded to cover more parameters that Firefox doesn't, including Google's gclid and dclid and Microsoft's msclkid. For a longer list of candidate parameters, see https://privacytests.org/
Two related mitigations:
I think I meant Web Workers. If a Worker spawns another Worker (as mentioned in https://developer.mozilla.org/en-US/docs/Web/API/Worker).
It would be good to check if the first-party domain partitioning (i.e., OriginAttibutes) correctly propagates from the top-level page to a third-party iframe, to a web worker spawned by the iframe, to a second web worker spawned by the first web worker.
We would need to check something stateful that is supposed to be partitioned, such as IndexedDB.
Hi everyone! I thought I would chime in to make the case for enabling HTTPS-Only Mode in Tor Browser as soon as possible.
HTTPS-Only Mode protects users from being navigated to an insecure website or loading insecure subresources of any kind, similar to HTTPS Everywhere's EASE mode. Nusenu's alarming reports (part i, part ii), of large numbers of Tor exit relays potentially mounting SSL strip attacks on users and stealing cryptocurrency, suggest to me that insecure HTTP is very dangerous for Tor Browser users. For that reason I think that enabling HTTPS-Only Mode in Tor Browser is urgent. The question is: are there any blockers to shipping HTTPS-Only Mode on by default? Here are some observations:
So my suggestion is to set the pref dom.security.https_only_mode
to true in Tor Browser alpha as soon as possible, to validate the HTTPS-Only Mode experience with the alpha user base.
I hope some of these comments are useful! I'm happy to discuss any of them further.
This description sounds like an inducible proxy leak to me:
https://blog.mozilla.org/security/2021/10/25/securing-the-proxy-api-for-firefox-add-ons/
It sounds like all an attacker needs to do is block a proxy connection and the browser will bypass the proxy. It seems important to make sure that this failover functionality is disabled in Tor Browser.
See https://fingerprintjs.com/blog/external-protocol-flooding/ for a description of the attack. I haven't investigated if this actually works in Tor Browser, but looks like a good thing to examine. Firefox bug reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=1711084