Tom Ritter tom@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.
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@gmail.com wrote:
- 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.