Tom Ritter <t...@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 <teor2...@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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
