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

[George Kadianakis]

Tom Ritter <tom at ritter.vg> writes:

> I am a big proponent of websites advertising .onions in their Alt-Srv.
>
>> 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.
>
> I envision a future Onion Everywhere extension like HTTPS Everywhere
> that works similar to the HSTS preload list. Crawlers validate a
> websites intention to be in the Onion Everywhere extension, and we
> cache the Alt-Srv information so it is used on first load.
>

Yep, that's yet another cool way to do this. 

>
>> 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
>
>
> I am a big opponent of changing the semantics of Alt-Srv.
>
> We'd have to change the semantics to only do redirection for onion
> domains. We'd also have to figure out how to handle cases where the
> onion lives alongside non-onion (which takes precedence?) We'd also
> have to maintain and carry this patch ourselves because it's pretty
> antithetical to the very intent of the header and I doubt the
> networking team at Mozilla would be interested in maintaining it.
>
> Besides those issues, it also eliminates Alt-Srv as a working option
> to something *else* websites may want: to silently redirect users to
> their .onion _without_ the possibility of confusion for the user by
> changing the address bar. I think Alt-Srv is an option for partial
> petname support in TB.
>
> There is a perfectly functioning mechanism for redirecting users: the
> Location header. It does a lot of what you want: including temporary
> or persistent redirects, updating the addess bar. Obviously it doesn't
> work for all users, most don't know what .onion is, so Facebook isn't
> going to deploy a .onion Location redirect even if they attempted to
> detect TB users.
>
> But they could send a new Onion-Redirect header that is recognized and
> processed (with a notification bar) by any UA that supports Tor and
> wants to implement it. This header would have a viable path to uplift,
> support in extensions, and even standardization. Onion Everywhere can
> preload these headers too.
>

Agreed, the semantics of Alt-Svc are not what we want, and it's probably
not a good idea to change it from an engineering/policy perspective.

Establishing our own header, with the same semantics as Location, seems
to be a cleaner way to approach this.

When I find some time (hopefully this or next week) I will fix up the
proposal based on received feedback.

>
> On 14 November 2017 at 11:25, teor <teor2345 at gmail.com> wrote:
>>> 4. Drawbacks
>>
>> You missed the biggest one:
>>
>> If the onion site is down, the user will be redirected to the downed site.
>> (I've used onion site redirects with this issue, it's really annoying.)
>> Similarly, if a feature is broken on the onion site, the user will be
>> redirected to a site they can't use.
>>
>> Or if the user simply wants to use the non-onion site for some reason
>> (maybe they want a link they can share with their non-onion friends,
>> or maybe they don't want to reveal they're using Tor Browser).
>>
>> Users *must* have a way to disable the redirect on every redirect.
>
> Right now, I don't agree with this. (I reserve the right to change my
> mind.) Websites can already redirect users to broken links through
> mistakes. Why is "my onion site is not running" a scenario we want to
> code around but "my subdomain is not running" is not? If a website
> wants to redirect users they should be responsible enough to monitor
> the uptime of their onion domain and keep it running.  Maybe we need
> better tooling for that, but that's different from saying we need to
> put the onus on users for webmasters failing to keep their sites
> running.
>

Agreed. As long as onion services provide a consistent service,
sysadmins should be responsible for maintaining the mapping and
availability of their services.