Over that time, things have changed slightly - at first, although the site was multi-homed, the means of discovery really was limited to noticing the "Browse via Tor" link in the privacy bar on the right hand side of your screen (unless you're on a mobile device...).
When Tor Browser pulled in Firefox's changes to implement support for RFC 7838 Alt-Svc headers, I added support for that too. Since that change, quite a number of Tor Browser Bundle users have connected to me via Onion Services without even knowing they had that additional protection (and were no longer using exit bandwidth).
The real benefit of the Alt-Svc method, other than it being transparent, is that your browser will receive and validate the SSL cert for my site - the user will know they're hitting the correct endpoint, rather than some imposter wrapper site.
Which brings us to today.
How it Works
The principle/implementation is incredibly simple. When you hit my site, amongst the HTTP response headers is a new header:
curl -v -o/dev/null -s https://www.bentasker.co.uk/blog 2>&1 | grep Location < Onion-Location: http://6zdgh5a5e6zpchdz.onion/blog
The new version of Tor Browser Bundle detects this header, and as a result will show you a purple pill informing you that this site has an Onion version available (image is clickable):
If you simply click the purple pill, you'll be taken to my site (at
However, the dialog also gives you the option to tell TBB to always follow these headers, if you click that, then the next time you hit www.bentasker.co.uk you'll (semi) transparently redirect onto the Onion site.
I say semi transparently, because TBB seems to load the entire page before following the redirect. It feels a little jarring but presumably will improve in later releases (and I guess currently happens because it's also possible to define
Onion-Location as a meta-tag, so the processing fires after the DOM has loaded).
Implementation really is stupidly simple in Nginx:
add_header Onion-Location http://6zdgh5a5e6zpchdz.onion$request_uri;
The Onion Location spec does note that larger sites may want to selectively serve this header - i.e. only serve it where Tor users are detected. To me, though, it seems better to just serve it on a non-discriminatory basis - half the issues with methods people previously used were down to reliance on detecting Tor-users, leading to some extremely half-baked results (IMO).
TBB having the ability to silently take you to a different destination based on an upstream header feels like it could be a little unsafe.
There are a bunch of limitations imposed to reduce the risk of this. In order for the header to be valid (and followed)
Onion-Locationvalue must be a valid URL with a
- The webpage serving the
Onion-Locationheader must be served over HTTPS
- The webpage serving the
Onion-Locationheader must not itself be a
So, an intermediary couldn't - for example - start intercepting port 80 requests (i.e. before they've been redirected to HTTPS) and inject an
Onion-Location header pointing to a Onion Service controlled by that intermediary (though they could still serve a standard redirect - that's solved by using HSTS preloading though).
TBB also doesn't appear to cache a list of sites with
Onion-Location headers, so this functionality shouldn't add to any on-disk footprint of sites visited.
So, as of a couple of days ago, Tor Browser Bundle users may see a purple pill in the address bar noting that there's an onion version of this site.
If you prefer to access an Onion directly, then this (hugely) simplifies discovery of the correct service to use. However, even if you don't select this, then where possible (i.e. if performance is better than via an exit - which is usually the case) your browser will continue to hit my www site via an onion transport (in other words, your connection will be silently upgraded).
You may get slightly different performance between the two (depending on the circuit your browser builds) as the hidden service endpoint is running on a different node to the Alt-Svc endpoint.