Apologies, I am waiting for a train and don't have much bandwidth, so I will be brief:
1) There is no point in issuing <any header of any kind> to anyone unless they are accessing <website> via an exit node.
2) It's inefficient to issue the header upon every web access by every person in the world; when the header is only relevant to 1-in-a-few-thousand users, you will be imposing extra bandwidth cost upon the remaining 99.99...% -- which is unfair to them
3) Therefore: the header should only be issued to people arriving via an exit node. The means of achieving this are
a) Location
b) Bending Alt-Svc to fit and breaking web standards
c) Creating an entirely new header
4) Location already works and does the right thing. Privacy International already use this and issue it to people who connect to their .ORG site from an Exit Node.
5) Bending Alt-Svc to fit, is pointless, because Location already works
6) Creating a new header? Given (4) and (5) above, the only potential material benefit of it that I can see would be to "promote Tor branding" - and (subjective opinion) this would actually harm the cause of Tor at all because it is *special*.
6 Rationale) The majority the "Dark Net" shade which had been thrown at Tor over the past 10 years has pivoted upon "needing special software to access", and creating (pardon me) a "special" header to onionify a fetch seems to be promoting the weirdness of Tor, again.
The required goal of redirection to the corresponding Onion site does not require anything more than a redirect, and - pardon me - but there are already 4x different kinds of redirects that are supported by the Location header (301, 302, 307, 308) with useful semantics. Why reinvent 4 wheels specially for Tor?
7) Story: when I was implementing the Facebook onion, I built infra to support such (eventual) redirection and/or exit-node-usage tracking. Hit "
facebook.com/si/proxy/" from Tor/NonTor to see it in action. The most challenging thing for me was to get a reliable and cheap way to look-up, locally, quickly, cheaply and reliably, whether a given IP address corresponded to an exit node. The closest that I could get to that idea was to scrape Onionoo every so often and to cache the results into a distributed, almost-memcache-like table for the entire site. ie: squillions of machines. This mechanism suffers from all the obvious flaws, notably Onionoo crashes and/or "lag" behind the state of the consensus.
8) So, to pass concrete advice on the basis of experience: rather than pursue novel headers and reinvent a bunch of established, widely-understood web redirection technologies, I would ask that Tor focus its efforts instead upon providing a service - perhaps a listener service embedded in little-t tor as an enable-able service akin to SOCKSListener - which can accept a request from <cidr-subnetmask>, receive an newline-terminated IP address, and return a set of flags associated with that IP (exit node, relay, whatever) - or "none" where the IP is not part of the tor network. Riff on this protocol as you see fit.
This would mean more people running more tor daemons in more datacentres (and possibly configuring some of them as relays) - using this lookup service to establish quickly whether $CLIENT_ADDR is an exit node or not, and whether it should be issued "308 Permanent Redirect With Same Method"
I think this is a better goal for Tor to be pursuing. What do you think?
- alec