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

[Tom Ritter]

I am a big proponent of websites advertising .onions in their Alt-Srv.


On 14 November 2017 at 06:51, George Kadianakis <desnacked at riseup.net> wrote:
> 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


I think this is a good idea, and would be the best place to put the
"Never show me this again" option.

> 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.


> 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.



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.

-tom