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/42143do something about autoconfig.js / cfg / js?2024-03-18T14:53:47ZThorindo something about autoconfig.js / cfg / js?e.g. https://github.com/mullvad/mullvad-browser/issues/137#issuecomment-1742215179
Things
- tweak about:config interstitial
- lock prefs where appropriate
- do something with user.js?
- do something with userChrome/content? (there is a ...e.g. https://github.com/mullvad/mullvad-browser/issues/137#issuecomment-1742215179
Things
- tweak about:config interstitial
- lock prefs where appropriate
- do something with user.js?
- do something with userChrome/content? (there is a pref we can lock)
- UX stuff (education, remove dead UI)
and now do something with autoconfig.js? I don't think we have an issue for this, so here it is. Maybe we can make this a meta. As for the autoconfig, I think tom had/has an issue on this upstream as a security concern
edit: another example: https://old.reddit.com/r/firefox/comments/16x7qbq/cant_disable_sponsored_shortcuts_on_home_screen/
- do we protect the user here against 3rd party software meddling with settings? - cc: @pierovhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42140disable windows.sizeToContent()2024-01-18T15:10:01ZThorindisable windows.sizeToContent()[1600400](https://bugzilla.mozilla.org/show_bug.cgi?id=1600400) Consider dropping support for Window.sizeToContent()
- unexposed in nightly FF117+
- disabled in FF120+
- `dom.window.sizeToContent.enabled`
from 1600400
> This is a Gecko ...[1600400](https://bugzilla.mozilla.org/show_bug.cgi?id=1600400) Consider dropping support for Window.sizeToContent()
- unexposed in nightly FF117+
- disabled in FF120+
- `dom.window.sizeToContent.enabled`
from 1600400
> This is a Gecko specific API, it is user-hostile (it allows a web page to resize the browser window, potentially allowing for things like hiding the URL bar), it relies on window.opener and the number of tabs in the current window for its functionality, and is currently implemented incorrectly in Fission (in that it is exposed to third-party iframes when running in Fission mode).
easy peasy :surfer:https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41769TTP-02-007 WP1: Missing about: pages in shouldShowTorConnect check (Info)2023-10-19T14:31:53ZrichardTTP-02-007 WP1: Missing about: pages in shouldShowTorConnect check (Info)>>>
## Description:
It was discovered that the `about:welcome`, `about:privatebrowsing`, and `about:home` pages are not redirecting to about:tor when they are accessed by a user who has not connected to Tor yet.
While this behavior does...>>>
## Description:
It was discovered that the `about:welcome`, `about:privatebrowsing`, and `about:home` pages are not redirecting to about:tor when they are accessed by a user who has not connected to Tor yet.
While this behavior does not present any immediate security risk, it can potentially cause confusion or alarm users who may access these pages before being connected to the Tor network. To ensure consistency across all about: pages, it is recommended to deploy relevant changes.
## Affected file:
`browser/base/content/utilityOverlay.js`
## Affected code:
```javascript
if (TorConnect.shouldShowTorConnect) {
if (
url === "about:tor" ||
(url === "about:newtab" &&
Services.prefs.getBoolPref("browser.newtabpage.enabled", false))
) {
url = TorConnect.getRedirectURL(url) ;
}
}
```
In order to reproduce this issue, simply open the Tor Browser, access `about:home` and
note that the page does not perform an automated redirection to `about:tor`.
To mitigate the problem, Cure53 advises including additional checks to validate whether
the URL matches `about:welcome`, `about:privatebrowsing` or about:home. If a match is
found, the page should be redirected to `about:tor`.
>>>henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41768TTP-02-005 WP1: Redirect to about:blank hides the new Tor Circuit button (Info)2023-10-19T14:33:23ZrichardTTP-02-005 WP1: Redirect to about:blank hides the new Tor Circuit button (Info)>>>
## Description:
It is possible to hide the **Tor Circuit** button from the address bar for a given tab by listening to the `onbeforeunload` event and redirecting the page to `about:blank` when the event is triggered.
If a user attem...>>>
## Description:
It is possible to hide the **Tor Circuit** button from the address bar for a given tab by listening to the `onbeforeunload` event and redirecting the page to `about:blank` when the event is triggered.
If a user attempts to reset their identity by clicking on the **New Tor circuit for this site** option, the navigation can be hijacked by the attacker's script. A blank page will be displayed as a consequence. If the user attempts to navigate back to the previous page using the Back button, the **Tor Circuit** button will not be displayed in the address bar.
Similarly to [TTP-02-002](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41767), this issue was found not to pose any immediate security risk and is included as **Info** only.
## PoC:
```html
<script>
let status;
onbeforeunload = () => {
status = true;
}
let timer = setInterval(() => {
if (status) {
status = false;
clearInterval (timer) ;
location = "about:blank";
}
}, 1);
</script>
```
# Steps to reproduce:
1. Open the Tor Browser and connect to it.
2. Save the PoC above as an HTML file and open it in the browser.
3. Click on the **Tor Circuit** button and then on the **New Tor circuit for this** site option.
4. The page will be redirected to `about:blank`.
5. Click on the **Back** option and observe that the **Tor Circuit button** is hidden for this page.
To mitigate this issue, Cure53 advises applying the same mitigation as specified in the [TTP-02-002](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41767) ticket. Given these issues seem to be related and they might share the same root cause, it is recommended to consider and address them together.
>>>https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41767TTP-02-002 WP1: Redirect prevents switching to new Tor Circuit (Info)2024-03-12T12:05:59ZrichardTTP-02-002 WP1: Redirect prevents switching to new Tor Circuit (Info)>>>
## Description:
It was discovered that navigation initiated through the new Tor Circuit feature can be hijacked. This can be accomplished by redirecting the current website to a cached page immediately after the Tor Circuit switch st...>>>
## Description:
It was discovered that navigation initiated through the new Tor Circuit feature can be hijacked. This can be accomplished by redirecting the current website to a cached page immediately after the Tor Circuit switch starts. As a result, the attacker-initiated navigation occurs before the Tor Circuit's browser-initiated navigation and, subsequently, the next step is canceled.
An attacker could exploit this vulnerability to prevent users from switching circuits while browsing a malicious webpage. Although this prevents the user from changing their Tor Circuit, it was concluded that this does not pose any immediate security risk, and as such, the severity mark was appropriately set at Info.
## PoC:
```html
<?php header ("cache-control: max-age=604800") ;
header ("Age: 100"); 2>
<html>
<script>
let status = false;
onbeforeunload = () => {
status = true;
}
let timer = setInterval(() => {
if (status) {
status = false;
clearInterval (timer);
location.href = location.href;
}
}, 1);
</script>
</html>
```
## Steps to reproduce:
1. Open the Tor Browser and connect to it.
2. Save the PoC above as a PHP file and serve it through a PHP server.
3. Access the file a few times through the Tor Browser to make sure it gets cached by the browser.
4. Click on the **Tor Circuit** button and then on the** New Tor circuit for this site** option.
5. The page will quickly be reloaded but the Circuit will remain the same.
To mitigate this issue, Cure53 advises forcing the navigation initiated by the new **Tor Circuit** feature to be completed. Cancellation of a user-initiated navigation is ill-advised in this scenario. However, during the testing phase, the team was unable to pinpoint the specific code responsible for this issue. As a result, the mitigation advice provided is currently incomplete.
>>>https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41553Tor Browser requires D-Bus' /etc/machine-id on Arch Linux2023-01-05T14:21:15ZTracTor Browser requires D-Bus' /etc/machine-id on Arch LinuxHello Tor developers,
I have been playing with firejail to harden the Tor Browser on Arch Linux. And I've noticed, that when creating a private /etc folder with only the minimal required files, the file /etc/machine-id is necessary or t...Hello Tor developers,
I have been playing with firejail to harden the Tor Browser on Arch Linux. And I've noticed, that when creating a private /etc folder with only the minimal required files, the file /etc/machine-id is necessary or the Firefox in Tor Browser will segfault.
http://0pointer.de/public/systemd-man/machine-id.html
> The machine ID is usually generated from a random source during system installation and stays constant for all subsequent boots.
This could be a potential issue, when tor browser gets exploited and someone can uniquely identify the host machine with that ID.
Maybe it would be feasible to build Firefox without the D-Bus dependency on Linux to solve this?
Related firejail ticket:
https://github.com/netblue30/firejail/issues/955
Thanks for making Tor!
**Trac**:
**Username**: robotanarchyhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41537Yubikeys do not work for .onion pages2022-12-20T16:20:14ZrichardYubikeys do not work for .onion pagesReported by @lavamind, the fix for this should possible by part of the 'Bug 23247: Communicating security expectations for .onion' patch, or maybe as a standalone for eventual uplift.
`security.webauth.webauthn` needs to be `true` for y...Reported by @lavamind, the fix for this should possible by part of the 'Bug 23247: Communicating security expectations for .onion' patch, or maybe as a standalone for eventual uplift.
`security.webauth.webauthn` needs to be `true` for yubikeys in general to work (see tor-browser#26614)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41235Rate limit gyroscope sampling frequency on FF mobile2022-11-30T14:52:17ZMike PerryRate limit gyroscope sampling frequency on FF mobileBy the time we get around to an official mobile port, we should double-check that Mozilla has reduced the sampling rate of the gyroscope on Android:
http://crypto.stanford.edu/gyrophone/files/gyromic.pdfBy the time we get around to an official mobile port, we should double-check that Mozilla has reduced the sampling rate of the gyroscope on Android:
http://crypto.stanford.edu/gyrophone/files/gyromic.pdfhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41212Fix startup crash in debug build when installing noscript2022-09-01T22:36:57ZAlex CatarineuFix startup crash in debug build when installing noscript```
2020-10-30 16:29:12.038 10759-10759/org.torproject.torbrowser_debug D/StrictMode: StrictMode policy violation; ~duration=175 ms: android.os.strictmode.DiskWriteViolation
at android.os.StrictMode$AndroidBlockGuardPolicy.onWrit...```
2020-10-30 16:29:12.038 10759-10759/org.torproject.torbrowser_debug D/StrictMode: StrictMode policy violation; ~duration=175 ms: android.os.strictmode.DiskWriteViolation
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1552)
at libcore.io.BlockGuardOs.open(BlockGuardOs.java:252)
at libcore.io.ForwardingOs.open(ForwardingOs.java:166)
at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7542)
at libcore.io.IoBridge.open(IoBridge.java:478)
at java.io.FileOutputStream.<init>(FileOutputStream.java:236)
at java.io.FileOutputStream.<init>(FileOutputStream.java:186)
at org.mozilla.fenix.components.TorBrowserFeatures.installNoScript(TorBrowserFeatures.kt:33)
at org.mozilla.fenix.components.TorBrowserFeatures.install(TorBrowserFeatures.kt:96)
at org.mozilla.fenix.components.Core$engine$2.invoke(Core.kt:121)
at org.mozilla.fenix.components.Core$engine$2.invoke(Core.kt:78)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at org.mozilla.fenix.components.Core.getEngine(Unknown Source:2)
at org.mozilla.fenix.FenixApplication.setupInMainProcessOnly(FenixApplication.kt:150)
at org.mozilla.fenix.FenixApplication.onCreate(FenixApplication.kt:96)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
at android.app.ActivityThread.access$1300(ActivityThread.java:237)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7656)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
2020-10-30 16:29:12.039 10759-10759/org.torproject.torbrowser_debug E/AndroidRuntime: FATAL EXCEPTION: main
Process: org.torproject.torbrowser_debug, PID: 10759
java.lang.RuntimeException: StrictMode ThreadPolicy violation
at android.os.StrictMode$AndroidBlockGuardPolicy.onThreadPolicyViolation(StrictMode.java:1813)
at android.os.StrictMode$AndroidBlockGuardPolicy.lambda$handleViolationWithTimingAttempt$0$StrictMode$AndroidBlockGuardPolicy(StrictMode.java:1727)
at android.os.-$$Lambda$StrictMode$AndroidBlockGuardPolicy$9nBulCQKaMajrWr41SB7f7YRT1I.run(Unknown Source:6)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7656)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
Caused by: android.os.strictmode.DiskWriteViolation
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1552)
at libcore.io.BlockGuardOs.open(BlockGuardOs.java:252)
at libcore.io.ForwardingOs.open(ForwardingOs.java:166)
at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7542)
at libcore.io.IoBridge.open(IoBridge.java:478)
at java.io.FileOutputStream.<init>(FileOutputStream.java:236)
at java.io.FileOutputStream.<init>(FileOutputStream.java:186)
at org.mozilla.fenix.components.TorBrowserFeatures.installNoScript(TorBrowserFeatures.kt:33)
at org.mozilla.fenix.components.TorBrowserFeatures.install(TorBrowserFeatures.kt:96)
at org.mozilla.fenix.components.Core$engine$2.invoke(Core.kt:121)
at org.mozilla.fenix.components.Core$engine$2.invoke(Core.kt:78)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at org.mozilla.fenix.components.Core.getEngine(Unknown Source:2)
at org.mozilla.fenix.FenixApplication.setupInMainProcessOnly(FenixApplication.kt:150)
at org.mozilla.fenix.FenixApplication.onCreate(FenixApplication.kt:96)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
at android.app.ActivityThread.access$1300(ActivityThread.java:237)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7656)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
2020-10-30 16:29:12.040 10759-10759/org.torproject.torbrowser_debug E/ExceptionHandler: Uncaught exception handled:
java.lang.RuntimeException: StrictMode ThreadPolicy violation
at android.os.StrictMode$AndroidBlockGuardPolicy.onThreadPolicyViolation(StrictMode.java:1813)
at android.os.StrictMode$AndroidBlockGuardPolicy.lambda$handleViolationWithTimingAttempt$0$StrictMode$AndroidBlockGuardPolicy(StrictMode.java:1727)
at android.os.-$$Lambda$StrictMode$AndroidBlockGuardPolicy$9nBulCQKaMajrWr41SB7f7YRT1I.run(Unknown Source:6)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7656)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
Caused by: android.os.strictmode.DiskWriteViolation
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1552)
at libcore.io.BlockGuardOs.open(BlockGuardOs.java:252)
at libcore.io.ForwardingOs.open(ForwardingOs.java:166)
at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7542)
at libcore.io.IoBridge.open(IoBridge.java:478)
at java.io.FileOutputStream.<init>(FileOutputStream.java:236)
at java.io.FileOutputStream.<init>(FileOutputStream.java:186)
at org.mozilla.fenix.components.TorBrowserFeatures.installNoScript(TorBrowserFeatures.kt:33)
at org.mozilla.fenix.components.TorBrowserFeatures.install(TorBrowserFeatures.kt:96)
at org.mozilla.fenix.components.Core$engine$2.invoke(Core.kt:121)
at org.mozilla.fenix.components.Core$engine$2.invoke(Core.kt:78)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at org.mozilla.fenix.components.Core.getEngine(Unknown Source:2)
at org.mozilla.fenix.FenixApplication.setupInMainProcessOnly(FenixApplication.kt:150)
at org.mozilla.fenix.FenixApplication.onCreate(FenixApplication.kt:96)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
at android.app.ActivityThread.access$1300(ActivityThread.java:237)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7656)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41131Review Mozilla 1738983: Enable Background Update by default on Release starti...2022-12-09T14:40:46ZrichardReview Mozilla 1738983: Enable Background Update by default on Release starting in FX96## https://bugzilla.mozilla.org/show_bug.cgi?id=1738983
Updater changes, odds are you're already aware and handled in the rebase already## https://bugzilla.mozilla.org/show_bug.cgi?id=1738983
Updater changes, odds are you're already aware and handled in the rebase alreadyhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41112Integrate cross-tab identity leak protection into Tor Browser with native UX2024-03-27T14:39:06ZdonutsIntegrate cross-tab identity leak protection into Tor Browser with native UXIn response to the potential for cache side channel attacks reported in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41071, @ma1 deployed [Cross-tab Identity Leak Protection](https://noscript.net/usage/#crosstab-i...In response to the potential for cache side channel attacks reported in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41071, @ma1 deployed [Cross-tab Identity Leak Protection](https://noscript.net/usage/#crosstab-identity-leak-protection) (or "TabGuard") in NoScript 11.4.8. However some users are finding the warning confusing, and/or are suffering from warning fatigue – e.g.:
```
<Jeremy_Rand_36C3[m]> So far at least 2 users in #tor have been very confused about the NoScript warnings that were recently added. One of them thought the warning meant his identity had already leaked, and panicked and shut off Tor Browser. Seems like we should ask the UX Team to evaluate how we can improve this, now that we have some breathing room since the vulnerability is mitigated.
<Jeremy_Rand_36C3[m]> One of the two users I noticed who was confused about the warning was one of my co-workers, who is very technically proficient, including about Tor, and even he couldn't understand what the warning was about, what triggered it, and what the correct course of action was
<Jeremy_Rand_36C3[m]> Then you have a less sophisticated user who thought the warning meant he was already pwned and panicked
<Jeremy_Rand_36C3[m]> I was hoping the UX Team might be able to evaluate how this warning can be better presented so that users don't get confused or make bad decisions when they see it
```
We're planning on integrating this feature into Tor Browser as part of the work to migrate the Security Level feature in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40925. We should take this opportunity to improve the UX in general, in addition to converting the feature into standard Tor Browser UI patterns.ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41041[Feature proposal] Verification of onion service integrity2023-05-02T13:55:57ZErik Moeller[Feature proposal] Verification of onion service integrity## Problem statement
[SecureDrop](https://securedrop.org/) and similar onion services that seek to provide end-to-end-encrypted communications (between sender and designated recipient) have a bootstrapping problem: if the server is comp...## Problem statement
[SecureDrop](https://securedrop.org/) and similar onion services that seek to provide end-to-end-encrypted communications (between sender and designated recipient) have a bootstrapping problem: if the server is compromised, users cannot be sure that their communications are in fact end-to-end encrypted. Server-provided code or cryptographic key material may have been tampered with.
This is not addressed by existing web standards like [SRI](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) and [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP), both of which depend on the server being a trusted resource to begin with. In the context of WhatsApp E2EE, Cloudflare/Facebook have recently piloted the use of an [integrity verification browser extension](https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users/).
We similarly need a way to securely ship authenticated JavaScript and WASM code and ensure that script execution is limited to that resource(s) only.
The executed code would be the same for all SecureDrop instances of the same version. This requirement is both to prevent browser exploits from untrusted sites and from trusted but compromised websites, as well as to prevent MITM attacks from trusted but compromised websites.
## Proposal
We suggest that an integrity verification feature can be built on top of the existing [about:rulesets](https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/262) functionality in Tor Browser, which maps full-length onion addresses against short names in the form `<service-name>.<namespace>.tor.onion`, e.g., `nytimes.securedrop.tor.onion`, and ships this information as a signed ruleset.
In this proposal, a ruleset provider could act as a verifier of a set of hashes (e.g., sha-256) which correspond to accepted response bodies for specific paths, e.g., `/index.html`, `/1.0.0/`. Subresources could then be verified using SRI.
Tor Browser would need to compute the hash based on the decompressed response body, before rendering the page, and display an error message if it does not correspond to one of the accepted hashes.
Interactions with Tor Browser's safety settings and the NoScript extension will need to be considered; ideally we'd like to ensure script execution is limited to resources that are verified directly or indirectly (e.g., via SRI hashes in a verified resource).
## Alternatives and implementation
We’d be happy to discuss alternative approaches that seem like a better fit from the Tor Project’s perspective, and are open to partnering directly with you on the implementing, testing and piloting any agreed upon approach.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40944Prompt if Tor Browser is zoomed2023-11-04T01:34:46ZbugzillaPrompt if Tor Browser is zoomedDon't we need to display some kind of toolbar message or otherwise warn the user against zooming their Tor Browser window like in legacy/trac#7255?
Because zooming changes resolution to very rare values.Don't we need to display some kind of toolbar message or otherwise warn the user against zooming their Tor Browser window like in legacy/trac#7255?
Because zooming changes resolution to very rare values.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40207Tor Browser is writing to Windows registry on every start2022-11-30T15:19:24ZGeorg KoppenTor Browser is writing to Windows registry on every startI got a report from a cypherpunk:
```
https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Platform-Installation
Firefox is still writing to Windows Registry on every start:
Computer\HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firef...I got a report from a cypherpunk:
```
https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Platform-Installation
Firefox is still writing to Windows Registry on every start:
Computer\HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\Launcher
There it stores all the paths TBB was started from.
That also allows an attacker to permanently disable Launcher Process
security feature, and even any hiccup can do/leads to it:
about:support
Launcher Process Disabled due to failure
```Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40087Use "Safer" as the default security level2023-01-05T16:13:52ZMatthew FinkelUse "Safer" as the default security levelWe should move toward shipping Tor Browser with Safer as the default security level. Safer includes a more sane and reasonable compromise between usability and security, and (we suspect) most users never change the security level from th...We should move toward shipping Tor Browser with Safer as the default security level. Safer includes a more sane and reasonable compromise between usability and security, and (we suspect) most users never change the security level from the default. Therefore, we should use a safe(r) default.
This ticket can track what is needed for this:
- [ ] #40086
- [ ] #33000
- [ ] #19850
- [ ] #22981https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33479PDF fullscreen Presentation Mode doesn't letterbox2023-05-03T13:40:28ZcypherpunksPDF fullscreen Presentation Mode doesn't letterbox1. Open a PDF file in a new tab so it opens in the browser's internal PDF viewer. Here's one. https://gitweb.torproject.org/company/policies.git/plain/corpdocs/IRS-Determination-Letter.pdf
2. Click the 4-outward-arrows (fullscreen?) icon...1. Open a PDF file in a new tab so it opens in the browser's internal PDF viewer. Here's one. https://gitweb.torproject.org/company/policies.git/plain/corpdocs/IRS-Determination-Letter.pdf
2. Click the 4-outward-arrows (fullscreen?) icon on the PDF toolbar. Its tooltip when you hover on it says, "Switch to Presentation Mode"
3. Observe that Presentation Mode is not letterboxed.
PDF Presentation Mode is distinct from browser full screen (F11 key) and from maximize.
Is this exploitable at all? Is the internal PDF API fingerprintable? Tor Browser warns when downloading to not open files in external viewers that could circumvent Tor.
Similar vectors:
* legacy/trac#32713, Letterboxing doesn't work when fullscreening videos
* legacy/trac#12609, HTML5 fullscreen API makes TB fingerprintable
Inspired by:
* https://blog.torproject.org/comment/286752#comment-286752https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31951Disable "Full-screen browsing" by default on Android2022-11-29T15:36:45ZMatthew FinkelDisable "Full-screen browsing" by default on AndroidFennec gives the option of enabling/disabling full-screen browsing where the chrome toolbar disappears when the user scrolls down a page. This is enabled by default. This has the nice benefit of giving users more screen space for the web...Fennec gives the option of enabling/disabling full-screen browsing where the chrome toolbar disappears when the user scrolls down a page. This is enabled by default. This has the nice benefit of giving users more screen space for the webpage content, however this also gives websites an opportunity where they can spoof the security-critical browser chrome.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31031Tor Browser trying to read /etc/machine-id on start2022-11-30T16:55:53ZTracTor Browser trying to read /etc/machine-id on startSteps to reproduce:
- Tor Browser from the official website
- Download and enable the AppArmor profile from https://github.com/Whonix/apparmor-profile-torbrowser (you may need to modify 2 or 3 lines due to different naming, e.g. change ...Steps to reproduce:
- Tor Browser from the official website
- Download and enable the AppArmor profile from https://github.com/Whonix/apparmor-profile-torbrowser (you may need to modify 2 or 3 lines due to different naming, e.g. change `*-browser` to `*-browser*`)
- Start TorBrowser
- Inspect `/var/log/kern.log`
You'll see a message like
`Jun 29 01:23:45 debian kernel: [xxxxxx.xxxxxx] audit: type=1400 audit(xxxxxxxxxx.xxx:xx): apparmor="DENIED" operation="open" profile="/**/*-browser*/Browser/firefox" name="/etc/machine-id" pid=xxxx comm="firefox.real" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0`
Not sure if this behaviour is also present in Firefox, maybe test it when I have time.
---
Debian 10 "Buster"
Tor Browser 8.5.3
AppArmor 2.13.2-10
**Trac**:
**Username**: rain-undefinedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30271Validate untrusted TLS certificates to ensure Exits aren't performing an attack2023-01-05T16:36:06ZTom Rittertom@ritter.vgValidate untrusted TLS certificates to ensure Exits aren't performing an attackAs described in https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/103-selfsigned-user-safety.txt - we can validate untrusted certificates via a separate circuit to ensure the exit node is not performing a TLS MITM attack ...As described in https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/103-selfsigned-user-safety.txt - we can validate untrusted certificates via a separate circuit to ensure the exit node is not performing a TLS MITM attack on end users.