[tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis <desnacked@xxxxxxxxxx>]

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
========================================================================

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

   Websites use the Alt-Svc HTTP header to specify their onion counterpart:
     http://httpwg.org/http-extensions/alt-svc.html

   The Tor Browser intercepts that header (if any) and auto-redirects the user
   to the onion site. Tor Browser only does so if the header is served over HTTPS.

   (That's it.)

3. Improvements

3.1. User education through notifications

   To minimize the probability of users freaking out about auto-redirects Tor
   Browser could inform the user that the auto-redirect is happening. This
   could happen with a small notification bar [*] below the URL bar informing
   users that "Tor Browser is auto-redirecting you to the secure onion site".

   The notification bar could also have a question mark button that provides
   the user with additional information on the merits of onion sites and why
   they should like them.

   [*]: like this one: http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg

3.2. Auto-redirects too intrusive? Make them optional.

   If we think that auto redirects are too intrusive, we should consider making
   them optional, or letting the website specify the desired behavior.

   If a website wants to specify an onion address but doesn't like
   auto-redirects, it could specify that as part of Alt-Svc and we could still
   inform the user that an onion is available using a notification bar again.

4. Drawbacks

   This proposal is far from the perfect solution of course. Here are a few
   reasons why:

4.1. Auto-redirects are scary

   Novice users or paranoid users might freak out with auto-redirects since
   it's unexpected. They might think they are under attack or they got hacked.

   An argument against that is that we are already using HTTPS-everywhere which
   is basically a redirection layer, and while its redirection technique is
   simpler, sometimes the derivative URL is not similar to the original URL,
   and we still don't see people freaking out. I think that's because people
   trust Tor Browser to do the right thing. Combining this knowledge with
   section 3.1 might solve this problem.

4.2. No security/performance benefits

   While we could come up with auto-redirect 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 we trust its HTTP headers), and the performance gets worse
   since we first need to connect to the website, get its headers, and then
   also 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 abou their onions. So this simple proposal will still
   help those websites and also pave the way forward for future auto-redirect
   techniques.

4.3. Alt-Svc does not do exactly what we want

   I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL
   in the location bar, document.location or any other indication of where the
   resource is; this is a “layer below” the URL.". IIUC, this is not exactly
   what we want because users will not notice the onion address, they will not
   get the user education part of the proposal and their connection will still
   be slowed down.

   I think we could perhaps change this in Tor Browser so that it rewrites the
   onion address to make it clear to people that they are now surfing the
   onionspace.

   [*]: https://www.mnot.net/blog/2016/03/09/alt-svc

5. The future

   As I said this is just a simple proposal to introduce the auto-redirect
   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 with more advanced auto-redirect proposals like:

   a) Have a "domains to onions" map into HTTPS-everywhere and have it 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.

======================================================================

Let me know what you think :)

(Should this be part of torspec?)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev