Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-16T18:53:58Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42462investigate mpris + disk data2024-03-16T18:53:58ZThorininvestigate mpris + disk dataAFAICT [this](https://searchfox.org/mozilla-central/search?q=mpris&path=&case=false&regexp=false) is a linux (gtk?) thing - and at least with `media.hardwaremediakeys.enabled` creates video thumbnails - I have not tested or verified
cc ...AFAICT [this](https://searchfox.org/mozilla-central/search?q=mpris&path=&case=false®exp=false) is a linux (gtk?) thing - and at least with `media.hardwaremediakeys.enabled` creates video thumbnails - I have not tested or verified
cc @pierovhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42418TorBrowser leave trace on the Windows Event Log by default and there is no wa...2024-03-05T13:50:25ZcypherpunksTorBrowser leave trace on the Windows Event Log by default and there is no way to stop this!To be clear, Mozilla Firefox does same thing.
Steps.
1. Launch Tor Browser latest
2. Open "eventvwr.ms" (The event viewer of Windows)
3. Open "Windows Logs/Application"
You'll see tons of:
```
The description for Event ID 5 from sourc...To be clear, Mozilla Firefox does same thing.
Steps.
1. Launch Tor Browser latest
2. Open "eventvwr.ms" (The event viewer of Windows)
3. Open "Windows Logs/Application"
You'll see tons of:
```
The description for Event ID 5 from source Tor Browser Launcher cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42371ESR128: rethink/check new identity2024-01-18T15:10:11ZThorinESR128: rethink/check new identityWhen ESR128 comes round there will be data written to disk (in PBM) that needs to be sanitized/cleaned-up
cc @pierovWhen ESR128 comes round there will be data written to disk (in PBM) that needs to be sanitized/cleaned-up
cc @pierovhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42282"Tor Browser" entry created in registry Editor under HKLM and HKCR2024-01-09T13:58:23Zcypherpunks"Tor Browser" entry created in registry Editor under HKLM and HKCR"Tor Browser" entry created in registry Editor under HKLM and HKCR"Tor Browser" entry created in registry Editor under HKLM and HKCRcypherpunkscypherpunkshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42255lock pdfjs.disabled to false in stable2024-01-09T14:37:09ZThorinlock pdfjs.disabled to false in stablein FF116 [1838415](https://bugzilla.mozilla.org/show_bug.cgi?id=1838415) in [Don't spoof explicitly disabled pdfJS](https://phabricator.services.mozilla.com/D180938) RFP no longer ignores the pref `pdfjs.disabled`. The original RFP prote...in FF116 [1838415](https://bugzilla.mozilla.org/show_bug.cgi?id=1838415) in [Don't spoof explicitly disabled pdfJS](https://phabricator.services.mozilla.com/D180938) RFP no longer ignores the pref `pdfjs.disabled`. The original RFP protection was done to help against disk leaks and to provide a uniform fingerprint [1]
Given these two aspects, we should just lock the pref in stable release
[1] There are only two possible values for combined plugins, mimeTypes and pdfViewerEnabledhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42220Flip all the possible preferences to prevent any automatic download2023-11-01T18:10:30ZPier Angelo VendrameFlip all the possible preferences to prevent any automatic downloadWe should make sure that no automatic downloads happens.
In normal Firefox for example the webp images from our blog are downloaded automatically when you open them in new tabs.
Also, I think we could force our browsers to ignore [`Con...We should make sure that no automatic downloads happens.
In normal Firefox for example the webp images from our blog are downloaded automatically when you open them in new tabs.
Also, I think we could force our browsers to ignore [`Content-disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) (maybe we already do it, I haven't checked).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42147Add browser.helperApps.deleteTempFileOnExit to our profile2023-10-31T05:46:31ZThorinAdd browser.helperApps.deleteTempFileOnExit to our profilefrom the almighty AF
```js
/* 2603: remove temp files opened with an external application
* [1] https://bugzilla.mozilla.org/302433 ***/
user_pref("browser.helperApps.deleteTempFileOnExit", true);
```
cc: @pierovfrom the almighty AF
```js
/* 2603: remove temp files opened with an external application
* [1] https://bugzilla.mozilla.org/302433 ***/
user_pref("browser.helperApps.deleteTempFileOnExit", true);
```
cc: @pierovPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42057Disable Platform text-recognition functionality2023-10-03T15:38:02ZrichardDisable Platform text-recognition functionalityMozilla's text recognition API is currently macOS only and calls out to these platfoms apis: https://developer.apple.com/documentation/vision/recognizing_text_in_images
In the future this could/should be replaced with local in-process O...Mozilla's text recognition API is currently macOS only and calls out to these platfoms apis: https://developer.apple.com/documentation/vision/recognizing_text_in_images
In the future this could/should be replaced with local in-process OCR system like teseract ( https://github.com/tesseract-ocr/tesseract ). For now let's neuter the global check to hard return false always and prevent all the dependent code paths from being taken.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42051Disable background downloading in private browsing mode2023-12-04T15:02:43ZrichardDisable background downloading in private browsing modeUpstream: https://bugzilla.mozilla.org/show_bug.cgi?id=438905
It is unexpected behaviour and a disk leak for downloads to start downloading *before* a user has actually agreed to a download. We should disable this feature when private b...Upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=438905
It is unexpected behaviour and a disk leak for downloads to start downloading *before* a user has actually agreed to a download. We should disable this feature when private browsing mode is enabled.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42015Review Mozilla 1830890: Keep a history window of WebRTC stats for about:webrtc2023-10-05T12:44:53ZrichardReview Mozilla 1830890: Keep a history window of WebRTC stats for about:webrtcLink: https://bugzilla.mozilla.org/show_bug.cgi?id=1830790
We should make sure there's no disk leak here, and if there is gate it behind private browsing mode and uplift.Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1830790
We should make sure there's no disk leak here, and if there is gate it behind private browsing mode and uplift.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42002Review Mozilla 1809305: Allow user to copy an image to the clipboard2023-10-03T13:28:08ZrichardReview Mozilla 1809305: Allow user to copy an image to the clipboardLink: https://bugzilla.mozilla.org/show_bug.cgi?id=1809305
We should see if there are mitigations we should apply here similar to our desktop clipboard patches.
/cc @danLink: https://bugzilla.mozilla.org/show_bug.cgi?id=1809305
We should see if there are mitigations we should apply here similar to our desktop clipboard patches.
/cc @danma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988Tor Browser history leaked to syslogs via GNOME2023-12-18T13:51:55ZhonortonTor Browser history leaked to syslogs via GNOME### Summary
Tab titles are sometimes logged by GNOME to `/var/log/syslog`, effectively causing browsing habits to persist on the system, even after closing Tor Browser. As Tor Browser does not save history by default, many users will not...### Summary
Tab titles are sometimes logged by GNOME to `/var/log/syslog`, effectively causing browsing habits to persist on the system, even after closing Tor Browser. As Tor Browser does not save history by default, many users will not expect this.
### Steps to reproduce:
1. Open a new Tor Browser window.
2. (optional) "Connect" to the Tor network and navigate to an arbitrary website.
3. Press the Super key (default) to open the GNOME activities menu.
4. Review syslog via `cat /var/log/syslog | grep -i "browser"`
### What is the current bug behavior?
I see results containing Tor Browser tab titles, such as the titles of opened websites.
### What is the expected behavior?
I expect not to see my visited website titles in any system file without my authorization.
More strongly, I don't expect GNOME (which may log all sorts of things) to require access to my visited website titles.
### Environment
- OS Version: Pop! OS 22.04
- GNOME Shell Version: 3.38.6
- Tor Browser Version: 12.5.2
- Tor Browser Installation Method: "Linux" binary from `https://www.torproject.org/download/`
### Relevant logs and/or screenshots
```
[/var/log/syslog]
[snip]
Aug 9 11:23:52 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug 9 11:23:53 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug 9 11:27:28 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
Aug 9 11:27:31 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
[snip]
```Pier Angelo VendramePier Angelo Vendrame2023-11-13https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41944Review Mozilla 1774083: Add Surrogate COM Server to handle native Windows not...2023-10-05T17:15:48ZrichardReview Mozilla 1774083: Add Surrogate COM Server to handle native Windows notifications when Firefox is closed.Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1774083
On windows COM servers are registered in the registy (if i recall correctly). We should make sure any such registration is gated behind w/e pref is used to disable notifications.Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1774083
On windows COM servers are registered in the registy (if i recall correctly). We should make sure any such registration is gated behind w/e pref is used to disable notifications.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41942Review Mozilla 1682520: Use the WER runtime exception module to catch early c...2023-10-05T17:15:48ZrichardReview Mozilla 1682520: Use the WER runtime exception module to catch early crashesLink: https://bugzilla.mozilla.org/show_bug.cgi?id=1682520
WER is the Windows crash reporting system. The above change may involve registry edits we want to get rid or other disk leak type stuffs.Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1682520
WER is the Windows crash reporting system. The above change may involve registry edits we want to get rid or other disk leak type stuffs.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41897Password saved while not in PBM are hidden but not deleted while in PBM (can ...2023-11-13T17:15:44Zma1Password saved while not in PBM are hidden but not deleted while in PBM (can be recovered by disabling PBM back)Copy-pasting from HackerOne report n. 2070150, setting confidential initially for triaging but I personally don't think it should be hidden, even though worth discussing (maybe we should actually nuke all storage, including passwords, ev...Copy-pasting from HackerOne report n. 2070150, setting confidential initially for triaging but I personally don't think it should be hidden, even though worth discussing (maybe we should actually nuke all storage, including passwords, every time PBM is flipped).
Also, could reproduce on 102.x but cannot reproduce on 115 because saving passwords seems broken there. You click "Save" but the same exception as cancelling is thrown:
```
NS_ERROR_ABORT: User canceled primary password entry
encrypt resource://gre/modules/crypto-SDR.sys.mjs:87
_encryptLogin resource://gre/modules/storage-json.sys.mjs:825
addLogin resource://gre/modules/storage-json.sys.mjs:186
addLogin resource://gre/modules/LoginManager.sys.mjs:323
persistData resource://gre/modules/LoginManagerPrompter.sys.mjs:441
callback resource://gre/modules/LoginManagerPrompter.sys.mjs:531
_onButtonEvent resource://gre/modules/PopupNotifications.sys.mjs:1928
oncommand chrome://browser/content/browser.xhtml:1
PopupNotifications.sys.mjs:1934:17
_onButtonEvent resource://gre/modules/PopupNotifications.sys.mjs:1934
oncommand chrome://browser/content/browser.xhtml:1
```
Depending on how we feel about the password manager in general, will open another issue for that or one to disable/hide it completely.
/cc @richard, @pierov
**Recover passwords stored when private browsing mode was disabled, after re-enabling private browsing mode and about:logins stating no login credentials exist.**
**Steps To Reproduce:**
Machine used: MacBook Pro 2020 M1
Download Tor Browser (Latest Version) for Mac OS (Latest Version: Ventura 13.4.1)
Enable ‘Always connect automatically’ and click ‘Connect’
Navigate to about:preferences#privacy
Disable ‘Always use private browsing mode’ and restart the browser when prompted.
Navigate to about:logins
Click ‘Create New Login’ and enter ‘eff.org’ into the Website address, ‘test’ into the Username, and ‘test’ into the Password. Then click save.
Navigate to about:preferences#privacy
Enable ‘Always use private browsing mode’ and restart the browser when prompted.
Navigate to about:logins and verify there are no passwords stored.
Navigate to about:preferences#privacy
Disable ‘Always use private browsing mode’ and restart the browser when prompted.
Navigate to about:logins
You can now view the login to eff.org and password, which you thought had been deleted.
**Actual behaviour:** Login credentials that were created when private browsing mode was disabled can be recovered, even after re-enabling private browser mode and the about:logins displaying no login credentials exist in Tor Browser.
**Expected behaviour:** Login credentials automatically clear when re-enabling private browser mode, after creating login credentials with private browser mode disabled.
**Impact**
An attacker could recover any passwords that the user stored when private browsing was disabled, even if a user re-enabled private browsing. The user may verify about:logins and assume their logins have been deleted, which may not be true. This attack assumes an attacker has full access and control of a users device.ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41891Tor Browser creates Registry entries2023-12-11T09:24:35ZcypherpunksTor Browser creates Registry entriesThe Registry key, `Computer\HKEY_CURRENT_USER\Software\Tor Project\Firefox` was created. As far as I remember this regisry entry was not exist until 12.0 or 12.5.
Could you please stop writing things to system & keep it to Tor Browser d...The Registry key, `Computer\HKEY_CURRENT_USER\Software\Tor Project\Firefox` was created. As far as I remember this regisry entry was not exist until 12.0 or 12.5.
Could you please stop writing things to system & keep it to Tor Browser directory only? This is a disk leak issue when Tor Browser write things OUTSIDE of Tor Browser folder.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41881Developer tools/Network/New Request remembers requests2023-10-03T15:37:59ZcypherpunksDeveloper tools/Network/New Request remembers requestsOn TBB 12.5.1, opening Developer tools, Network tab and then clicking on "New Request" causes address, headers, POST body to be autofilled with ones of previous request in other isolation domain or even after browser restart.On TBB 12.5.1, opening Developer tools, Network tab and then clicking on "New Request" causes address, headers, POST body to be autofilled with ones of previous request in other isolation domain or even after browser restart.cypherpunkscypherpunkshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41875revisit enforce `ask` for downloads | also patch `ask` for other files2023-08-26T04:14:20ZThorinrevisit enforce `ask` for downloads | also patch `ask` for other filesESR115 built from https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/33fdfcfcf4128fbb99599c464aa05177a85f194d
```
/* 2651: enable user interaction for security by always asking where to download
* [SETUP-CHROME] On And...ESR115 built from https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/33fdfcfcf4128fbb99599c464aa05177a85f194d
```
/* 2651: enable user interaction for security by always asking where to download
* [SETUP-CHROME] On Android this blocks longtapping and saving images
* [SETTING] General>Downloads>Always ask you where to save files ***/
user_pref("browser.download.useDownloadDir", false);
```
this is default false on previous ESRs, so we've regressed something somewhere? @pierov
also, while we're at it
```
/* 2654: enable user interaction for security by always asking how to handle new mimetypes [FF101+]
* [SETTING] General>Files and Applications>What should Firefox do with other files ***/
user_pref("browser.download.always_ask_before_handling_new_types", true);
```
this is default false in earlier releases and I think I opened an issue about this, might as well cover it herehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41758ESR115: android: don't allow PDFs to be opened by 3rd party apps2023-08-26T05:12:29ZThorinESR115: android: don't allow PDFs to be opened by 3rd party appshttps://bugzilla.mozilla.org/show_bug.cgi?id=1829372 - landed in FF114https://bugzilla.mozilla.org/show_bug.cgi?id=1829372 - landed in FF114https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41752Review changes done by Bug 415652023-10-05T12:40:26ZPier Angelo VendrameReview changes done by Bug 41565While trying to uplift #41565/!505, I got some feedback, see [Bug 1829140](https://bugzilla.mozilla.org/show_bug.cgi?id=1829140).
- `fission.experiment.*` has gone in [Bug 1671548](https://bugzilla.mozilla.org/show_bug.cgi?id=1671548)
-...While trying to uplift #41565/!505, I got some feedback, see [Bug 1829140](https://bugzilla.mozilla.org/show_bug.cgi?id=1829140).
- `fission.experiment.*` has gone in [Bug 1671548](https://bugzilla.mozilla.org/show_bug.cgi?id=1671548)
- `browser.js` changes are done to avoid calls to histogram functions that become a no-op with telemetry disabled
- not a good approach for Mozilla: the assumption is that all the telemetry checks are done _by these functions_, not by the caller
- after all, not good also for us: we don't patch any other block of calls (unless it's for other reasons, such as the download code, in which we drop an entire telemetry block because our patch changes several scopes)
- as a result, **dropping these changes seems a sensible option**
- for `BrwoserGlue`, I've been asked to move these changes closer to where the writing actually happens
- possibly document the reasons for which the usual Firefox's assumptions (call Telemetry, it will check if it's allowed to run instead) don't hold
- makes sense, and I'm doing it also for the C++ changes (i.e., not change `nsAppRunner.cpp`, but `WriteFailedProfileLock` in `Telemetry.cpp`)
- `reportInstallationTelemetry` doesn't actually write anything: it depends on `installation_telemetry.json`, written by the installer. We don't add that file, so as a matter of fact, we don't need to do anything on that function. It looks like a performance improvement, but upstream says that they should be measurable, and if they are, probably the code _with telemetry enabled_ should be improved, instead of having these changes
- it could make sense to drop this change, too. I will comment upstream, to deepen the performance improvement argument (it's async stuff, so it should not be that heavy)
- `_collectStartupConditionsTelemetry` does not write anything on disk directly, either, so upsteram is less happy to take it.
- In general, disk leak of times is a very weak argument, because there are probably plenty of other ways to get the same information.
- for `times.json`, I've kept thinking about it for a few days, and I think it was a misunderstanding on our side. `times.json` is used also for profile health and something for the Activity Stream. But, as a coincidence, the only piece of code calling `ProfileAge()` in Tor Browser was that telemetry file.
- I'm leaning toward not patching it anymore. What is its role in the security treat model, exactly?
- `times.json` is created with the profile, so we still have the profile creation time. Also, if we didn't have it, there would probably be some file leaking some date.
- I don't think fighting timestamps is worth the issue. There are several other things that change them, including preferences and even our Onion Aliases patch.
- This can be disabled, but I'm sure many more remain.
- I don't think we need profile health at the moment, neither in Tor Browser, nor in Mullvad Browser, since we should hardly write anything on them. Maybe in the future we might, but if we have a stronger reason to disable timestamp collection, I'd be up for just disabling it.
- The I/O argument hardly holds, as it's implemented in an async way. Also, performance improvements should be measured/measurable to make sure they're worth it (and upstream should improve the code in the first place, if that's the case).
I'd be happy if upstream took the disk changes.
But after having re-reviewed the patch, I think I'd be okay in making it lighter even if they didn't (i.e., take what I proposed upstream).Pier Angelo VendramePier Angelo Vendrame