[tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
desnacked at riseup.net
Wed Nov 15 10:09:44 UTC 2017
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
>> 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
> 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
>> [*]: 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
Agreed. As long as onion services provide a consistent service,
sysadmins should be responsible for maintaining the mapping and
availability of their services.
More information about the tor-dev