Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:13:10Zhttps://gitlab.torproject.org/legacy/trac/-/issues/4234Deploy experimental builds using the Firefox update process2020-06-16T01:13:10ZMike PerryDeploy experimental builds using the Firefox update processSure, it's probably not hardened against version downgrade attacks, interruption attacks, no-progress attacks, and maybe not even against CA compromises.
But it's gotta be better than nothing, and maybe it is easily serviceable into so...Sure, it's probably not hardened against version downgrade attacks, interruption attacks, no-progress attacks, and maybe not even against CA compromises.
But it's gotta be better than nothing, and maybe it is easily serviceable into something that will work for us.
Users are having a hard time manually working with our TBB packages if they want to preserve bookmarks, settings, and history, and are getting themselves into trouble by copying pieces of them over each other incorrectly while trying to manually upgrade:
https://lists.torproject.org/pipermail/tor-talk/2011-October/021771.html
I think any form of process that automates this for them is a step above status quo. It's just a matter of finding out if it is significantly less time+effort to deploy than Thandy, and what the security tradeoffs are.TorBrowserBundle 2.3.x-stableMark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/3944TBB prefs are set as user_prefs (may cause exceptions/settings errors?)2020-06-15T23:15:14ZMike PerryTBB prefs are set as user_prefs (may cause exceptions/settings errors?)All of the prefs we change in TBB appear to be set as user prefs. This makes it hard for me in Torbutton to tell if the user has changed a value.
We also have occasional reports from people that some prefs seem inexplicably set (such as...All of the prefs we change in TBB appear to be set as user prefs. This makes it hard for me in Torbutton to tell if the user has changed a value.
We also have occasional reports from people that some prefs seem inexplicably set (such as form fill options). Since user_prefs() sets a user value, it probably causes Firefox to emit observer events for each preference we change in this way. If one of them has an exception because the observer for that pref is buggy and/or tries to touch some not-yet-initialized piece of Firefox at startup, that could easily cause some prefs to fail to apply randomly.TorBrowserBundle 2.3.x-stableErinn ClarkErinn Clarkhttps://gitlab.torproject.org/legacy/trac/-/issues/3875TBB's Firefox should use optimistic data socks handshake variant2020-06-15T23:13:28ZRoger DingledineTBB's Firefox should use optimistic data socks handshake variantTor Proposal 181 lets the Tor client save a round-trip if the application speaks socks in a special way. In short, the application needs to send its data before hearing that the socks connection was successful. It's supported as of Tor 0...Tor Proposal 181 lets the Tor client save a round-trip if the application speaks socks in a special way. In short, the application needs to send its data before hearing that the socks connection was successful. It's supported as of Tor 0.2.3.3-alpha.
Ian originally had suggested to hack polipo to use a modified socks handshake. With polipo out of the picture for TBB, we should make Firefox itself do it.
Is this something Torbutton should (could) do, or should we patch the Firefox we include in TBB?TorBrowserBundle 2.3.x-stableMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3792Pre-launch Firefox and have it wait for Tor to connect2020-06-13T00:48:07ZAndrew LewmanPre-launch Firefox and have it wait for Tor to connectWe probably already have this complaint, but I couldn't find an open ticket in trac. Consider this user feedback.
Ali from Tehran, Iran left a long, detailed voice mail today. He says the #1 reason people don't use Tor in Iran is becaus...We probably already have this complaint, but I couldn't find an open ticket in trac. Consider this user feedback.
Ali from Tehran, Iran left a long, detailed voice mail today. He says the #1 reason people don't use Tor in Iran is because it takes too long to view a webpage. He's measuring the time as from the time he clicks on the 'Start tor browser' icon in windows xp through the time he can type in a url. It's taking him 60-90 seconds on average. He says he did 10 trials over three days.
He double-clicks 'start tor browser' and waits. He sees the vidalia control panel and the 0-100% progress bar, which takes 40 seconds on average in Tehran, and then nothing happens for 20 seconds, and then firefox starts up, and roughly another 10-30 seconds for check.torproject.org to load and tell him he's using tor. He can now type in a url and go to a website, such as balatarin.com, which will take anywhere from 10-30 seconds to load in TBB.
He compares this to his VPN. He clicks on the VPN icon, in 5 seconds it is connected. He starts up Firefox in 2 seconds. It takes 3 seconds to load the same site as he used to test before, balatarin.com.
10 second vs. 60-90 means no contest in his mind.TorBrowserBundle 2.3.x-stableMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3347Permanently Opt-In to YouTube's HTML5 Beta Test2020-06-15T23:23:57ZTracPermanently Opt-In to YouTube's HTML5 Beta TestAn option to permanently opt-in to YouTube's HTML5 beta test would greatly enhance the Torbutton user experience. Bonus points if the option would work even if cookies are disabled.
**Trac**:
**Username**: katmagicAn option to permanently opt-in to YouTube's HTML5 beta test would greatly enhance the Torbutton user experience. Bonus points if the option would work even if cookies are disabled.
**Trac**:
**Username**: katmagicTorBrowserBundle 2.2.x-stableMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/18044Prompt if Tor Browser is zoomed2020-06-16T01:27:52ZbugzillaPrompt if Tor Browser is zoomedDon't we need to display some kind of toolbar message or otherwise warn the user against zooming their Tor Browser window like in #7255?
Because zooming changes resolution to very rare values.Don't we need to display some kind of toolbar message or otherwise warn the user against zooming their Tor Browser window like in #7255?
Because zooming changes resolution to very rare values.https://gitlab.torproject.org/legacy/trac/-/issues/10820Create preferences for Firefox patches that need them2020-06-15T23:18:09ZMike PerryCreate preferences for Firefox patches that need themWe have several patches that could use a pref to control if them if they are to be enabled.
Ideally, there would have be a pref to control each one so that it only applies to private browsing mode windows (though this would could also b...We have several patches that could use a pref to control if them if they are to be enabled.
Ideally, there would have be a pref to control each one so that it only applies to private browsing mode windows (though this would could also be broken off into separate tickets if it is substantial).
This ticket will serve as the parent ticket for tickets for prefs for our individual patches.
Feel free to file child tickets for any of those patches. All patches that need prefs are also fair game for any bounty programs or interview processes we may run.
Our patch set can be perused at:
https://gitweb.torproject.org/tor-browser.git/shortlog/refs/heads/tor-browser-24.3.0esr-1
An additional Google Doc with more information and Tor Trac and Mozilla Bugzilla bug numbers can be found at:
https://docs.google.com/spreadsheet/ccc?key=0AroPYigJXMK4dFhzUGl5eFFkY09XbjBSTlNVS3o2SWc
Not all patches obviously require prefs and/or private browsing mode detection, but there are many that do (especially the fingerprinting and isolation patches).https://gitlab.torproject.org/legacy/trac/-/issues/7561Contents of FTP requests are cached and not isolated to the URL bar origin2020-06-15T23:15:04ZGeorg KoppenContents of FTP requests are cached and not isolated to the URL bar originContents of FTP requests can get cached but are currently not isolated to the URL bar origin which contradicts the goal of section 3.5.2 of the Tor Browser design documentation. The relevant code is here: https://mxr.mozilla.org/mozilla-...Contents of FTP requests can get cached but are currently not isolated to the URL bar origin which contradicts the goal of section 3.5.2 of the Tor Browser design documentation. The relevant code is here: https://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/ftp/nsFtpConnectionThread.cpp
There are two things to note:
1) This caching is working a bit differently than the familiar HTTP caching. E.g. are there no E-Tags, no headers involved which makes a scalable exploitation much harder (that's the only reason why I think the prio is normal) IMO.
2) Furthermore, only directory listings can get cached, not "normal" files like CSS or JS files loaded via FTP.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/7495Create browser-based update notification mechanism2020-06-13T01:48:06ZMike PerryCreate browser-based update notification mechanismThe check.torproject.org update notification has several problems. It's web-based, overloaded, and unmaintained.
From a usability standpoint, I think I like the idea of an ever-present notification ribbon/toolbar thing on *all* windows ...The check.torproject.org update notification has several problems. It's web-based, overloaded, and unmaintained.
From a usability standpoint, I think I like the idea of an ever-present notification ribbon/toolbar thing on *all* windows rather than a popup that appears only when the check interval expires, so long as it can't be confused with something from the content window.
Note, we'll also want to make sure that such a ribbon does not change the size of the resolution values from your CSS + window.screen patches... This might actually be fairly tricky in practice, due to there not being a lot of slack in the current window sizing code in Torbutton ( https://gitweb.torproject.org/torbutton.git/blob/master:/src/chrome/content/torbutton.js#l4358). See also #6146, for example... We could handle this issue by simply giving a larger buffer for maxHeight in that function, though.
Another option could be some sort of icon hint in the Toolbar (for example, Google Chrome places red up arrow over it's 'menu vent'), but that is even more likely to get ignored.
In either case, the notification should provide a link to the TBB download page, and should pass the OS and architecture to this page in the form of an anchor/fragment (see #4238).Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/7494Create local homepage for TBB2020-06-15T23:28:05ZMike PerryCreate local homepage for TBBcheck.torproject.org is unmaintained and overloaded (see #6156). We've rate-limited the version check, but we still need a homepage for our browser to use instead.
We've got the work from #3749 (see http://jmtodaro.com/tor/check/success...check.torproject.org is unmaintained and overloaded (see #6156). We've rate-limited the version check, but we still need a homepage for our browser to use instead.
We've got the work from #3749 (see http://jmtodaro.com/tor/check/success.html), but it's way too busy and overloaded with text for a homepage. We should remove the infoboxes, most of the text, and the footer. In fact, I think the only thing we should keep is the portion of that page up to and including the search box (which should point to StartPage, not DDG).
We also need to use DTD strings from Torbutton rather that flat-text (for translation).Kathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/7265Only display Canvas message for first parties; simply log third parties2020-06-15T23:15:21ZMike PerryOnly display Canvas message for first parties; simply log third partiesIn #6253, we created a prompt before allowing sites to extract image data from the HTML5 canvas. We did this for fingerprinting reasons.
However, since deploying that patch, I have noticed the warning on at least two random sites.
Unfo...In #6253, we created a prompt before allowing sites to extract image data from the HTML5 canvas. We did this for fingerprinting reasons.
However, since deploying that patch, I have noticed the warning on at least two random sites.
Unfortunately, the warning is not reproducible, and likely came from a particular 3rd party advertising network. Extra unfortunately, we display only the first party URL in the warning, for usability reasons and for first party-jailed content permissions.
We should provide some mouseover tooltip or other way of determining the full third party url in such warning boxes.
We need to be careful that such a notification does not clutter the warning box or confuse users, and we also need to be mindful of string updates, since the strings are stored in Torbutton but are used in Tor Browser (for translation expedience).Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/7256Explore zoom-based alternatives to fixed window sizes2020-06-15T23:22:30ZMike PerryExplore zoom-based alternatives to fixed window sizesRight now, we set the size of new Tor Browser windows such that their content area is a 200x100 multiple. We also lie to content that the entire desktop resolution is this size.
However, this potentially leaks information for users who ...Right now, we set the size of new Tor Browser windows such that their content area is a 200x100 multiple. We also lie to content that the entire desktop resolution is this size.
However, this potentially leaks information for users who maximize their browser windows, as such windows will no longer be rounded.
We could play with zooming such that maximized windows do not reveal Firefox decoration sizes. We could also set the zoom level automatically such that we end up with a content window size of a 200x100 multiple as well.
Not sure how complicated this will be. See also #7255 for a potentially simpler stopgap.https://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/6577WebSockets seem totally broken by Firefox SOCKS settings2020-06-15T23:14:40ZMike PerryWebSockets seem totally broken by Firefox SOCKS settingshttp://html5demos.com/web-socket is failing on both TBB 2.2.x and 2.3.x. I also tested a Vanilla FF14 with SOCKS proxy settings, and the socket also breaks there, too.
This is thus probably an upstream Firefox bug. We should at least fi...http://html5demos.com/web-socket is failing on both TBB 2.2.x and 2.3.x. I also tested a Vanilla FF14 with SOCKS proxy settings, and the socket also breaks there, too.
This is thus probably an upstream Firefox bug. We should at least file a bugzilla bug and bring it to someone's attention, I guess.https://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/6528Combine cache isolation patches and bind to pref2020-06-15T23:14:35ZMike PerryCombine cache isolation patches and bind to prefWe have two cache isolation patches that we should try to get merged upstream, especially since one of them is a crazy large change to the image cache operation and is likely to generate conflicts in future releases.
However, the patche...We have two cache isolation patches that we should try to get merged upstream, especially since one of them is a crazy large change to the image cache operation and is likely to generate conflicts in future releases.
However, the patches need work before they can be merged. In addition to the pref, we'll want to make the normal cache isolation built-in, instead of relying on torbutton's stanford-safecache.js and associated observers.
Someone will probably also need to write/updated tests. Bleh.
Getting stuff like this polished and merged is a non-trivial amount of work. At a guess, I'd say around 3 to 4 days worth in total?https://gitlab.torproject.org/legacy/trac/-/issues/6458Double-key HSTS for third party content2020-06-15T23:14:32ZMike PerryDouble-key HSTS for third party contentWith proper cache+identifier siloing to url bar origin, it is no longer a security issue to allow 3rd party content from HSTS urls to get loaded from non-HSTS sites. Therefore, we can disable HSTS enforcement for third parties in this ca...With proper cache+identifier siloing to url bar origin, it is no longer a security issue to allow 3rd party content from HSTS urls to get loaded from non-HSTS sites. Therefore, we can disable HSTS enforcement for third parties in this case.
This will eliminate a super-cookie vector that HSTS creates (registering 32 domains, using HSTS for each domain as a bit).
This is going to be a painful patch to write, though...https://gitlab.torproject.org/legacy/trac/-/issues/6431Torbutton should have a downward arrow menu hint2013-01-08T14:52:52ZMike PerryTorbutton should have a downward arrow menu hintWe've had issues with people mistaking Vidalia's New Identity with Torbutton's New Identity (https://lists.torproject.org/pipermail/tor-qa/2012-June/000014.html), which we hope that #5277 will improve.
However, the root issue might be ...We've had issues with people mistaking Vidalia's New Identity with Torbutton's New Identity (https://lists.torproject.org/pipermail/tor-qa/2012-June/000014.html), which we hope that #5277 will improve.
However, the root issue might be a lack of any hint that Torbutton actually provides a menu now if you click on it.. A downward arrow next to the button should help provide that hint.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/6428Replace the NoScript Snake with a less scary click-to-play logo2020-06-13T01:35:38ZMike PerryReplace the NoScript Snake with a less scary click-to-play logoI'm not 100% sure, but I think that with some XUL gymnastics, we should be able to replace the NoScript Click-To-Play Snake barrier with a less scary play button and a localized "Click to Play" string on a dark grey background instead of...I'm not 100% sure, but I think that with some XUL gymnastics, we should be able to replace the NoScript Click-To-Play Snake barrier with a less scary play button and a localized "Click to Play" string on a dark grey background instead of the jarring puke-tan we have now.
We could also patch NoScript during TBB build, I guess.. But patching it dynamically from Torbutton might actually be less painful and more stable.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/6156Rate limit hit of check.tpo on 'new identity' in Tor Browser2020-06-13T02:14:17ZAndrew LewmanRate limit hit of check.tpo on 'new identity' in Tor BrowserRemove hit of check.tpo on 'new identity' in Tor Browser. Since this new feature went live a few weeks ago, the requests per second on check.tpo has doubled and shows no signs of abating. The server is increasingly busy. See https://muni...Remove hit of check.tpo on 'new identity' in Tor Browser. Since this new feature went live a few weeks ago, the requests per second on check.tpo has doubled and shows no signs of abating. The server is increasingly busy. See https://munin.torproject.org/torproject.org/sergii.torproject.org/apache_accesses.html (use tor-guest username and anything for the password). The next time the server crashes, everyone will be sad, even more so than before.
Option two is to remove check.tpo completely and have it done via the browser.Mike PerryMike Perry