The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-01-05T17:03:13Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19741favicon in searchbar popup uses catchall circuit2023-01-05T17:03:13ZArthur Edelsteinfavicon in searchbar popup uses catchall circuitTo reproduce:
* Set "torbutton.loglevel" to 3.
* Enter the word "test" in the searchbar. Click on the DuckDuckGo icon in the popup menu below to cause a search for "test" to be performed on DuckDuckGo. After the search is performed, a g...To reproduce:
* Set "torbutton.loglevel" to 3.
* Enter the word "test" in the searchbar. Click on the DuckDuckGo icon in the popup menu below to cause a search for "test" to be performed on DuckDuckGo. After the search is performed, a green "plus" symbol appears on the searchbar magnifying glass icon.
* Open the browser console, and clear it.
* Click on the searchbar again. An additional menu item appears, which contains the text `Add "DuckDuckGo (HTML)"` and a DuckDuckGo favicon.
* Examine the browser console. Log messages should appear as follows:
```
[07-22 22:38:01] Torbutton INFO: tor SOCKS: http://3g2upl4pq6kufc4m.onion/favicon.ico via --NoFirstPartyHost-chrome-browser.xul--:9bb8a61534faf1f952647a3537560fb0
GET
http://3g2upl4pq6kufc4m.onion/favicon.ico [HTTP/1.1 200 OK 0ms]
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
[07-22 22:38:02] Torbutton INFO: controlPort >> 650 STREAM 264 NEW 0 3g2upl4pq6kufc4m.onion:80 SOURCE_ADDR=127.0.0.1:52895 PURPOSE=USER
[07-22 22:38:02] Torbutton INFO: controlPort >> 650 STREAM 264 SENTCONNECT 15 3g2upl4pq6kufc4m.onion:80
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
[07-22 22:38:02] Torbutton INFO: controlPort >> 650 STREAM 264 SUCCEEDED 15 3g2upl4pq6kufc4m.onion:80
```
should be visible. I believe these messages are caused by
So it appears that the favicon display inside "add-engines" vbox of the search popup is being sent over the catchall circuit.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18866Rip mozTCPSocket out of Tor Browser2023-01-05T16:06:48ZGeorg KoppenRip mozTCPSocket out of Tor BrowserIn legacy/trac#18863 we disabled the usage of mozTCPSocket per preference. We might want to rip out that code as a defense in depth.In legacy/trac#18863 we disabled the usage of mozTCPSocket per preference. We might want to rip out that code as a defense in depth.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18813Tor Browser breaks rendering of fonts in applications launched from Tor Browser2022-11-30T16:47:36ZadrelanosTor Browser breaks rendering of fonts in applications launched from Tor BrowserTor Browser adds few additional environment variables which breaks `kdialog` and likely other applications also:
```
FONTCONFIG_PATH=/home/user/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig
LD_LIBRARY_PATH=/home/user/tor-browser_...Tor Browser adds few additional environment variables which breaks `kdialog` and likely other applications also:
```
FONTCONFIG_PATH=/home/user/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig
LD_LIBRARY_PATH=/home/user/tor-browser_en-US/Browser/TorBrowser/Tor/
```
screenshot:
https://i.imgur.com/1ItY3jR.png
([This issue was originally reported against QubesOS.](https://github.com/QubesOS/qubes-issues/issues/1892))
Perhaps do not modify environment variables for applications launched from Tor Browser?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18780Windows' numeric keyboard characters enter doesn't work.2022-11-29T13:53:49ZTracWindows' numeric keyboard characters enter doesn't work.Just tried to enter some extended characters into textarea using numeric keyboard as Windows allows it: pressing left Alt and typing char code, like: Alt-0151 enters m-dash, Alt-0171 for left double arrow quote, Alt-0187 for right quote,...Just tried to enter some extended characters into textarea using numeric keyboard as Windows allows it: pressing left Alt and typing char code, like: Alt-0151 enters m-dash, Alt-0171 for left double arrow quote, Alt-0187 for right quote, etc. No character appeared. But typing into location field does actually work, and I can type those chars in there and paste them into text fields and textareas in pages opened in TB.
Is this an intentional measure or a bug? Found two tickets possibly related to this: legacy/trac#16678, legacy/trac#15646.
OS: Windows 8
Tor Browser: 5.5.4
**Trac**:
**Username**: Unchquahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18532Now search.disconnect.me through catchall too2022-07-13T12:49:45ZbugzillaNow search.disconnect.me through catchall too[03-11 17:31:16] Torbutton INFO: tor SOCKS isolation catchall: https://search.disconnect.me/searchTerms/search?ses=Google&location_option=US&source=tor via --unknown--:75
Windows only?[03-11 17:31:16] Torbutton INFO: tor SOCKS isolation catchall: https://search.disconnect.me/searchTerms/search?ses=Google&location_option=US&source=tor via --unknown--:75
Windows only?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18166TBB continuously updates its Custom Destinations file on Win72022-07-12T21:06:29ZbugzillaTBB continuously updates its Custom Destinations file on Win7TBB continuously updates its Custom Destinations (def.: https://blogs.microsoft.co.il/sasha/2009/02/24/windows-7-taskbar-custom-destinations/) file (in **%appdata%\Microsoft\Windows\Recent**) on Win7.
Example: https://chromium-build-logs...TBB continuously updates its Custom Destinations (def.: https://blogs.microsoft.co.il/sasha/2009/02/24/windows-7-taskbar-custom-destinations/) file (in **%appdata%\Microsoft\Windows\Recent**) on Win7.
Example: https://chromium-build-logs.appspot.com/viewlog/raw/AMIfv94tusHalcqStZPT2jxqjdP-9rOkCcqjhLf2xB1BZab1hYhBql2FfdQI6I-CItcqXjQ5xWu23OF5KODrhcUxEKW35Bv_riDt1L_YIboliQjkrH98p6cwGg8bRd6VQvqrHG9M6yk-LNQVA24NrtaJAisGjKCTcLmS8oQ3cHXtYpBlUGMOykshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18087security.nocertdb -> false breaks mochitest https pages2023-01-05T17:47:45ZArthur Edelsteinsecurity.nocertdb -> false breaks mochitest https pagesWhen the `security.nocertdb` pref is enabled, mochitests that attempt to connect to `https://example.com` run into a "This connection is untrusted" error. We should try to fix this (and upstream to mozilla).When the `security.nocertdb` pref is enabled, mochitests that attempt to connect to `https://example.com` run into a "This connection is untrusted" error. We should try to fix this (and upstream to mozilla).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17123Request for certificate is sent over the catch-all circuit2023-01-05T16:36:14ZGeorg KoppenRequest for certificate is sent over the catch-all circuitThe request made to fetch a certificate of a page showing a certificate warning is sent over the catch-all circuit. I think it should be sent over the circuit of the page the user tried to visit originally instead.The request made to fetch a certificate of a page showing a certificate warning is sent over the catch-all circuit. I think it should be sent over the circuit of the page the user tried to visit originally instead.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16624Improper key passed to nsHttpChannel::DoInvalidateCacheEntry()?2023-01-05T16:36:29ZMike PerryImproper key passed to nsHttpChannel::DoInvalidateCacheEntry()?During the cache2 review in legacy/trac#13035, mcs noticed that an empty key was being passed to nsHttpChannel::DoInvalidateCacheEntry().
> nsHttpChannel::DoInvalidateCacheEntry() to use our modified (isolated) cache keys. That would inv...During the cache2 review in legacy/trac#13035, mcs noticed that an empty key was being passed to nsHttpChannel::DoInvalidateCacheEntry().
> nsHttpChannel::DoInvalidateCacheEntry() to use our modified (isolated) cache keys. That would involve passing a non-empty string as the second parameter to cacheStorage->AsyncDoomURI() within that method. This is not new code and not something we patched in the past... and Kathy and I do not understand the implications of not patching it. But it seems like the wrong key is being used there.
I replied:
> I have not dug through all of the eviction code (there sure are a lot of codepaths involved there), but my initial take is that since Mozilla has been using this same extension key to isolate caching for POST requests, it probably is not a serious issue to omit it, since the original code would have been experiencing similar problems even before our isolation made further use of this key...
We should ask Mozilla for an opinion. This may be a bug in their code, too.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16486about:cache page (disk entry) is confusing in Tor Browser2023-11-27T11:58:47ZGeorg Koppenabout:cache page (disk entry) is confusing in Tor Browser`about:cache` shows cache items stored in memory in the disk section as well which is quite confusing. Even though in the disk section it says:
```
Storage disk location: none, only stored in memory
```
it does not make sense to show m...`about:cache` shows cache items stored in memory in the disk section as well which is quite confusing. Even though in the disk section it says:
```
Storage disk location: none, only stored in memory
```
it does not make sense to show memory-only items in the disk section in the first place.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/15908Compose key doesn't work when GTK_IM_MODULE=xim2022-07-09T22:00:37ZLunarCompose key doesn't work when GTK_IM_MODULE=ximWhen `GTK_IM_MODULE=xim` is set in the environment when starting Tor Browser 4.5, the compose key will not work. Unsetting the variable will fix the issue.
This is on a Debian Wheezy system.
(I don't think I'm going dig deeper now that...When `GTK_IM_MODULE=xim` is set in the environment when starting Tor Browser 4.5, the compose key will not work. Unsetting the variable will fix the issue.
This is on a Debian Wheezy system.
(I don't think I'm going dig deeper now that I have a work-around.)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/15882Tor Browser shows up as Firefox in Ubuntu dash/launcher2022-07-09T21:59:27ZcypherpunksTor Browser shows up as Firefox in Ubuntu dash/launcherOn Debian (with Gnome), Tor Browser always showed up using the green, obvious Tor Browser icon (provided as tor-browser_en-US/Browser/browser/icons/mozicon128.png).
For some reason, on Ubuntu 14.04 64-bit with Unity (v 7.2.4) if I start...On Debian (with Gnome), Tor Browser always showed up using the green, obvious Tor Browser icon (provided as tor-browser_en-US/Browser/browser/icons/mozicon128.png).
For some reason, on Ubuntu 14.04 64-bit with Unity (v 7.2.4) if I start Tor Browser using the new "start-tor-browser.desktop" file, whether run from the terminal or by double-clicking, it simply attaches to the Firefox icon and treats it like a second instance of Firefox. It does not get its own icon using the provided "mozicon128.png".
Even when I drag the .desktop file into the launcher and click it, it still attaches the process to the Firefox icon.
This might lead to confusion for users who run Firefox in a normal session and Tor Browser concurrently and they might inadvertently enter information intended for TBB into their normal Firefox or vice versa.
As far as I can tell, it's a purely visual issue, but from a design perspective, I would think it'd be advantageous to keep the two identities as separate as possible, including in the launcher / dash.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/14939Support ipv6 addresses in Tor Circuit DIsplay2022-04-06T22:48:02ZArthur EdelsteinSupport ipv6 addresses in Tor Circuit DIsplayBridges and other nodes may have ipv6 addresses, and we need to fix the tor circuit display so that it handles these correctly.Bridges and other nodes may have ipv6 addresses, and we need to fix the tor circuit display so that it handles these correctly.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/14033Upgrade meek to 0.152020-06-27T14:41:23ZDavid Fifielddcf@torproject.orgUpgrade meek to 0.15The main reason for the upgrade is legacy/trac#12778, which is smaller HTTP headers for lower overhead.
Here's the diff between 0.11 (what is packaged currently) and 0.15:
https://gitweb.torproject.org/pluggable-transports/meek.git/di...The main reason for the upgrade is legacy/trac#12778, which is smaller HTTP headers for lower overhead.
Here's the diff between 0.11 (what is packaged currently) and 0.15:
https://gitweb.torproject.org/pluggable-transports/meek.git/diff/?id=0.15&id2=0.11https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13747Make sure tor browser handles mixed content in .onions correctly2023-01-05T16:56:03ZWilliam BudingtonMake sure tor browser handles mixed content in .onions correctlyThe .onion URL for a given THS instance is a fingerprint of the public key, thus ensuring authenticity of the service. For this reason, some assume the same security assurances for .onion addresses as they would for https, with the adde...The .onion URL for a given THS instance is a fingerprint of the public key, thus ensuring authenticity of the service. For this reason, some assume the same security assurances for .onion addresses as they would for https, with the added assurances that hidden services provide. For instance, the major browsers have chosen to not load http resources when accessing an https site, blocking mixed content. However, there is no protection against mixed content being loaded in the TBB for .onion addresses when they include resources from http URLs. For any .onion URL which includes http resources, an attacker controlling an exit node could perform a Man in the Middle attack, providing malicious javascript which modifies the content of the DOM.
One would hope that an http THS would never include remote resources from an http site if they would like to protect their users. In fact, one would hope that a THS would never load any resources at all from a source they do not control. But this is no guarantee that they won't. It seems like a good security measure to disallow http resources from being loaded in TBB.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13575Disable randomised Firefox HTTP cache decay user test groups2020-06-27T14:41:36ZIsis LovecruftDisable randomised Firefox HTTP cache decay user test groupsI need to look into it more, but I think we should be setting `browser.cache.frecency_experiment` to `-1` to [disable HTTP_CACHE_MISS_HALFLIFE_EXPERIMENT](https://bugzilla.mozilla.org/show_bug.cgi?id=986728#c3). Since we have Telemetry d...I need to look into it more, but I think we should be setting `browser.cache.frecency_experiment` to `-1` to [disable HTTP_CACHE_MISS_HALFLIFE_EXPERIMENT](https://bugzilla.mozilla.org/show_bug.cgi?id=986728#c3). Since we have Telemetry disabled, of course, Mozilla's experiment shouldn't be collecting any data on our users. However, if that pref is not set in `firefox.js` to `-1`, it will default to `0`. And if it's `0`, then it's randomised between `1` and `4` inclusive, setting different HTTP cache decay times for the four groups, which might make for a bit of a rough-edged fingerprinting mechanism.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13439Inspector raises the canvas prompt when hovering over images2020-06-27T14:41:42ZDavid Fifielddcf@torproject.orgInspector raises the canvas prompt when hovering over images1.Open any old page with an image, for instance https://blog.torproject.org/
2. Press Ctrl+Shift+I to open the Inspector.
3. Click the "Pick an element from the page" icon, the one that looks like ![pick.png](uploads/pick.png).
4. Hov...1.Open any old page with an image, for instance https://blog.torproject.org/
2. Press Ctrl+Shift+I to open the Inspector.
3. Click the "Pick an element from the page" icon, the one that looks like ![pick.png](uploads/pick.png).
4. Hover over an img element.
The "attempted to extract HTML5 canvas image data" prompt appears.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13027Make WebWorkers use spoofed navigator.* useragent values2020-06-27T14:41:56ZMike PerryMake WebWorkers use spoofed navigator.* useragent valuesWe spoof the navigator values through various general.useragent.override prefs. However, this object is now exposed to WebWorkers too, which may or may not be listening to these new prefs (because WebWorkers are special threads and have ...We spoof the navigator values through various general.useragent.override prefs. However, this object is now exposed to WebWorkers too, which may or may not be listening to these new prefs (because WebWorkers are special threads and have restricted access to much of XPCOM).
https://bugzilla.mozilla.org/show_bug.cgi?id=925847Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13026Verify screenX and screenY are spoofed sanely2020-06-27T14:41:56ZMike PerryVerify screenX and screenY are spoofed sanelyIn Firefox 28, window.screenX and window.screenY were changed to report CSS pixels instead of device pixels. We should ensure we're still properly reporting content window resolution here.In Firefox 28, window.screenX and window.screenY were changed to report CSS pixels instead of device pixels. We should ensure we're still properly reporting content window resolution here.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13025Lie about the screen orientation2020-06-27T14:41:56ZMike PerryLie about the screen orientationScreen orientation is now exposed as a JS property: https://developer.mozilla.org/en-US/docs/Web/API/Screen.orientation
We should probably make this property lie.Screen orientation is now exposed as a JS property: https://developer.mozilla.org/en-US/docs/Web/API/Screen.orientation
We should probably make this property lie.Georg KoppenGeorg Koppen