[tor-commits] [tor-browser-spec/master] Starting Tor Browser proposals
gk at torproject.org
gk at torproject.org
Fri Sep 21 10:30:02 UTC 2018
commit 6becf9c072a8111f1a8a68c5f1c2e4fbf359a722
Author: Georg Koppen <gk at 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/tor-browser/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js
+[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
More information about the tor-commits
mailing list