Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2022-09-01T22:37:54Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41215Downloads are not cleared after browser restart2022-09-01T22:37:54ZAlex CatarineuDownloads are not cleared after browser restarthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41221Safely save state when app is killed by OS2022-09-01T22:40:03ZMatthew FinkelSafely save state when app is killed by OSWhen the device is under memory pressure (and some other reasons), Android kills random apps. Tor Browser uses a significant amount of resources, so it is killed relatively often. This has the consequence of users losing all of their ope...When the device is under memory pressure (and some other reasons), Android kills random apps. Tor Browser uses a significant amount of resources, so it is killed relatively often. This has the consequence of users losing all of their open tabs, arbitrarily.
Android gives an app an opportunity to save its state immediately before it is killed. We should take advantage of this and somehow-safely save the current statehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40062consider disabling the Web Share API (Android and Windows)2022-11-30T15:13:29ZMark Smithconsider disabling the Web Share API (Android and Windows)From #33534: The Web Share API allows web pages to bring up a system sharing UI. Does this cause any disk leaks or proxy bypass possibilities? If it does, we should disable it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1402369 \
"Imp...From #33534: The Web Share API allows web pages to bring up a system sharing UI. Does this cause any disk leaks or proxy bypass possibilities? If it does, we should disable it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1402369 \
"Implement Web Share API on Fenix"
https://bugzilla.mozilla.org/show_bug.cgi?id=1573029 \
"Implement Web Share on Windows"https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40054Investigate disabling disk caching of shaders2023-01-05T16:25:29ZMark SmithInvestigate disabling disk caching of shadersFrom #33534: Firefox 75 implemented more aggressive caching of shaders to disk. We should verify this does not happen in private browsing mode (or that the shaders being cached are not from web content).
https://bugzilla.mozilla.org/sho...From #33534: Firefox 75 implemented more aggressive caching of shaders to disk. We should verify this does not happen in private browsing mode (or that the shaders being cached are not from web content).
https://bugzilla.mozilla.org/show_bug.cgi?id=1614679 \
"Cache shaders to disk even if they are compiled after the 10th frame"Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33961Uplift patch for "21830: Copying large text from web console leaks to /tmp"2022-11-30T16:59:16ZAlex CatarineuUplift patch for "21830: Copying large text from web console leaks to /tmp"Bugzilla is https://bugzilla.mozilla.org/show_bug.cgi?id=1433030. We can somehow try to make progress on that.Bugzilla is https://bugzilla.mozilla.org/show_bug.cgi?id=1433030. We can somehow try to make progress on that.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32002Double-check Storage Access API for disk leaks and 3rd party cookie blocking ...2023-01-05T16:47:14ZGeorg KoppenDouble-check Storage Access API for disk leaks and 3rd party cookie blocking adherenceThe [Storage Access API](https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API) is a means to prevent trackers across origins yet to not break authentication flows and other benign 3rd party identifier usage.
We should mak...The [Storage Access API](https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API) is a means to prevent trackers across origins yet to not break authentication flows and other benign 3rd party identifier usage.
We should make sure it's not using the disk in our default Tor Browser mode.
Moreover, we disable third-party cookies outright, mainly because we have not looked at the first-party isolation yet (legacy/trac#21905), and we should make sure this is not bypassed in non-private-browsing-mode contexts.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40986Clean up profile directory during New Identity2022-11-30T16:43:30ZGeorg KoppenClean up profile directory during New IdentityAt CCCamp 2019 a cypherpunk approached me proposing that we try to clean up the profile directory as well as good as we can during New Identity.
I think I like the general idea of doing a more aggressive cleaning (from time to time) in ...At CCCamp 2019 a cypherpunk approached me proposing that we try to clean up the profile directory as well as good as we can during New Identity.
I think I like the general idea of doing a more aggressive cleaning (from time to time) in the profile directory in particular if users are requesting a New Identity. I am not sure yet, though, whether we want to have this mechanism during New Identity as this one is usually more concerned with stuff that is risk exposing previous browsing sessions to *web content*. Which is clearly not the case for worries about the profile directory which are concerned with a local attacker.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29887Potential user activity data leak2023-01-05T17:32:42ZTracPotential user activity data leakThe user preferences file at ./Browser/TorBrowser/Data/Browser/profile.default/prefs.js contains data that can be used to tie anonymous activity via Tor in a certain time period to a particular user. This information may serve as additio...The user preferences file at ./Browser/TorBrowser/Data/Browser/profile.default/prefs.js contains data that can be used to tie anonymous activity via Tor in a certain time period to a particular user. This information may serve as additional evidence and help repressive regimes to identify activists and whistleblowers.
The most sensitive data is contained in the following parameters:
* toolkit.startup.last_success - time of last successful browser startup.
* browser.laterrun.bookkeeping.profileCreationTime - profile creation time, i.e. when this browser was started for the first time.
All other parameters listed below are regularly updated during the browser's run. Given their quantity, they may serve as a pretty reliable indication of when this particular user was online.
* app.update.lastUpdateTime.addon-background-update-timer
* app.update.lastUpdateTime.background-update-timer
* app.update.lastUpdateTime.blocklist-background-update-timer
* app.update.lastUpdateTime.browser-cleanup-thumbnails
* app.update.lastUpdateTime.experiments-update-timer
* app.update.lastUpdateTime.search-engine-update-timer
* app.update.lastUpdateTime.xpi-signature-verification
* extensions.blocklist.lastModified
* extensions.torbutton.lastUpdateCheck
* idle.lastDailyNotification
* media.gmp-manager.lastCheck
* places.database.lastMaintenance
* storage.vacuum.last.places.sqlite
* app.update.lastUpdateTime.xpi-signature-verification
If there are any other such parameters, they may pose a security risk as well.
As a possible solution, we propose that these parameters should not be updated at all, and the browser should treat every time it is run as the first.
**Trac**:
**Username**: pf.teamSponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40980NoScript XSS user choices are persisted2023-01-05T16:24:12ZTracNoScript XSS user choices are persistedWhenever user chooses 'Always allow' or 'Always block' in one of the NoScript XSS popups the setting is persisted in `storage-sync.sqlite` file and this is never cleared on browser startup as the rest of NoScript preferences.
The full p...Whenever user chooses 'Always allow' or 'Always block' in one of the NoScript XSS popups the setting is persisted in `storage-sync.sqlite` file and this is never cleared on browser startup as the rest of NoScript preferences.
The full persisted object can be inspected via `about:debugging` -> Debug Noscript -> `browser.storage.sync.get('xssUserChoices')`.
I understand this is not intended behaviour, since NoScript default is to not persist user choices (clearing them up on browser start).
**Trac**:
**Username**: atacSponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29630TorBrowser creates empty directory in "/tmp"2022-11-29T15:16:51ZTracTorBrowser creates empty directory in "/tmp"I'm using the latest TBB on Linux.
After I start TorBrowser, the directory is created in temporary direcrory (in my case /tmp)
drwx------ 2 user user 4096 Mar 1 12:34 Temp-41d8a42b-5545-4af5-89c2-be2502af95c7
The directory is empt...I'm using the latest TBB on Linux.
After I start TorBrowser, the directory is created in temporary direcrory (in my case /tmp)
drwx------ 2 user user 4096 Mar 1 12:34 Temp-41d8a42b-5545-4af5-89c2-be2502af95c7
The directory is empty. After I close the TBB, this directory disappears. Not sure if it's OK behavior or not.
**Trac**:
**Username**: AxelFhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/28996Tor Browser on Windows creates a file in %APPDATA%\Microsoft\Windows\Recent\C...2024-02-12T16:55:53ZrichardTor Browser on Windows creates a file in %APPDATA%\Microsoft\Windows\Recent\CustomDestinations containing the Tor Browser install locationBackground here: https://trac.torproject.org/projects/tor/ticket/12885#comment:13
Attached is an example file that is created when Tor Browser is installed to `C:\Users\user\Desktop\Tor Browser`Background here: https://trac.torproject.org/projects/tor/ticket/12885#comment:13
Attached is an example file that is created when Tor Browser is installed to `C:\Users\user\Desktop\Tor Browser`https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/28373verify that cubeb-related tmp files do not violate disk avoidance2023-01-05T17:31:27ZMark Smithverify that cubeb-related tmp files do not violate disk avoidanceThe following bug caught our eye while reviewing undocumented changes made between ESR52 and ESR60 (for legacy/trac#22074):
https://bugzilla.mozilla.org/show_bug.cgi?id=1407490
"Ensure cubeb remoting socket has unique name per server pr...The following bug caught our eye while reviewing undocumented changes made between ESR52 and ESR60 (for legacy/trac#22074):
https://bugzilla.mozilla.org/show_bug.cgi?id=1407490
"Ensure cubeb remoting socket has unique name per server process."
From reading the code in media/audioipc/audioipc/src/lib.rs, it looks like temporary files are created in the path returned by `temp_dir()` (which is probably /tmp or the %TEMP% directory on Windows). We should see if that is true, what data is in the files, and whether they are left behind when the browser exits.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27065TBA: Delete AccountManager usage from Tabs2022-11-30T13:31:35ZMatthew FinkelTBA: Delete AccountManager usage from TabsWhen the app is started/restarted, it creates an `OnAccountsUpdatedListener` using the Android `AccountManager` in `Tabs.attachToContext()`. When a new account is added, the Listener calls `queuePersistAllTabs()` where the current tabs a...When the app is started/restarted, it creates an `OnAccountsUpdatedListener` using the Android `AccountManager` in `Tabs.attachToContext()`. When a new account is added, the Listener calls `queuePersistAllTabs()` where the current tabs are cached in the local database on disk. We should avoid all of this. We already deleted most of the FxA and Sync related code, we can probably delete this, too.
```
mAccountManager = AccountManager.get(appContext);
mAccountListener = new OnAccountsUpdateListener() {
@Override
public void onAccountsUpdated(Account[] accounts) {
queuePersistAllTabs();
}
};
// The listener will run on the background thread (see 2nd argument).
mAccountManager.addOnAccountsUpdatedListener(mAccountListener, ThreadUtils.getBackgroundHandler(), false);
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40976On macOS a list of downloaded files is kept on disk and survives New Identity2022-11-29T13:39:51ZGeorg KoppenOn macOS a list of downloaded files is kept on disk and survives New IdentityOn macOS a list of downloaded files is kept and survives New Identity. It might affect other platforms, too:
```
Mac [...] keeps a list of all the downloaded files. From which app(browser) and which website.
Location:
sqlite3 ~/Library/...On macOS a list of downloaded files is kept and survives New Identity. It might affect other platforms, too:
```
Mac [...] keeps a list of all the downloaded files. From which app(browser) and which website.
Location:
sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV* 'select * from LSQuarantineEvent’
52FA128A-42E1-41E6-A0DD-5A58FB21ED7A|550679062.0|org.torproject.torbrowser|TorBrowser.app|https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSP6KTk9o7luHrlg5CoeGFLiH2RpKwEcywcgdDeVQpciZzytjaafDzkKL0v|||0||https://www.google.com/search?q=snowmountains&tbm=isch&sa=G&gbv=1&sei=h3oiW_DkC8yFgAadrJLQBQ|
```Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40975Disk leak on macOS due to Notification API2023-10-12T11:29:31ZGeorg KoppenDisk leak on macOS due to Notification APIKonark Modi reported a while ago a disk leak at least on macOS due to the Notification API. Here is the bug report:
```
The leak is cause by: https://www.w3.org/TR/notifications/ API.
Steps to reproduce:
1. Visit http://www.bennish.net/...Konark Modi reported a while ago a disk leak at least on macOS due to the Notification API. Here is the bug report:
```
The leak is cause by: https://www.w3.org/TR/notifications/ API.
Steps to reproduce:
1. Visit http://www.bennish.net/web-notifications.html
2. Temporarily allow JS.
3. Click on Authorize button.
4. Click on Show button.
5. Notification should occur.
macOS by default saves these notification in`/private/var/folders/qs/54swlb5d1fx4hq969vdqg4rr0000gn/0/com.apple.notificationcenter/db` . It dumps the content of the notification and the website name.
This location can be found using:
Activity Monitor -> Search for process user noted -> Open files and ports -> Notifications DB.
Now, although the user opted in to these notifications, but this is an intended leak from OS level.
```Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/26574Save TBA updates in the internal android storage2022-11-29T14:32:47ZIgor OliveiraSave TBA updates in the internal android storageCurrently, UpdateService downloads the new apk and saves it to an external storage, it violates the disk avoidance principle.
We should modify its code to use the internal storage.Currently, UpdateService downloads the new apk and saves it to an external storage, it violates the disk avoidance principle.
We should modify its code to use the internal storage.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/26444macOS 10.14 adds persisted-to-disk permission prompts for WebCam/Mic access2022-11-29T14:31:31ZTom Rittertom@ritter.vgmacOS 10.14 adds persisted-to-disk permission prompts for WebCam/Mic accessmacOS 10.14 Beta has added OS-level permission prompts for Mic/Camera access. According to Mozilla's prelimimary testing the behavior was:
> The description I found said the OS should cache the results of the prompt. Did a quick test - ...macOS 10.14 Beta has added OS-level permission prompts for Mic/Camera access. According to Mozilla's prelimimary testing the behavior was:
> The description I found said the OS should cache the results of the prompt. Did a quick test - 1st try: get the the Firefox dialog then two OS dialogs for the "Firefox" process (camera and mic), 2nd try: get OS dialog for "plugin-container", 3rd try: no OS dialogs
I requested we file a bug about persisting this to disk in Private Browsing mode (and what, if anything we could do about that...) but I wanted to get this bug on file for Tor Browser.
It seems like a user who uses Tor Browser and uses the mic or camera will create a disk persistence that they had done so, with timestamp.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/26080torbrowser 7.5.4 update seems to generate file with unique uuid in it2022-11-29T14:28:02Zcypherpunkstorbrowser 7.5.4 update seems to generate file with unique uuid in itupdating from 7.5.3 to 7.5.4 on linux seems to include a file named '.uuid' in the fonts dir that appears to be unique (comparing two different updated torbrowsers)updating from 7.5.3 to 7.5.4 on linux seems to include a file named '.uuid' in the fonts dir that appears to be unique (comparing two different updated torbrowsers)Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25633Ctrl-D makes it too easy to create bookmarks accidentally2023-11-01T12:45:57ZcypherpunksCtrl-D makes it too easy to create bookmarks accidentallyIt used to be the case that pressing Ctrl-D would pop up a dialog box prompting you to create a bookmark (or cancel.)
A few releases ago, Firefox changed this behavior. Now, Ctrl-D creates a bookmark, then pops up a dialog prompting yo...It used to be the case that pressing Ctrl-D would pop up a dialog box prompting you to create a bookmark (or cancel.)
A few releases ago, Firefox changed this behavior. Now, Ctrl-D creates a bookmark, then pops up a dialog prompting you to edit the bookmark (or delete it.)
This is a subtle distinction, but potentially an important one, for two reasons.
**1. Pressing Escape after Ctrl-D doesn't undo the bookmarking operation as you might expect.** It's very easy to press Ctrl-D by mistake when you mean to press, say, Ctrl-F. If you've just pressed a key you didn't intend to press, without knowing what it does, and an unexpected dialog appears in your peripheral vision, it's natural to react by pressing Escape ("oops, didn't mean that.") And if you do that, and the dialog disappears in response, it's quite natural to assume that you successfully cancelled whatever action it was that you inadvertently initiated.
**2. Pressing Ctrl-D immediately saves the current URL to disk** (namely, in places.sqlite), without any further confirmation. Even if you are paying attention, a simple slip of the finger can potentially create a persistent record of your browsing activity. (Even if you delete the bookmark immediately, it won't be purged from places.sqlite right away.)
This UI change was a bad idea, but in "normal" Firefox usage, it's usually only a minor annoyance - I end up with a bunch of random accidental bookmarks at the bottom of the menu that I need to clean out every couple of months. But in the Tor Browser context, it's potentially quite dangerous, as it violates the disk avoidance principle.
Saving bookmarks without the user's consent may or may not have any practical impact in most cases. But it can have a major impact on users' confidence in the browser. For that reason, Tor Browser can and should do better.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25064Don't record update history on the Tor Browser2023-06-28T08:16:00ZcypherpunksDon't record update history on the Tor Browser1. Open "about:support".
2. Click "Show update history".
My TBB shows long history.
Can you stop logging these(and clear existing history)?
The date/time information is useful to track Tor users.1. Open "about:support".
2. Click "Show update history".
My TBB shows long history.
Can you stop logging these(and clear existing history)?
The date/time information is useful to track Tor users.