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

Fri Feb 2 10:32:36 UTC 2018

Georg Koppen <gk at torproject.org> writes:

> [ text/plain ]
> 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).
>

Hello,

pushed another commit to the onion-location branch in my repo for
addressing the concerns in GeKo's email:
           https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=onion-location&id=14fc750e3afcd759f4235ab955535a07eed24286

I was not sure what other stuff to put in section 2 but please let me
know if you don't feel fullfiled with the current ones!!!

Also, I wiped out the improvements section because i was not sure what
to put there.

As a side thing, I found this extension which does the bottombar part of
this proposal, but it gets the redirection list from a local file
instead of an HTTP header: https://github.com/Someguy123/HiddenEverywhere

Cheers!

>> 
>> 
>> ========================================================================
>> 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
>
> [ signature.asc: application/pgp-signature ]
> [ text/plain ]
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev