torbutton issueshttps://gitlab.torproject.org/tpo/applications/torbutton/-/issues2022-05-26T01:39:57Zhttps://gitlab.torproject.org/tpo/applications/torbutton/-/issues/31066Consider protection against requests going through catch-all circuit2022-05-26T01:39:57ZAlex CatarineuConsider protection against requests going through catch-all circuitWhile taking a look at upstreaming legacy/trac#26353 to Firefox I was thinking whether it would make sense to have some mitigations to reduce potential anonymity loss if there are requests unintentionally going through the catch-all circ...While taking a look at upstreaming legacy/trac#26353 to Firefox I was thinking whether it would make sense to have some mitigations to reduce potential anonymity loss if there are requests unintentionally going through the catch-all circuit. We currently isolate requests by `originAttributes.firstPartyDomain`. If `originAttributes.firstPartyDomain` is empty, then the request goes to the catch-all circuit (socks username `--unknown--`).
I would suggest changing this and proxying with socks username `--unknown--|||firstPartyDomain(request)` instead, where `firstPartyDomain` is calculated as if the request host was the origin. I think this can only improve user anonymity wrt current behaviour, at the cost of potentially worse network performance (more circuits). But I think there should not be many cases were `firstPartyDomain` is empty, and also not so many `--unknown-- + domain` combinations to make this a performance issue. I think it should be seen just as a mitigation for the potential cases in Tor Browser that might not obey first party isolation.
Not sure if this has already been discussed in the past, but I thought it might be interesting to consider.https://gitlab.torproject.org/tpo/applications/torbutton/-/issues/23768Update code to wipe indexedDB in New Identity2022-05-18T23:44:05ZArthur EdelsteinUpdate code to wipe indexedDB in New IdentityLooks like Mozilla may have fixed the issue of wiping indexedDB.
https://bugzilla.mozilla.org/show_bug.cgi?id=1047098
Let's see if we can get this working in New Identity.Looks like Mozilla may have fixed the issue of wiping indexedDB.
https://bugzilla.mozilla.org/show_bug.cgi?id=1047098
Let's see if we can get this working in New Identity.https://gitlab.torproject.org/tpo/applications/torbutton/-/issues/12683Permissions in nsIPermissionManager aren't cleared with TorButton's "New Iden...2022-03-17T20:59:06ZIsis LovecruftPermissions in nsIPermissionManager aren't cleared with TorButton's "New Identity"When TorButton's "New Identity" button is pressed, the permissions stored with `nsIPermissionManager` aren't cleared, even though `nsIPermissionManager.removeAll()` is called.
From `torbutton_do_new_identity()` in `src/chrome/content/t...When TorButton's "New Identity" button is pressed, the permissions stored with `nsIPermissionManager` aren't cleared, even though `nsIPermissionManager.removeAll()` is called.
From `torbutton_do_new_identity()` in `src/chrome/content/torbutton.js`:
```
torbutton_log(3, "New Identity: Clearing permissions");
let pm = Cc["@mozilla.org/permissionmanager;1"].
getService(Ci.nsIPermissionManager);
pm.removeAll();
torbutton_log(3, "New Identity: Sending NEWNYM");
```
There's a ton of info stored in this thing, including how many time the site has been visited, if popups are allowed, if a site can access offline storage, etc. For me, several dozen sites are listed after clicking "New Identity". It seems to have been keeping these permissions for quite a while, as some of my sites are reported to have hundreds of visits.
To reproduce, do some stuff in TorBrowser for a while, then click "TorButton > New Identity", then navigate to `about:permissions`.boklmboklmhttps://gitlab.torproject.org/tpo/applications/torbutton/-/issues/9783New Identity does not always clear all OCSP/favicon related network activity2022-05-18T23:07:57ZGeorg KoppenNew Identity does not always clear all OCSP/favicon related network activitySteps to reproduce:
1) Bookmark 10 (randomly chosen) pages
2) They should show up in the "Recently Bookmarked" menu. There click on "Open All in Tabs"
3) Click on "New Identiy" after making sure that there are actual some connections un...Steps to reproduce:
1) Bookmark 10 (randomly chosen) pages
2) They should show up in the "Recently Bookmarked" menu. There click on "Open All in Tabs"
3) Click on "New Identiy" after making sure that there are actual some connections under way.
4) With a high percentage there are favicon and/or ocsp cache entries left in the new session (this happened for me in 5 out of 7 cases)
Could be that these cache entries are due to ongoing network activity. I have not checked that yet.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/torbutton/-/issues/7637Alter "New Identity" to make use of onCacheEntryDoomed if that's still needed2022-05-18T23:00:05ZMike PerryAlter "New Identity" to make use of onCacheEntryDoomed if that's still neededOne of our Firefox patches is a horrible hack that makes nsCacheService::EvictEntries synchronous. We did this because Mozilla made it Async before providing an observer to notify us that the eviction took place. This allowed evercookies...One of our Firefox patches is a horrible hack that makes nsCacheService::EvictEntries synchronous. We did this because Mozilla made it Async before providing an observer to notify us that the eviction took place. This allowed evercookies to persist for a short time after New Identity (see legacy/trac#5715).
Apparently, we should now be able to listen to https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsICacheListener#onCacheEntryDoomed().
Unless of course "doomed" means "We're really going to delete it soon, we swear. But we'd like to give content a few more chances to access it first, just in case they really wanted to recover their evercookies."https://gitlab.torproject.org/tpo/applications/torbutton/-/issues/3600Prevent redirects from transmitting+storing cookies+identifiers2022-01-19T14:45:01ZMike PerryPrevent redirects from transmitting+storing cookies+identifiersI've been using RequestPolicy for so long I'd not realized that redirects have been getting more and more transparent. In Firefox 4/5, the loading indications are impossible to differentiate between redirects and 3rd party loads.
There ...I've been using RequestPolicy for so long I'd not realized that redirects have been getting more and more transparent. In Firefox 4/5, the loading indications are impossible to differentiate between redirects and 3rd party loads.
There does not appear to be any obvious about:config options to enable more prompting either. We may have to dig into the RequestPolicy source to see how they do this.
Redirect notification is important if we're going to try to keep 3rd party cookies disabled (or dual-keyed). If redirects are 100% transparent, there's little point in disabling 3rd party cookies.
NoScript has some options for notifying in the case of JS redirects. We'll probably want to enable those options in TBB, too.