Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-05T18:49:47Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41188Implement Android-native Connection Assist UI2024-03-05T18:49:47ZdonutsImplement Android-native Connection Assist UIAs originally proposed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29590, we should port a version of the flows and UI for Connection Assist (a.k.a. "smarter bootstrapping" or "mostly automated censorship circu...As originally proposed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29590, we should port a version of the flows and UI for Connection Assist (a.k.a. "smarter bootstrapping" or "mostly automated censorship circumvention") designed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40781 to Android.clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33021Sync tabs between Tor Browser instances2023-01-05T15:45:07ZMatthew FinkelSync tabs between Tor Browser instancesWe can think about synchronizing (some) open tabs between Tor Browser instances by each instance creating and registering onion services with other instances. The first iteration of this doesn't need to be crazy where we synchronize the ...We can think about synchronizing (some) open tabs between Tor Browser instances by each instance creating and registering onion services with other instances. The first iteration of this doesn't need to be crazy where we synchronize the exact viewport location of each page between instances, and it shouldn't synchronize all open tabs by default.
But, it'd be neat if we could select a tab in the browser and choose to which other Tor Browser instance that URL should be sent. The URL should not be opened automatically in the other instance, but it should be listed "somewhere" in the UI. If one wants to open one of the synced tabs, then they can open the list and select it.
To some degree this has the ricochet problem but it shouldn't be nearly as bad. The worse tradeoff is that both Tor Browser instances must be online at the same time. This could work well enough for desktop->mobile, but it'll be harder in some situations for desktop->desktop, and mobile->desktop.https://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/19750Sandboxing in Tor Browser2022-11-30T15:14:35ZArthur EdelsteinSandboxing in Tor BrowserHere's a parent ticket to track efforts to sandbox Tor Browser. Please use this ticket to discuss various approaches and link to email discussions where available.Here's a parent ticket to track efforts to sandbox Tor Browser. Please use this ticket to discuss various approaches and link to email discussions where available.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40948Tor Browser should offer an option to clear history in PBM2023-01-05T16:41:52ZcypherpunksTor Browser should offer an option to clear history in PBMBy default, TBB uses private browsing mode. Cookies and other state (e.g. cache) are retained until the browser is restarted. There is neither an option to view the cookies nor to clear the history.
If the browser is left running for a ...By default, TBB uses private browsing mode. Cookies and other state (e.g. cache) are retained until the browser is restarted. There is neither an option to view the cookies nor to clear the history.
If the browser is left running for a long time, a lot of history can be linked.
TBB should offer an option to clear history in private browsing mode and/or clear all history associated with an URL bar domain when it is closed.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16110Improve Time Resolution Defense2023-01-05T15:47:25ZMike PerryImprove Time Resolution DefenseHovav Shacham and Keaton Mowery saw legacy/trac#1517 and emailed to point out some papers from the virtualization literature that have tried to deal with timing-based side channels. It turns out that simply reducing the granularity of th...Hovav Shacham and Keaton Mowery saw legacy/trac#1517 and emailed to point out some papers from the virtualization literature that have tried to deal with timing-based side channels. It turns out that simply reducing the granularity of the clock can still allow an adversary to extrapolate the true time by running a busy loop with a predictable operation in it. They provided a simple test that I updated and posted here https://people.torproject.org/~mikeperry/transient/tests/timingtest.html. It is able to recover the original time value with ~1-5ms accuracy.
They linked to this paper https://cseweb.ucsd.edu/~hovav/dist/xentimers.pdf, and suggested that the best approach would be:
> Pick some nominal granularity x. Then define a distribution (normal?) with mean at x. Clocks available to the program only ever show an exact multiple of x, with a clock-edge on transition. But they are lies: Immediately after a clock edge, the monitor draws some value t out of the distribution with mean x, and then sets a time-t timer; when that timer fires, the clock shown to the program is increased by x, and the monitor draws a new value t and continues.
In other words, we'd still report 100ms steps, but change when we bump that step by +/- 50ms or so, based on a random value.
While I'm at it, I should also see how well using window.requestAnimationFrame and setTimeout can reconstruct the clock.
Firefox 38 also added a bunch more time sources to window.Performance, and also added Performance API support to WebWorkers and SharedWorkers. There's also a new animation API (https://developer.mozilla.org/en-US/docs/Web/API/AnimationPlayer).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16025Potential anonymity leak in Tor Browser Bundle via Key Map2022-11-30T16:16:55ZcypherpunksPotential anonymity leak in Tor Browser Bundle via Key MapFor users of alternative key maps such as AZERTY, Dvorak, etc., the user's keymap can reveal personally identifiable information about an end-user. Using JavaScript, it is fairly trivial to identify a user's key map by comparing key code...For users of alternative key maps such as AZERTY, Dvorak, etc., the user's keymap can reveal personally identifiable information about an end-user. Using JavaScript, it is fairly trivial to identify a user's key map by comparing key codes and character codes against some fairly simple patterns to accurately determine the user's key map.
If packet insertion is accomplished between the Tor exit node and the destination site, malicious JavaScript can be injected which, when the user types, could determine their keymap. HTTPS on the destination site can help to prevent packet injection, but if the destination site itself is malicious or compromised, it would still remain possible to determine the user's keymap and store data about this interaction which could potentially identify a user in the end.
A fix for this would involve patching Tor Browser Bundle's Firefox to never send key codes or alternatively never send char codes to executing JavaScript. It's also possible to mitigate this by disabling JavaScript, but many sites depend on JavaScript for basic interaction with the site.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/5791Gather apparmor/selinux/seatbelt profiles for each component of TBB2022-11-30T16:20:35ZRoger DingledineGather apparmor/selinux/seatbelt profiles for each component of TBBIt's increasingly clear that shipping TBB without any "system call permissions" wrappers is an arms race that is too easy to lose. Bug 5741 is the latest of what will continue to be many instances.
The Tor wiki has a variety of instruc...It's increasingly clear that shipping TBB without any "system call permissions" wrappers is an arms race that is too easy to lose. Bug 5741 is the latest of what will continue to be many instances.
The Tor wiki has a variety of instructions on putting your TBB in a VM, or running it wrapped by apparmor, or somebody saying the word SELinux, etc.
We should gather all these instructions together, and start vetting them with the goal of integrating as many as we can into the main build processes, and providing the rest as "for experts, you can be even safer if".
We need a volunteer with good security taste to get this started. I could easily see this project being a bounty too.