The 9.5a11 alpha version of @torproject's browser ships with support for announcing your Onion site from your regular website via the "Onion-Location" HTTP header. For Nginx users: `add_header Onion-Location x.onion$request_uri;` and you're done.

@ahf @torproject that's sweet!

I don't have any services available through the tor but on the user side it's great. Wonder if this feature available on Android version.

@a1batross @torproject I don't think it is ready for Android yet, but I must admit I haven't tried 😕

@ahf Is there a (hidden) preference I need to activate to make Tor-Browser 9.5a11 show the purple badge?

Because I can't get it show up here with a page that already successfully does an opportunistic onion via alt-svc header.

HTTP response header shows correctly in curl(1).

@MacLemon Hm. I think the banner only shows up with the Onion-Location header, but not with alt-svc headers. Are you testing on desktop or on mobile? Does my site on show the banner for you?

@ahf The alt-svc was only mentioned to underline that I know this site has a working onion site.

I would only expect the purple banner to show up when an onion-location header is in fact available. Which it is.

Nope, doesn't show on your page as well.
Interestingly your's does auto redirect to the onion site though, but no purple banner.

Using 9.5a11 (based on Mozilla Firefox 68.7.0esr) (64-bit) on macOS.

@MacLemon Did you enable in the preferences that it should auto-redirect? If yes, I don't think the banner shows up when auto-redirection is in place. I can ask tomorrow how the feature is supposed to work *together* with alt-svc. I have no idea about the semantics there.

@ahf Yes, just experimented with that setting. Only auto-redirects when set to always. Now it also shows the purple-banner.

Might it be related to using a subdomain of the onion domain? like `foo.<domain>.onion` instead of the plain `<domain>.onion`?

I don't expect it to work *together* with alt-svc. Also doesn't change when removing the alt-svc header.

Leaving the only differences being me using a subdomain of the onion and mine being a single hop onion.

@MacLemon Hm, interesting. I don't think the fact that you are a single hop onion should matter here, since that is not known to the browser. Your header is: `Onion-Location: http://foo.<public key>.onion/` ?

@ahf I wouldn't expect the single hop onion to make a difference either. It's just the only things I could identify being differences.
I'm using `Onion-Location: http://domain.tld.<public_key>.onion/` to be exact.

I wouldn't think it *should* make a difference, since that's a totally valid and working onion address. Unless there's restrictions on that in place.
Haven't found any documentation on the header yet.

@MacLemon It's still only in an Alpha release, so I doubt there are much documentation yet. Heck, I think in theory the semantics could even change before the final release. I just enabled it to experiment with the feature now that the Alpha release was out.

I'm gonna try tomorrow to change my site to use a subdomain and see if I can reproduce the behavior you're reporting.

@ahf I can perfectly reproduce it now. It's clearly the subdomain use.

@MacLemon I have passed on the description of the problem to one of our browser engineers! Thanks for debugging this 🙂

@ahf If you created a ticket, I'm happy to add to it if need be.

@MacLemon I'll wait and see what he says on IRC tomorrow 😃

@MacLemon I created - acat replied with some info on the constraints we have for it to work. Is there something missing there in your setup?

@ahf Thanks, just read through it and certainly meeting all the criteria. I guess I've debugged it and it's complicated. Tor-Browser's behaviour is technically correct, but very confusing to the user.

I'll write that up and add to the ticket.

@MacLemon Hey, did you ever get around having a look at ? We are unsure if you managed to solve the issue or if there is an issue in the code in TB? We haven't been able to reproduce it.

@ahf I could add more to this, but it seems I'm not allowed to comment on the ticket.

It raises a few more questions with .js and XHR and how this behaves. Might be relevant for the Spec as well as the UI which is the *current* problem concerning the ticket.

@ahf Svc-alt is weird in behaviour, because Tor-Browser is unable to tell the user where it sent a request being it directly to the domain, or via the proxy.
It does though send subsequent requests after the first load of a page with Svc-Alt header to the onion domain via proxy, but with Host: and SNI Headers of the original domain.
It's completely transparent to the user, they have no way to tell what's actually going on. But you get HTTPS+h2 via Tor with your standard LE cert.

@MacLemon Yeah. The semantics of alt-srv (and a lot of the new HTTP2 behaviours from IETF) are often "odd". It took me a while to wrap my head around it.

I personally see alt-svc as a positive feature since it opportunistically can remove load from the scarce exit node resource in the network. I think it lacks the educational aspect of letting the user know they are using onions, which may or may not matter at all.

@ahf To speed things up for Tor users and save on Exit bandwidth is the exact reason we use that.

At least having the info available where a request was sent somewhere in the browser console would make debugging this a *LOT* easier though. :-)

I just temporarily remove the subdomain part and now the purple banner *does* show up. So it certainly is a limitation there. Don't know it that is intentional or not.

If yes, we'd need to rebuild all our hosts to use separate onion hostnames.

@MacLemon I remember when I was trying out alt-srv when CF announced it for their .onion support, and the lack of debugging abilities inside of Firefox made it very hard to figure out if Firefox was even using the alt-svc or not.

I have no idea if they have added support for alt-svc in the web inspector in the normal Firefox release cycle (Tor is on ESR), but I hope one day the web inspector will be made more aware of the feature.

Sign in to participate in the conversation

The original server operated by the Mastodon gGmbH non-profit