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

[Georg Koppen]

George Kadianakis:
> As discussed in this mailing list and in IRC, I'm posting a subsequent
> version of this proposal. Basic improvements:
> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
> - Does not do auto-redirect; it instead suggests the onion based on
>   antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png

I don't see that or any particular idea of informing the user in the
proposal itself, though. I think more about those browser side plans
should be specified in it (probably in section 2). Right now you are
quite specific about the redirection part and its pro and cons but
rather vague on the actual UX improvements (having the header is just
half of what you need).

> 
> 
> ========================================================================
> UX improvement proposal: Onion redirects using Onion-Location HTTP header
> ========================================================================
> 
> 1. Motivation:
> 
>    Lots of high-profile websites have onion addresses these days (e.g. Tor ,

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
> 
>    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.
> 
>    The Tor Browser intercepts the Onion-Location header (if any) and informs
>    the user of the existense of the onion site, giving them the option to visit

s/existense/existence/

>    it. Tor Browser only does so if the header is served over HTTPS.
> 
>    Browsers that don't support Tor SHOULD ignore the Onion-Location header.
> 
> 3. Improvements

Did you plan to write anything here? I guess there are at least UX
improvements to the ad-hoc things you mentioned at the beginning of the
proposal.

> 4. Drawbacks
> 
> 4.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 we trust its HTTP headers), and the performance gets worse

s/its/their/

>    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

s/abou/about/

>    help those websites and also pave the way forward for future auto-redirect
>    techniques.
> 
> 4.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).
> 
> 5. 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 with more advanced auto-redirect proposals like:

s/with// maybe?

[snip]

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171214/5d01e255/attachment.sig>