commit 6becf9c072a8111f1a8a68c5f1c2e4fbf359a722 Author: Georg Koppen gk@torproject.org Date: Fri Sep 21 10:29:36 2018 +0000
Starting Tor Browser proposals --- audits/FF31_NETWORK_AUDIT | 2 +- proposals/001-process.txt | 119 ++++++++++++++ proposals/100-onion-location-header.txt | 124 ++++++++++++++ proposals/101-security-controls-redesign.txt | 234 +++++++++++++++++++++++++++ 4 files changed, 478 insertions(+), 1 deletion(-)
diff --git a/audits/FF31_NETWORK_AUDIT b/audits/FF31_NETWORK_AUDIT index 163a4e6..c575dec 100644 --- a/audits/FF31_NETWORK_AUDIT +++ b/audits/FF31_NETWORK_AUDIT @@ -75,7 +75,7 @@ Direct paths to DNS resolution: + nsDNSService::AsyncResolve + Patched for safety + nsHostResolver::ResolveHost - + Only used by nsDNSService + + Only used by nsDNSService2
Misc UDP (SOCK_DGRAM, PR_DESC_SOCKET_UDP): + PR_DESC_SOCKET_UDP diff --git a/proposals/001-process.txt b/proposals/001-process.txt new file mode 100644 index 0000000..fa0fffc --- /dev/null +++ b/proposals/001-process.txt @@ -0,0 +1,119 @@ +Filename: 001-process.txt +Title: The Tor Browser Proposal Process +Author: Georg Koppen +Created: 21-Sep-2018 +Status: Meta + +Overview: + + This document describes how Tor Browser proposals work. It heavily borrowed + and copied from the Tor proposal process. + + This is an informational document. + +Motivation: + + Previously, our process for implementing complex features possibly including + the expertise of different teams consisted of discussions on IRC, our bug + tracker, and at informal sessions at our developer meetings. While this worked + more or less it's hard to keep track of the status of various ideas and it + makes it more difficult to reason about their pros and cons. Tor Browser + proposals should help address those issues and aid in deciding which ideas to + implement and how, and which not. + +How new proposals get added: + + Once an idea has been proposed on the tbb-dev (or if relevant: the tor-dev) + development list, a properly formatted (see below) draft exists, and rough + consensus within the active development community exists that this idea + warrants consideration, the proposal editors will officially add the proposal. + + To get your proposal in, send it to the tbb-dev mailing list. + + The current proposal editors are Georg Koppen. + +What should go in a proposal: + + Every proposal should have a header containing these fields: + Filename, Title, Author, Created, Status, Ticket. + + These fields are optional but recommended: + Target, Implemented-In. + + The Target field should describe which version the proposal is hoped to be + implemented in (if it's Open or Accepted). The Implemented-In field should + describe which version the proposal was implemented in (if it's Finished or + Closed). The Ticket field should be a ticket number referring to Tor's + canonical bug tracker (e.g. "#21952" refers to + https://bugs.torproject.org/21952) or to a publicly accessible URI where one + may subscribe to updates and/or retrieve information on implementation + status. + + The body of the proposal should start with an Overview section explaining + what the proposal's about, what it does, and about what state it's in. + + After the Overview, the proposal becomes more free-form. Depending on its + length and complexity, the proposal can break into sections as appropriate, + or follow a short discursive format. Every proposal should contain at least + the following information before it is "ACCEPTED", though the information + does not need to be in sections with these names. + + Motivation: What problem is the proposal trying to solve? Why does this + problem matter? If several approaches are possible, why take this one? + + Design: A high-level view of what the new or modified features are, how the + new or modified features work, how they interoperate with each other, and + how they interact with the rest of Tor Browser. This is the main body of + the proposal. + +Proposal status: + + Open: A proposal under discussion. + + Accepted: The proposal is complete, and we intend to implement it. After this + point, substantive changes to the proposal should be avoided, and regarded + as a sign of the process having failed somewhere. + + Finished: The proposal has been accepted and implemented. After this point, + the proposal should not be changed. + + Rejected: We're not going to implement the feature as described here, though + we might do some other version. See comments in the document for details. + The proposal should not be changed after this point; to bring up some other + version of the idea, write a new proposal. + + Draft: This isn't a complete proposal yet; there are definite missing pieces. + Please don't add any new proposals with this status; put them in the "ideas" + sub-directory instead. + + Needs-Revision: The idea for the proposal is a good one, but the proposal as + it stands has serious problems that keep it from being accepted. See + comments in the document for details. + + Dead: The proposal hasn't been touched in a long time, and it doesn't look + like anybody is going to complete it soon. It can become "Open" again if it + gets a new proponent. + + Needs-Research: There are research problems that need to be solved before it's + clear whether the proposal is a good idea. + + Meta: This is not a proposal, but a document about proposals. + + Reserve: This proposal is not something we're currently planning to + implement, but we might want to resurrect it some day if we decide to do + something like what it proposes. + + Informational: This proposal is the last word on what it's doing. + It isn't going to turn into a spec unless somebody copy-and-pastes it into + a new spec for a new subsystem. + + Obsolete: This proposal was flawed and has been superseded by another + proposal. See comments in the document for details. + + The editors maintain the correct status of proposals, based on rough + consensus and their own discretion. + +Proposal numbering: + + Numbers 000-099 are reserved for special and meta-proposals. 100 and up + are used for actual proposals. Numbers aren't recycled. diff --git a/proposals/100-onion-location-header.txt b/proposals/100-onion-location-header.txt new file mode 100644 index 0000000..23a4450 --- /dev/null +++ b/proposals/100-onion-location-header.txt @@ -0,0 +1,124 @@ +Filename: 100-onion-location-header.txt +Title: Onion redirects using Onion-Location HTTP header +Author: George Kadianakis +Created: 02-02-2018 +Status: Open +Ticket: #21952 + +1. Motivation: + + Lots of high-profile websites have onion addresses these days (e.g. Tor, + NYT, blockchain, ProPublica). All those websites seem confused on what's + the right way to inform their users about their onion addresses. Here are + some confusion examples: + a) torproject.org does not even advertise their onion address to Tor users (!!!) + b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion + address and completely wrecking the UX (loses URL params, etc.) + c) ProPublica has a "Browse via Tor" section which redirects to the onion site. + + Ideally there would be a consistent way for websites to inform their users + about their onion counterpart. This would provide the following positives: + + Tor users would use onions more often. That's important for user + education and user perception, and also to partially dispell the darkweb myth. + + Website operators wouldn't have to come up with ad-hoc ways to advertise + their onion services, which sometimes results in complete breakage of + the user experience (particularly with blockchain) + + This proposal specifies a simple way forward here that's far from perfect, + but can still provide benefits and also improve user-education around onions + so that in the future we could employ more advanced techniques. + + Also see Tor ticket #21952 for more discussion on this: + https://trac.torproject.org/projects/tor/ticket/21952 + +2. Proposal + +2.1. Redirection method + + We introduce a new HTTP header called "Onion-Location" with the exact same + restrictions and semantics as the Location HTTP header. Websites can use the + Onion-Location HTTP header to specify their onion counterpart, in the same + way that they would use the Location header. + + Example: + Onion-Location: http://vwc43ag5jyewlfgf.onion + +2.2. Browser logic + + The Tor Browser intercepts the Onion-Location HTTP header (if any) and + informs the user of the existence of the onion site, giving them the option + to visit it. Tor Browser only does so if the header is served over HTTPS. + + Tor Browser should inform the user about the onion in a non-intrusive way + (e.g. an infobar below the address bar), it should also provide a way for + the user to visit the onion, and a button that offers more information about + onions. + + Browsers that don't support Tor SHOULD ignore the Onion-Location header. + +3. Drawbacks + +3.1. No security/performance benefits + + While we could come up with onion redirection proposals that provide + security and performance benefits, this proposal does not actually provide + any of those. + + As a matter of fact, the security remains the same as connecting to normal + websites, since for this proposal to work we need to trust their HTTP headers, + and the user might have already provided identifying information + (e.g. cookies) to the website. The performance is worse than connecting to a + normal website, since Tor first needs to connect to the website, get its + headers, and then finally connect to the onion. + + Still _all_ the website approaches mentioned in the "Motivation" section + suffer from the above drawbacks, and sysadmins still come up with ad-hoc + ways to inform users about their onions. So this simple proposal will still + help those websites and also pave the way forward for future auto-redirect + techniques. + +3.2. Defining new HTTP headers is not the best idea + + This proposal defines a new non-standard HTTP header. This is not great + because it makes Tor into a "special" thing that needs to be supported with + special headers. However, the fact that it's a new HTTP header that only + works for Tor is a positive thing since it means that non-Tor browsers will + just ignore it. + + Furthermore, another drawback is that this HTTP header will increase the + bandwidth needlessly if it's also served to non-Tor clients. Hence websites + with lots of client traffic are encouraged to use tools that detect Tor + users and only serve the header to them (e.g. tordnsel). Website operators + should be aware that tools like tordnsel have false positive potential (they + might treat Tor users as non-Tor users) which will result in not sending + them the Onion-Location header. + + Finally, websites can also detect Tor users (as discussed in the above + paragraph) and redirect them using the Location header, thus triggering a + non-prompting redirect. Websites doing so should consider the potential user + confusion of being redirected to an odd-looking domain. The Onion-Location + mechanism offered in this proposal is designed to provide a + browser-supported option to consistently offer an onion service in a + hopefuly less-confusing way. + +4. The future + + As previously discussed, this is just a simple proposal to introduce the + redirection concept to people, and also to help some sysadmins who are + currently coming up with weird ways to inform people about their + onions. It's not the best way to do this, but it's definitely one of the + simplest ways. + + In the future we could implement more advanced auto-redirect proposals like: + + a) Have a "domains to onions" map into HTTPS-everywhere and have the + extension do the autoredirects for us (performance benefits, and security + benefits under many threat models). + + b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested + by comment:42 in #21952. + + But both of the designs above require non-trivial engineering/policy work + and would still confuse people. So I think starting with a simple approach + that will educate users and then moving to more advanced designs is a more + normative way to go. diff --git a/proposals/101-security-controls-redesign.txt b/proposals/101-security-controls-redesign.txt new file mode 100644 index 0000000..3321c56 --- /dev/null +++ b/proposals/101-security-controls-redesign.txt @@ -0,0 +1,234 @@ +Filename: 101-security-controls-redesign.txt +Title: Redesign of Tor Browser's Security Controls +Author: Georg Koppen +Created: 5-Apr-2018 +Status: Open +Ticket: #25658 + +1 Introduction + + Tor Browser is well-known for its defenses against web tracking and + fingerprinting. However, providing Tor users just a privacy-enhanced + browser is often not enough to safeguard against deanonymization + attacks as those protections might simply get bypassed by exploiting + browser vulnerabilities. Tor Browser therefore offers several security + enhancements as well to reduce that risk. Most of those features are + provided by extensions which Tor Browser includes, namely Torbutton, + NoScript, and HTTPS Everywhere. + +1.1 Motivation + + By default Torbutton, NoScript, and HTTPS Everywhere are visible on + the toolbar in Tor Browser and there is no hint about possible + security enhancements, with the exception of a notification bar shown + on first start and pointing to our security slider. This has a number + of suboptimal outcomes which this proposal seeks to address: + + a) Security controls are scattered over and within different + extensions. That makes it hard to understand which knobs a user + could turn to improve their security settings while not being + exposed to additional fingerprinting risks. + b) The toolbar gets cluttered with three additional icons that provide + access to both per-site and global security settings. This is + confusing to users. Part of the confusion stems from mixing + non-global with global security controls on the toolbar not + indicating which of them just affect a particular website while + others affect the whole browser session. Another part is that users + feel the need to navigate through different levels of extension + menus to make basic adjustments to their security level. + c) There is the security vs. usability trade-off and little incentives + to change the default which comes with Tor Browser. That results in + users just staying on the lowest security level while at least some + of them could get convinced to raise that level if we managed to + provide an improved experience around our security controls, both + functionality- and UX-wise. + +1.2 The State of the Security Controls + + That is how the toolbar in Tor Browser looks like currently: + + ---------------------------------------------------------------------- + | --- --- ------------------------- --------------- --- --- | + | |N| |T| | URL bar | | Search bar | |H| |M| | + | --- --- ------------------------- --------------- --- --- | + ---------------------------------------------------------------------- + + N = NoScript button + T = Torbutton button + H = HTTPS Everywhere button + M = (Hamburger) Menu button + + We include HTTPS Everywhere to help against potential Tor Exit node + eavesdroppers and active attackers. To provide users with optional + defense-in-depth against JavaScript and other potential exploit + vectors, we use NoScript modifying some of its defaults[1]. Torbutton + includes the security slider which is meant to give users an easy way + to adjust their security level from Standard to Safest, depending on + their perceived needs. + +2 Proposal + + Generally, items on the toolbar serve two important purposes: they are + shortcuts to features often used and they inform about current state. + With that in mind we can think about redoing our toolbar helping that + way with issues outlined in 1.1 a) and b). The remaining problems + (part of 1.1 b) and 1.1 c)) will be addressed in section 2.2, 3.3, and + follow-up proposals. + +2.1 Restructuring the Toolbar + +2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar + + I'd propose we remove both NoScript and HTTPS Everywhere from the + toolbar and leave Torbutton on it for now: + + Torbutton serves a number of purposes and access to security settings + is just one of them. Moreover, we are in the process of restructuring + at least part of its functionality right now[2] and more will likely + happen in the future in this area. We can think about whether + Torbutton should remain on the toolbar after that transition is done. + + HTTPS Everywhere has the option to block all unencrypted requests and + apart from that is just enforcing HTTPS connections according to the + rulesets it ships, which is our default. There is not much gain + security-wise leaving it on the toolbar and users might just be + confused by the "Block all unencrypted requests" option. I'd argue as + well that the status indicator is not important enough to justify + precious space on the toolbar either. + + NoScript comes with a myriad of configuration options. We try to + abstract that away by shipping a list of defaults for Tor Browser[1]. + But still having NoScript easily accessible makes it dangerous to + choose the wrong option, especially as the majority of its + functionality does not need to be exposed for Tor Browser users. + Moreover, the scary warning icon which is visible when NoScript + allows JavaScript is highly confusing to users as we ship this + configuration as our default. Removing the icon from the toolbar + should solve those two problems. We might want to think about exposing + the small amount of functionality which especially users with the + security slider set to "Safest" might need: managing finer-grained + script control. See section 2.2 for that. + +2.1.2 Showing Security Slider State + + We essentially have one tool we want to promote to deal with security + settings: the security slider. Keeping in mind that icons on the + toolbar serve as well the purpose of showing state of important + settings, we could think about providing an own toolbar button for the + security slider. We could use an icon similar to the one suggested by + ninavizz[3] or come up with a different solution. + + However, being able to easily adjust the slider level is risky as it + affects all the tabs and windows in a session. It might lead to + confusion as to whether the settings are applied globally or just for + a tab in question, which is error-prone. To mitigate that problem we + could at least warn users about the possible danger and provide the + option to acquire a New Identity right after changing the security + slider level. Doing so is a good idea anyway, but might not be enough + to justify exposing security slider functionality on the toolbar. + + We'll add a security settings button to the toolbar which shows the + current slider state but, once clicked on, opens an about:preferences + pane in a new tab which contains the security slider. That way we + make the current slider state easily visible while avoiding the risk + of accidentally changing it. Moreover, having it as an option on + Firefox's preferences pane reinforces the idea of slider settings + being applied to the whole session and not just to a particular tab or + window. + +2.1.3 Reorganizing the Toolbar + + Taking the preceding chapters into account this leaves us with two + toolbar buttons for the Tor Browser toolbar: the one from the + Torbutton extension and the button for the security settings. + Following the toolbar layout of Firefox we should move both buttons to + the right, between the search bar and the menu button. + + Now, the new toolbar would look like: + + ---------------------------------------------------------------------- + | -------------------------------- -------------- --- --- --- | + | | URL bar | | Search bar | |T| |S| |M| | + | -------------------------------- -------------- --- --- --- | + ---------------------------------------------------------------------- + + T = Torbutton button + S = Security Settings button + M = (Hamburger) Menu button + + Note: The reorganized toolbar has the additional benefit that no + per-site state is shown anymore on it, which should lead to less + confusion about whether the settings visible there apply globally or + not. + +2.2 Dealing with Per-Site Security Settings + + There are a number of features disabled on higher security settings as + they are potentially dangerous, yet sometimes users need or want to + allow them anyway. So far, these options were exposed by click-to-play + buttons or directly in the NoScript user interface accessible over the + toolbar button. + + With NoScript gone from the toolbar the click-to-play options remain, + but easily allowing JavaScript per site and making the status of + NoScript related settings visible is not available anymore. To solve + this I'd propose to follow the path we are currently taking with our + circuit display redesign[2]: we are moving site specific settings into + the URL bar. + + One way to do that would be to use the Permissions section which opens + after clicking on the "i" icon in the URL bar. However, while showing + the security permissions the user has granted there (too) is a good + idea, it does not solve the problem of easily allowing e.g. JavaScript + on a website, and seeing its status without the need to click on any + button. We could have small icons on the right side of the URL bar + accomplishing that, though. That way, users could easily see if they + had JavaScript, or WebGL, or ... enabled on that particular website in + case they are on higher security levels. Moreover, they would be able + to adjust those permissions quickly without the need to deal with any + NoScript user interface or additional menus just by toggling those + icons. + + By default only the option to temporarily allow JavaScript would be + visible. All the click-to-play features could show up once there is a + respective object embedded on a website. We should refrain from + exposing icons for every single "active content" in the URL bar, + though. Rather, besides the button for temporarily allowing JavaScript + we would only add one additionally, which is responsible for + manipulating and showing the state of "active content" (like WebGL, + SVG, fonts etc.). + +3 Additional Considerations + +3.1 Where Are My Extensions Gone? + + Some users might be confused and think NoScript and HTTPS Everywhere + are gone now, plus they want to have their "old" way of setting their + per-site settings back. That's okay and they can easily add NoScript + and HTTPS Everywhere back to their toolbar if they wish. It would be + good to point this out in the transition phase to the new interface at + least. + +3.2 How Do We Inform Users about the New Interface? + + I don't know yet how we ideally inform users about the new interface. + That is not part of this proposal but might merit an own one. + +3.3 Should We Change the Default Security Level? + + As much as I wished to change the default security level, to e.g. + "Safer", right now I think we are not there yet. Part of the security + control redesign should be fixing bugs that make the current and new + interface less effective and painful to use[4][5][6][7]. We could + revisit that discussion, though, once we have solved the low hanging + bugs. + + +[1] +https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/t... +[2] https://trac.torproject.org/projects/tor/ticket/24309 +[3] https://trac.torproject.org/projects/tor/ticket/21183 +[4] https://trac.torproject.org/projects/tor/ticket/22981 +[5] https://trac.torproject.org/projects/tor/ticket/22985 +[6] https://trac.torproject.org/projects/tor/ticket/20314 +[7] https://trac.torproject.org/projects/tor/ticket/21805