<div dir="auto">1) the best and proper way to redirect from site A to site B is to use "Location:" and/or an appropriate 3xx code. It already works.<div dir="auto"><br></div><div dir="auto">2) having an "h2o" ALPN for Alt-Svc would literally make things worse, retard adoption, confuse implementations, break almost all of my future plans for onionification of corporations, and generally make life a pain. It's hard enough getting people to implement functionality in early stages when there are merely bugs, let alone forcing them to jump through hoops to implement special, redundant magical headers that literally do not serve any additional functional value above the extant, open, standard, supported ones.</div><div dir="auto"><br></div><div dir="auto">3) if sites wish to follow Privacy International's example and redirect from a DNS TLD to ".onion" then that is something they should implement at layer 7, by dint of identifying whether the user has arrived over Tor. (See below)</div><div dir="auto"><br></div><div dir="auto">4) if sites want to advertise the existence of an alternate onion site by leveraging some form of tor-specific browser pop down, then sure, knock yourself out with a magical header but nobody in their right mind is going to deploy it in the Enterprise. It would be a massive waste of human / tech bandwidth and hassle. It would be far easier and cheaper instead to react having first identified whether the user has arrived over Tor.</div><div dir="auto"><br></div><div dir="auto">5) onion networking already works for h2 ALPN under alt-svc; please do not mess this up by fragmenting it / imagining that it needs to take-on a special syntax to reflect it's "onion nature". I get what you are saying, it's very clever, but please: no. There is a vast amount of potential for organisations to "turbocharge" their Tor user-experience by simply offering an "h2" onion address amongst Alt-Svc when a user connects to them via an exit node. Everything is already sufficiently disambiguated by the ".onion" suffix. We're good.</div><div dir="auto"><br></div><div dir="auto">6) a moment's consideration will illuminate that the underlying problem here is the increasing fallacy which Tor continues to suffer, that sites should/do not know that a user is arriving over Tor. That half of the websites in the world should be kept in ignorance that a user is arriving via Tor, while the other half - the popular sites by volume - actively want to know that the user is arriving over Tor in order to optimise the user's experience.</div><div dir="auto"><br></div><div dir="auto">In short we have conflicting desires: some tor users want to pretend that they are just some schmoe (sp?) running Firefox on Windows on a "random machine somewhere on the internet" - e.g. a fat exit node run by Mozilla…</div><div dir="auto"><br></div><div dir="auto">But any website that takes an interest (e.g. tracks Cloudflare's "xx-tor" country geolocation, or whatever it is called) - regarding the reputation of the source IP address will KNOW that the user is coming from Tor. </div><div dir="auto"><br></div><div dir="auto">We live in a weird world where the Tor community still believes that systems administrators don't have trivial access to IP reputation databases.</div><div dir="auto"><br></div><div dir="auto">The world has changed since Tor was first invented; perhaps it's time that we stopped trying to hide the fact that we are using Tor? Certainly we should attempt to retain the uniformity across all tor users - everybody using Firefox on Windows and so forth - but the fact that/when traffic arrives from Tor is virtually unhideable. </div><div dir="auto"><br></div><div dir="auto">Consciously sacrificing that myth would make uplift to onion networking so much simpler.</div><div dir="auto"><br></div><div dir="auto">- a</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div>