Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-09T17:31:09Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17569Add uBlock Origin to the Tor Browser2024-03-09T17:31:09ZJesse VictorsAdd uBlock Origin to the Tor BrowserI suggest that we add Ublock Origin to the Tor Browser. Ublock Origin has the following advantages:
1. FOSS under GPL3. See https://github.com/gorhill/uBlock
2. It is actively maintained and very popular.
3. It's designed to be efficient...I suggest that we add Ublock Origin to the Tor Browser. Ublock Origin has the following advantages:
1. FOSS under GPL3. See https://github.com/gorhill/uBlock
2. It is actively maintained and very popular.
3. It's designed to be efficient on CPU and memory. See https://github.com/gorhill/uBlock#performance
From https://github.com/gorhill/uBlock#philosophy:
> uBlock Origin is not an ad blocker; it's a general-purpose blocker. Furthermore, advanced mode allows uBlock₀ to work in default-deny mode, which mode will cause all 3rd-party network requests to be blocked by default, unless allowed by the user.
Its behavior is governed through filter lists, which are maintained by Adblock Plus, Disconnect, the community, or other sources. Users can control which lists are downloaded and most are fetched through HTTPS.
I have read through https://www.torproject.org/projects/torbrowser/design/#philosophy, but this was written several years ago and I believe that the landscape has changed and that it's time to revisit those assumptions. Arguments include:
1. Default denial of cross-site (3rd party) requests, unless allowed by the users. This eliminates CSRFs and prevents contact with ad networks and trackers in the first place. This supplements browser security by prevent ad networks from tracking users across a browser session.
2. If all users use Ublock Origin, then everyone has the same fingerprint.
3. Adblockers are now relatively common by tech-savvy users, to the point where they now consider webpages to be broken if ads get in their way. The existence of ads may drive a user to install an insecure adblocker or to use their native non-Tor browser.
4. Ublock Origin would save significant bandwidth, reducing the load on the Tor network and increasing the responsiveness of webpages in the Tor Browser.
<n8fr8> might be good to revisit these assumptions, but make sure to read on in the design document to get the full understanding
<helix> I wonder how many people install adblockers anyway. I have like 4 extra extensions for ad/tracking blocking
<n8fr8> true that
<helix> my memory was fuzzy but I recall there also being some concern that blocking ads might increase sites' contempt towards tor users, but this was like 2011-2012 and the situation was quite different
<nickm> It seems like it follows some kind of design antipattern to me; "Assuming that we deliver security with X, Y adds no additional security. Therefore, not Y." then again, I am not a TB person and do not want to step on their toes here
<n8fr8> the world has changed wrt to ad blockers being seen as anti-social... Apple now supports them after all.
<kernelcorn> helix: so many non-Tor users use adblockers that I doubt that Tor users would make a significant impact
<helix> kernelcorn: I agree now - I'm saying that the timeframe in which that decision was made had a different landscape
<helix> I think it's probably worth revisiting the topic to see if it's still true
Ticket legacy/trac#10914 is related.richardrichard2023-11-15https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25555Reimplement Optimistic SOCKS feature2024-02-27T10:54:54ZGeorg KoppenReimplement Optimistic SOCKS featureWe had to rip out the Optimistic SOCKS feature to get Moat working in Tor Browser (see: legacy/trac#24432) but we want it back for performance reasonsWe had to rip out the Optimistic SOCKS feature to get Moat working in Tor Browser (see: legacy/trac#24432) but we want it back for performance reasonshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30939Use Firefox's Tracking Protection as a means for performance improvements2023-03-03T08:48:30ZGeorg KoppenUse Firefox's Tracking Protection as a means for performance improvementsWhen improving browser performance one of the low-hanging fruits we could think about is using at least some of the Enhanced Tracking Protection (ETP) feature for that purpose. This ticket is the parent ticket to track all the involved w...When improving browser performance one of the low-hanging fruits we could think about is using at least some of the Enhanced Tracking Protection (ETP) feature for that purpose. This ticket is the parent ticket to track all the involved work.
There are a number of questions involved that we need to discuss and decide how to proceed (and probably more than I came up with below):
a) Do we want to use the same message and UI of ETP as it is shipped right now in Firefox?
b) Do we want to enable the same lists as Mozilla is doing in the respective browsing modes?
c) Do we want to use the same list retrieval mechanism as Mozilla (using the safebrowsing protocol)?
d) Do we want to host the tracking protection lists ourselves?
e) Does the work in this ticket (and child tickets) is our answer to "ship an ad blocker" in Tor Browser? Or do we feel the need to still ship another blocking tool on top of ETP?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30977Make it possible to measure Tor performance while doing Tor Browser updates/u...2023-01-05T17:34:11ZGeorg KoppenMake it possible to measure Tor performance while doing Tor Browser updates/update pingsWhile being at All Hands ekr had the idea that we could make it possible to measure Tor performance when doing update pings and downloading updates. The idea is _not_ to send the data somewhere, rather being able to measure the time the ...While being at All Hands ekr had the idea that we could make it possible to measure Tor performance when doing update pings and downloading updates. The idea is _not_ to send the data somewhere, rather being able to measure the time the ping/updates take if one wants to look at that. We could emit a log message with the time it took for those actions and whether errors occurred (that e.g. led to retrying the whole thing).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32759Review Tor Browser prefs for performance improvements2023-08-22T22:05:58ZGeorg KoppenReview Tor Browser prefs for performance improvementsWe should go over the Firefox prefs and review them for performance impact (inspired by legacy/trac#3978). We might have some knobs that allow us to get the user some perceived performance improvements without sacrificing all the other p...We should go over the Firefox prefs and review them for performance impact (inspired by legacy/trac#3978). We might have some knobs that allow us to get the user some perceived performance improvements without sacrificing all the other properties Tor Browser provides.Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41392Update network.http.htp2.* settings as appropriate in 001-tor-browser.js for ...2023-05-31T18:44:10ZrichardUpdate network.http.htp2.* settings as appropriate in 001-tor-browser.js for better user experience.Following the fix for https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27128 we should spend some effort to fully understand and test how each of the http2 knobs work and interact with network conditions with higher-la...Following the fix for https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27128 we should spend some effort to fully understand and test how each of the http2 knobs work and interact with network conditions with higher-latency and slower speeds then perhaps expected by Mozilla engineers.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41397Re-enable tab unloading for private browsing tabs2023-01-05T16:17:30ZrichardRe-enable tab unloading for private browsing tabsThe tab unloading feature was disabled in Firefox because it caused forced restarts after updates ( https://bugzilla.mozilla.org/show_bug.cgi?id=1751366 ). We only updates after Tor Browser is restarted by the user, so we may not be affe...The tab unloading feature was disabled in Firefox because it caused forced restarts after updates ( https://bugzilla.mozilla.org/show_bug.cgi?id=1751366 ). We only updates after Tor Browser is restarted by the user, so we may not be affected by this bug and may benefit from the perf improvements when Tor Browser is under memory pressure.
In 12.5 alpha series we should try reverting this patch and enabling tab unloading and see if this breaks anything.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41963builds: improve benchmarking2023-08-22T17:03:52ZThorinbuilds: improve benchmarkingspun off from #32759 ... so (windows) annecdata benchmarking indicates several things
**speedometer**
- TB/MB are consistently operating at around 2/3rds of ESR
- uBO affects perf at ~5%
- which is not an issue and is a symptom more ...spun off from #32759 ... so (windows) annecdata benchmarking indicates several things
**speedometer**
- TB/MB are consistently operating at around 2/3rds of ESR
- uBO affects perf at ~5%
- which is not an issue and is a symptom more about how the test is run than real-world? IDK
- uBO will be in TB at some stage, and the benefits (less network fetches etc) outweigh any cons IMO
- @pierov mentioned reproducible builds, PGO, LTO and I mentioned mingw - cc @fabrizio
- I will update jetstream and motionmark data after I test them
- needs labels and/or moving to appropriate repo cc @richard
**jetstream**
- about an 8% hit: is this primarily due to API/pref flips?
- NI (well, I have ideas, but not important) why gecko "regressed": TB10 vs ESR78 results are legit
**motionmark** (when I add them)
- sizes
- `1000x1000` = small screen | `1400x900` and `1400x1000` = medium screen
- will use medium screen across all tests
- since RFP is disabled
- IDK how that affects realworld results (e.g. non 60FPS hardware)
- results seems to fluxuate a lot between releases
- also IDK if this test is relevant: e.g. the perf hit in FF118 looks huge, but then read [1848050#c2](https://bugzilla.mozilla.org/show_bug.cgi?id=1848050#c2)
<details><summary>thorin's hardware</summary><p>
- OS: Windows 11 Pro 64-bit
- CPU: AMD K19 (x12)
- RAM: 32.0GB Dual-Channel DDR4 @ 1598MHz
- Motherboard: Gigabyte Technology Co. Ltd. B550M DS3H AC (AM4)
- Graphics: 4095MB NVIDIA GeForce RTX 3060 (ASUStek Computer Inc)
</p></details>
<details><summary>methods/notes</summary><p>
- https://browserbench.org/
- no extensions (e.g. uBO impacts at least speedometer by ~5+%)
- no RFP (to get accurate perf)
- new (+ sanitized) browser session for each test (S, J, M)
- speedometer: two runs each test (using `test again`, i.e in same tab), took least ± (standard deviation?)
- LW = librewolf, WF = waterfox, AF = arkenfox
- All FF's except Beta and Nightly are portable versions (portable versions use mozilla's binaries)
- EDIT: redid FF tests, using PB windows, vs TB/MB
</p></details>
<details><summary>TB/MB results</summary><p>
```
PB windows
S (2.1) J (2.1) M (1.2) medium screen
FF115 239 ± 4.5 156 953
ESR115mingw 184 ± 2.0 150
TB13.0a 155 ± 1.9 144 939
--- ---
TB 65% 92%
ESR102.14 181 ± 3.4 135 874
TB12.5.2 114 ± 1.3 114 605 (418 with RFP)
MB12.5.1 115 ± 1.9 117
MB12.5.1+uBO 106 ± 3.1 114
--- ---
TB/MB 63% 85%
MB+uBO 58% 85%
ESR91.13 158 ± 4.4 106
TB11.5.8 104 ± 2.4 98
--- ---
TB 66% 92%
ESR78.15 128 ± 3.5 124
TB10.5.10 91 ± 1.1 114
--- ---
TB 71% 92%
```
</p></details>
<details><summary>FF/fork/other results</summary><p>
```
non-PB windows
S (2.1) J (2.1) M (1.2) medium screen
Chrome 115 291 ± 5.4 239 1795
Edge 115 287 ± 3.2 237 1576
Opera 114 247 ± 3.7 230 1573
FF118 (N) 267 ± 3.9 175 1203 (bugzilla 1848050#c2)
FF117 (D) 272 ± 1.2 161 921
FF117 (B) 266 ± 4.7 163 990
FF116 244 ± 3.6 157 925
FF116 (AF) 239 ± 4.0 158 936
FF116 (LW) 181 ± 2.5 139 853 (762 with RFP)
--- ---
LW 74% 89%
FF115 240 ± 2.3 154 953
Mercury115 234 ± 1.8 152 1002
FF114 238 ± 3.0 152 901
FF113 218 ± 3.0 149 921
FF112 211 ± 2.5 148 1007
FF111 199 ± 2.0 141 1041
FF110 197 ± 2.3 140 984
FF109 194 ± 2.3 142 979
FF108 189 ± 2.1 137 906
FF107 183 ± 2.8 124 752
FF106 176 ± 2.2 124 770
FF105 181 ± 4.1 133 916
FF104 178 ± 5.1 121 621
FF103 179 ± 4.6 120 577
FF102 179 ± 2.9 129 761
FF102 (WF) 143 ± 2.9 123 566
--- ---
WF 80% n/a
---
OMG... LMFAO
WF Classic 90 ± 1.5 93 460
Basilisk 43 ± 1.2 66 396
Palemoon 37 ± 1.2 62 380
```
</p></details>