Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-06-17T20:21:17Zhttps://gitlab.torproject.org/legacy/trac/-/issues/164418-month-old Tor Browser offers to "Reset Tor Browser", removes extensions2022-06-17T20:21:17ZDavid Fifielddcf@torproject.org8-month-old Tor Browser offers to "Reset Tor Browser", removes extensionsI started an old copy of Tor Browser 4.0 I had in a directory. From file times it looks like it was last run on 2014-10-21, 8 months ago (today is 2015-06-24). When I started it, the about:tor page showed a banner at the bottom
It look...I started an old copy of Tor Browser 4.0 I had in a directory. From file times it looks like it was last run on 2014-10-21, 8 months ago (today is 2015-06-24). When I started it, the about:tor page showed a banner at the bottom
It looks like you haven't started Tor Browser in a while. Do you want to clean it up for a fresh, like-new experience? And by the way, welcome back!
with a button that says "Reset Tor Browser..."
When I click on the button, the browser restarts and gives me the plain Firefox start page, with the Firefox logo and everything. It looks like all the extensions are gone (HTTPS-Everywhere, NoScript, Torbutton, Tor Launcher). check.torproject.org says the browser is using Tor. I also got a banner offering to update to 5.0a2.
I was trying the instructions from [[doc/TorBrowser/Hacking#UsinganExistingTorProcess]] so I had run
```
export TOR_SOCKS_PORT=9050
export TOR_SKIP_LAUNCH=1
./start-tor-browser
```
I don't know if that had anything to do with it.https://gitlab.torproject.org/legacy/trac/-/issues/572fallback-consensus file impractical to use2022-06-17T18:25:28ZRoger Dingledinefallback-consensus file impractical to useWe can put the fallback-consensus in the tarball that results from 'make dist',
but it breaks 'make dist-rpm'.
Right now (0.2.0.12-alpha) it's commented out of src/config/Makefile.am
We need whatever voodoo it takes to let make dist-rp...We can put the fallback-consensus in the tarball that results from 'make dist',
but it breaks 'make dist-rpm'.
Right now (0.2.0.12-alpha) it's commented out of src/config/Makefile.am
We need whatever voodoo it takes to let make dist-rpm do its thing too, before
we can reenable it.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8435Ignore advertised bandwidths for flags once we have enough measured bandwidths2022-06-17T13:53:36ZAndrea ShepardIgnore advertised bandwidths for flags once we have enough measured bandwidthsOnce a dirauth sees a large enough fraction of nodes with measured bandwidths, it should ignore advertised bandwidths for purposes of assigning flags. That is, nodes without measured bandwidths should never get the Fast, Guard, HSDir fl...Once a dirauth sees a large enough fraction of nodes with measured bandwidths, it should ignore advertised bandwidths for purposes of assigning flags. That is, nodes without measured bandwidths should never get the Fast, Guard, HSDir flags, etc.
This is a follow-on to 8273.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6539Image cache isolation causes assert crash in debug builds (and other cases?)2022-06-16T02:51:54ZMike PerryImage cache isolation causes assert crash in debug builds (and other cases?)Turns out that the patch in #5742 crashes in debug builds at VerifyCacheSizes() in imgLoader.cpp:1613.
There might also be a crash on certain XUL dialog types that contain chrome images/icons. In non-debug builds I get a refcount issue ...Turns out that the patch in #5742 crashes in debug builds at VerifyCacheSizes() in imgLoader.cpp:1613.
There might also be a crash on certain XUL dialog types that contain chrome images/icons. In non-debug builds I get a refcount issue when pointing my new Firefox build at an old profile, or when running it with -P -no-remote.. Could be the fact that I re-use the same nsIURI pointer for two arguments in the XUL icon codepath, or could be something else.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/6564Enable DOM Storage and isolate it to url bar domain2022-06-16T02:51:54ZMike PerryEnable DOM Storage and isolate it to url bar domainDOM storage is currently disabled in TBB. We should be isolating it to url bar domain. See mozIThirdPartyUtil and #5742 for useful APIs.DOM storage is currently disabled in TBB. We should be isolating it to url bar domain. See mozIThirdPartyUtil and #5742 for useful APIs.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2875Spoof Desktop Resolution in TorBrowser2022-06-16T02:51:54ZMike PerrySpoof Desktop Resolution in TorBrowserWe currently have Javascript hooks in Torbutton to spoof our desktop resolution, but this information is now available due to CSS3 media queries. We need to patch Firefox at a deeper level to prevent any pieces of it from obtaining valid...We currently have Javascript hooks in Torbutton to spoof our desktop resolution, but this information is now available due to CSS3 media queries. We need to patch Firefox at a deeper level to prevent any pieces of it from obtaining valid desktop resolution information.
This could work as an about:config approach that tells the patch to either spoof the next largest common desktop size that is bigger than the window, or to a specific fixed size, or to the size of the content window (as if the content window only was the entire desktop).
We'll also want to try to remap mouse event coordinates back to this spoofed desktop:
https://developer.mozilla.org/en/DOM/Event/UIEvent/MouseEvent
Spoofing the content window to the desktop size is the cleanest approach that leaks the least information, but the Panopticlick test makes people believe that they are always unique because this is such a rare thing to do relative to the rest of the web, so people are always wrongly complaining we don't defend against Panopticlick :/TorBrowserBundle 2.3.x-stableMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3229Make content pref service memory-only + clearable2022-06-16T00:22:07ZMike PerryMake content pref service memory-only + clearableOur current blanket disable of site-specific zoom has very annoying effects on pages like wikipedia. If you zoom to view the text and then click on an anchor link, the zoom gets reset because it is not stored.
We should make this memory...Our current blanket disable of site-specific zoom has very annoying effects on pages like wikipedia. If you zoom to view the text and then click on an anchor link, the zoom gets reset because it is not stored.
We should make this memory only and clearable via an observer or pref.TorBrowserBundle 2.2.x-stableMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/12827Create preference to disable SVG2022-06-16T00:15:16ZMike PerryCreate preference to disable SVGWe should have a way to disable SVG suport in Firefox for the security slider. There currently is no pref in Firefox for this, so we will need to create one.We should have a way to disable SVG suport in Firefox for the security slider. There currently is no pref in Firefox for this, so we will need to create one.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/13019New locale fingerprinting capabilities in FF31ESR2022-06-15T02:45:00ZMike PerryNew locale fingerprinting capabilities in FF31ESRVarious element properties (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-type) as well as the String, Date, and Number objects now expose locale-specific functions.
Also, the Intl object exposes locale informatio...Various element properties (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-type) as well as the String, Date, and Number objects now expose locale-specific functions.
Also, the Intl object exposes locale information:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl
If extensions.torbutton.spoof_english is set, these functions should all behave as if the locale was en_US.Arthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/legacy/trac/-/issues/5926language info leaked by JS Date methods in Windows and Linux2022-06-15T02:45:00ZMike Perrylanguage info leaked by JS Date methods in Windows and LinuxIn greg's test at http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html, the Date string ends up localized to the user's language.
We should scrub it or remove it most likely. See also #5922 for info on the relevant source c...In greg's test at http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html, the Date string ends up localized to the user's language.
We should scrub it or remove it most likely. See also #5922 for info on the relevant source code paths.https://gitlab.torproject.org/legacy/trac/-/issues/27511Add New identity button to toolbar2022-05-26T01:52:40ZTracAdd New identity button to toolbarPlease, make possible to put a "new identity button" in the toolbar.
**Trac**:
**Username**: isnaiterPlease, make possible to put a "new identity button" in the toolbar.
**Trac**:
**Username**: isnaiterhttps://gitlab.torproject.org/legacy/trac/-/issues/26353First request after copying and pasting an URL in URL bar seems to go over th...2022-05-26T01:39:58ZGeorg KoppenFirst request after copying and pasting an URL in URL bar seems to go over the catch-all circuitIf one goes e.g. to our blog and copies and pastes a link from the Upcoming Events section (like https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh) and hits return then the first request seems to go over the catc...If one goes e.g. to our blog and copies and pastes a link from the Upcoming Events section (like https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh) and hits return then the first request seems to go over the catch-all circuit:
```
[06-12 08:47:21] Torbutton INFO: tor SOCKS: https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh via
--unknown--:d106e3543536c1d88e4b356a8d2644e8
[06-12 08:47:21] Torbutton INFO: tor SOCKS: https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh via
torproject.org:7ec24bef3562e08e7b096e5b1049cb49
```
If that's indeed the case we need to fix thathttps://gitlab.torproject.org/legacy/trac/-/issues/24421"Temporarily allow all this page" get inherited when New Identity is chosen.2022-05-18T23:54:20Zcypherpunks"Temporarily allow all this page" get inherited when New Identity is chosen.How to reproduce:
1. Open Tor Browser.
2. Select "High" Security Setting.
3. Go to https://github.com/
4. Click on NoScript icon and choose "Temporarilly allow all this page".
5. You can note that when the page gets refreshed the canvas...How to reproduce:
1. Open Tor Browser.
2. Select "High" Security Setting.
3. Go to https://github.com/
4. Click on NoScript icon and choose "Temporarilly allow all this page".
5. You can note that when the page gets refreshed the canvas prompt is displayed.
6. Select New Identity in the Torbutton.
7. Go to https://github.com/
8. You can notice that the canvas prompt is displayed (meaning JS is enabled, which in turn implies that "Temporarilly allow all this page" gets inherited when New Identity is chosen.)https://gitlab.torproject.org/legacy/trac/-/issues/19200HTML5 video not blocked with placeholder, plays automatically2022-05-18T23:36:09ZTracHTML5 video not blocked with placeholder, plays automaticallyIn Tor Browser 6.0a5, with security level set at Medium-Low or higher, HTML5 video that uses media source extensions (MSE) is able to load and play automatically, without being blocked by a click-to-play NoScript placeholder. The policy ...In Tor Browser 6.0a5, with security level set at Medium-Low or higher, HTML5 video that uses media source extensions (MSE) is able to load and play automatically, without being blocked by a click-to-play NoScript placeholder. The policy for the Medium-Low, Medium-High, and High security levels states that "HTML5 video and audio media become click-to-play via NoScript," but this bug breaks that security policy by allowing HTML5 MSE media to play unobstructed. The browser's attack surface may be increased due to exposure to this media.
I've tested on both OS X and Tails 2.4~rc1. The bug exists on both platforms. On OS X, I tested with a clean install of Tor Browser.
Regular HTML5 video that does not use MSE is unaffected by this bug and gets placeholder-blocked properly.
## Expected result:
HTML5 MSE video should not be allowed to play automatically in security level Medium-Low or higher, it should be replaced with a click-to-play placeholder by NoScript to block it until the user either clicks the placeholder or uses the NoScript toolbar button to allow it. This was the behavior in Tor Browser 5.5.5 and earlier.
## Steps to reproduce:
1. Click the Torbutton icon in the browser toolbar, select "Privacy and Security Settings..." and choose Medium-Low, Medium-High, or High security level.
2. Go to a site that has MSE video, such as any YouTube video, eg: https://www.youtube.com/watch?v=T07gkTc5Fcc
3. If Tor Browser is in High security mode, then allow scripts on the page via the NoScript toolbar button option "Temporarily allow all this page."
4. The video will start playing automatically. There is no NoScript placeholder that you click to start the video, it just starts playing.
**Trac**:
**Username**: potatohttps://gitlab.torproject.org/legacy/trac/-/issues/7255Prompt if Tor Browser is Maximized2022-05-18T23:26:29ZMike PerryPrompt if Tor Browser is MaximizedWe should display some kind of toolbar message or otherwise warn the user against maximizing their Tor Browser window, because maximization reveals monitor resolution and toolbar sizes.We should display some kind of toolbar message or otherwise warn the user against maximizing their Tor Browser window, because maximization reveals monitor resolution and toolbar sizes.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/247Tor doesn't seem to work with Network configuration2022-03-22T13:21:19ZTracTor doesn't seem to work with Network configurationRunning OS X 10.3.9 with Tor installed; Network settings pointing to Privoxy on 127.0.0.1, port 8118 for HTTP,
HTTPS, and Gopher. Using Safari 1.3, Camino 1.0b1 and Firefox 1.5 with SwitchProxy and the browser's Connection
settings poin...Running OS X 10.3.9 with Tor installed; Network settings pointing to Privoxy on 127.0.0.1, port 8118 for HTTP,
HTTPS, and Gopher. Using Safari 1.3, Camino 1.0b1 and Firefox 1.5 with SwitchProxy and the browser's Connection
settings pointing to Privoxy as well.
Connecting to ipid.shat.net/ using Safari or Camino shows an ip address in a different part of the country or
world, as expected. Using Firefox 1.5 with SwitchProxy turned off (Network settings for OS X are still enabled), I get an
ip address for my ISP, even though they're not running any Tor servers. If I use Network Utility to do a Whois lookup,
it also says I'm coming from my ISP; same if I go to www.dnsstuff.com (Java and JavaScript are off). Turning on SwitchProxy
(even while Network settings are enabled) and trying again gets me an IP address in a different part of the country or world,
as it should be.
This makes no sense, and it doesn't inspire confidence, since I get different results depending on which browser I'm using.
I followed the directions for installation and setup, so I can only presume it's a bug of some sort, perhaps with OS X, or Tor.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: dedwardshttps://gitlab.torproject.org/legacy/trac/-/issues/2511Tor will use an unconfigured bridge if it was a configured bridge last time y...2022-03-22T13:03:41ZRoger DingledineTor will use an unconfigured bridge if it was a configured bridge last time you ran TorIf you configure your Tor client with
```
usebridges 1
bridge 128.31.0.34:9009
```
and you run it and it works, then Tor will end up writing two things to disk: 1) a @purpose bridge descriptor for 128.31.0.34 in your cached-descriptors f...If you configure your Tor client with
```
usebridges 1
bridge 128.31.0.34:9009
```
and you run it and it works, then Tor will end up writing two things to disk: 1) a @purpose bridge descriptor for 128.31.0.34 in your cached-descriptors file:
```
@downloaded-at 2011-02-08 07:54:52
@source "128.31.0.34"
@purpose bridge
router bridge 128.31.0.34 9009 0 0
...
```
and 2) an entry guard stanza in your state file:
```
EntryGuard bridge 4C17FB532E20B2A8AC199441ECD2B0177B39E4B1
EntryGuardAddedBy 4C17FB532E20B2A8AC199441ECD2B0177B39E4B1 0.2.3.0-alpha-dev 2011-02-01 18:43:23
```
Then if you kill your Tor and run it with
```
usebridges 1
bridge 150.150.150.150:9009
```
it will successfully bootstrap -- using the bridge that worked before but isn't your requested bridge.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1090Warning about using an excluded node for exit2022-03-22T13:03:41ZSebastian HahnWarning about using an excluded node for exitQuite a few people have reported warnings in their logs when using
Exclude*Nodes in their torrc. We should track down why this happens,
and fix.
I opened the bug so we can keep track of ideas/problem reports. A
typical log line would be...Quite a few people have reported warnings in their logs when using
Exclude*Nodes in their torrc. We should track down why this happens,
and fix.
I opened the bug so we can keep track of ideas/problem reports. A
typical log line would be
[Warning] Requested exit node '..' is in ExcludeNodes or ExcludeExitNodes.. Using anyway.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8240Raise our guard rotation period, if appropriate2022-03-22T13:02:42ZRoger DingledineRaise our guard rotation period, if appropriateTariq's COGS paper from WPES 2012 shows that a significant component of guard churn is due to voluntary rotation, rather than actual network changes:
http://freehaven.net/anonbib/#wpes12-cogs
In short, if the target client makes sensiti...Tariq's COGS paper from WPES 2012 shows that a significant component of guard churn is due to voluntary rotation, rather than actual network changes:
http://freehaven.net/anonbib/#wpes12-cogs
In short, if the target client makes sensitive connections continuously every day for months, and you (the attacker) run some fast guards, the odds get pretty good that you'll become the client's guard at some point and get to do a correlation attack.
We could argue that the "continuously every day for months" assumption is unrealistic, so in practice we don't know how bad this issue really is. But for hidden services, it could well be a realistic assumption.
There are going to be (at least) two problems with raising the guard rotation period. The first is that we unbalance the network further wrt old guards vs new guards, and I'm not sure by how much, so I'm not sure how much our bwauth measurers will have to compensate. The second (related) problem is that we'll expand the period during which new guards don't get as much load as they will eventually get. This issue already results in confused relay operators trying to shed their Guard flag so they can resume having load.
In sum, if we raise the rotation period enough that it really results in load changes, then we could have unexpected side effects like having the bwauths raise the weights of new (and thus totally unloaded) guards to huge numbers, thus ensuring that anybody who rotates a guard will basically for sure get one of these new ones.
The real plan here needs a proposal, and should be for 0.2.5 or later. I wonder if we can raise it 'some but not too much' in the 0.2.4 timeframe though?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5968Improve onion key and TLS management2022-03-22T12:59:29ZMike PerryImprove onion key and TLS managementAs a best practice behavior, a relay should check that the onion key it tried to publish is actually the one it sees in the consensus in which it appears.
The onion key should also be what authenticates the TLS key (rather than the iden...As a best practice behavior, a relay should check that the onion key it tried to publish is actually the one it sees in the consensus in which it appears.
The onion key should also be what authenticates the TLS key (rather than the identity key, as it is now).
This would prevent some utility vectors of identity key theft, where a non-targeted upstream MITM attempts to use a relays identity to impersonate it in order to execute a tagging attack (#5456).Tor: unspecified