[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [tor-browser-spec/master] Starting Tor Browser proposals



commit 6becf9c072a8111f1a8a68c5f1c2e4fbf359a722
Author: Georg Koppen <gk@xxxxxxxxxxxxxx>
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

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits