On 14 Nov 2017, at 23:51, George Kadianakis <desnacked@riseup.net> wrote:

3.2. Auto-redirects too intrusive? Make them optional.

If we think that auto redirects are too intrusive, we should consider making them optional, or letting the website specify the desired behavior.

If a website wants to specify an onion address but doesn't like auto-redirects, it could specify that as part of Alt-Svc and we could still inform the user that an onion is available using a notification bar again.

Inform the user that the onion address is available. Make the default behaviour *not* to redirect (it's not faster, it's not more secure, and it's surprising). But I'd be willing to compromise here, by letting the site specify an initial default, and having the Tor Browser default be whatever. Let *the user* control the behaviour via the notification bar, and maybe allow them to set a session default. (This won't be persistent, for disk leak reasons.)

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. T

Tom Ritter <tom@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 <teor2345@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.

As discussed in this mailing list and in IRC, I'm posting a subsequent version of this proposal. Basic improvements: - Uses a new custom HTTP header, instead of Alt-Svc or Location. - Does not do auto-redirect; it instead suggests the onion based on antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png ======================================================================== UX improvement proposal: Onion redirects using Onion-Location HTTP header ======================================================================== 1. Motivation: Lots of high-profile websites have onion addresses these days (e.g. Tor , NYT, blockchain, ProPublica). All those websites seem confused on what's the right way to inform their users about their onion addresses. Here are some confusion examples: a) torproject.org does not even advertise their onion address to Tor users (!!!) b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion address and completely wrecking the UX (loses URL params, etc.) c) ProPublica has a "Browse via Tor" section which redirects to the onion site. Ideally there would be a consistent way for websites to inform their users about their onion counterpart. This would provide the following positives: + Tor users would use onions more often. That's important for user education and user perception, and also to partially dispell the darkweb myth. + Website operators wouldn't have to come up with ad-hoc ways to advertise their onion services, which sometimes results in complete breakage of the user experience (particularly with blockchain) This proposal specifies a simple way forward here that's far from perfect, but can still provide benefits and also improve user-education around onions so that in the future we could employ more advanced techniques. Also see Tor ticket #21952 for more discussion on this: https://trac.torproject.org/projects/tor/ticket/21952 2. Proposal We introduce a new HTTP header called "Onion-Location" with the exact same restrictions and semantics as the Location HTTP header. Websites can use the Onion-Location HTTP header to specify their onion counterpart, in the same way that they would use the Location header. The Tor Browser intercepts the Onion-Location header (if any) and informs the user of the existense of the onion site, giving them the option to visit it. Tor Browser only does so if the header is served over HTTPS. Browsers that don't support Tor SHOULD ignore the Onion-Location header. 3. Improvements 4. Drawbacks 4.1. No security/performance benefits While we could come up with onion redirection 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. 4.2. Defining new HTTP headers is not the best idea This proposal defines a new non-standard HTTP header. This is not great because it makes Tor into a "special" thing that needs to be supported with special headers. However, the fact that it's a new HTTP header that only works for Tor is a positive thing since it means that non-Tor browsers will just ignore it. Furthermore, another drawback is that this HTTP header will increase the bandwidth needlessly if it's also served to non-Tor clients. Hence websites with lots of client traffic are encouraged to use tools that detect Tor users and only serve the header to them (e.g. tordnsel). 5. The future As previously discussed, this is just a simple proposal to introduce the redirection concept to people, and also to help some sysadmins who are currently coming up with weird ways to inform people about their onions. It's not the best way to do this, but it's definitely one of the simplest ways. In the future we could implement with more advanced auto-redirect proposals like: a) Have a "domains to onions" map into HTTPS-everywhere and have it do the autoredirects for us (performance benefits, and security benefits under many threat models). b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested by comment:42 in #21952. But both of the designs above require non-trivial engineering/policy work and would still confuse people. So I think starting with a simple approach that will educate users and then moving to more advanced designs is a more normative way to go. ======================================================================

On 9 Dec 2017, at 03:27, Tom Ritter <tom@ritter.vg> wrote:

...

We introduce a new HTTP header called "Onion-Location" with the exact same restrictions and semantics as the Location HTTP header.

For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2

Because this is a non-standard header, does it need to be spelled: "X-Onion-Location"? T

George Kadianakis:

As discussed in this mailing list and in IRC, I'm posting a subsequent version of this proposal. Basic improvements: - Uses a new custom HTTP header, instead of Alt-Svc or Location. - Does not do auto-redirect; it instead suggests the onion based on antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png

I don't see that or any particular idea of informing the user in the proposal itself, though. I think more about those browser side plans should be specified in it (probably in section 2). Right now you are quite specific about the redirection part and its pro and cons but rather vague on the actual UX improvements (having the header is just half of what you need).

======================================================================== UX improvement proposal: Onion redirects using Onion-Location HTTP header ========================================================================

1. Motivation:

Lots of high-profile websites have onion addresses these days (e.g. Tor ,

Tor,

NYT, blockchain, ProPublica). All those websites seem confused on what's the right way to inform their users about their onion addresses. Here are some confusion examples: a) torproject.org does not even advertise their onion address to Tor users (!!!) b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion address and completely wrecking the UX (loses URL params, etc.) c) ProPublica has a "Browse via Tor" section which redirects to the onion site.

Ideally there would be a consistent way for websites to inform their users about their onion counterpart. This would provide the following positives: + Tor users would use onions more often. That's important for user education and user perception, and also to partially dispell the darkweb myth. + Website operators wouldn't have to come up with ad-hoc ways to advertise their onion services, which sometimes results in complete breakage of the user experience (particularly with blockchain)

This proposal specifies a simple way forward here that's far from perfect, but can still provide benefits and also improve user-education around onions so that in the future we could employ more advanced techniques.

Also see Tor ticket #21952 for more discussion on this: https://trac.torproject.org/projects/tor/ticket/21952

2. Proposal

We introduce a new HTTP header called "Onion-Location" with the exact same restrictions and semantics as the Location HTTP header. Websites can use the Onion-Location HTTP header to specify their onion counterpart, in the same way that they would use the Location header.

The Tor Browser intercepts the Onion-Location header (if any) and informs the user of the existense of the onion site, giving them the option to visit

s/existense/existence/

it. Tor Browser only does so if the header is served over HTTPS.

Browsers that don't support Tor SHOULD ignore the Onion-Location header.

3. Improvements

Did you plan to write anything here? I guess there are at least UX improvements to the ad-hoc things you mentioned at the beginning of the proposal.

4. Drawbacks

4.1. No security/performance benefits

While we could come up with onion redirection 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

s/its/their/

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

s/abou/about/

help those websites and also pave the way forward for future auto-redirect techniques.

4.2. Defining new HTTP headers is not the best idea

This proposal defines a new non-standard HTTP header. This is not great because it makes Tor into a "special" thing that needs to be supported with special headers. However, the fact that it's a new HTTP header that only works for Tor is a positive thing since it means that non-Tor browsers will just ignore it.

Furthermore, another drawback is that this HTTP header will increase the bandwidth needlessly if it's also served to non-Tor clients. Hence websites with lots of client traffic are encouraged to use tools that detect Tor users and only serve the header to them (e.g. tordnsel).

5. The future

As previously discussed, this is just a simple proposal to introduce the redirection concept to people, and also to help some sysadmins who are currently coming up with weird ways to inform people about their onions. It's not the best way to do this, but it's definitely one of the simplest ways.

In the future we could implement with more advanced auto-redirect proposals like:

s/with// maybe? [snip] Georg

Hi, I've had a go at implementing this for my personal blog. Here are some things:

We introduce a new HTTP header called "Onion-Location" with the exact same restrictions and semantics as the Location HTTP header. Websites can use the Onion-Location HTTP header to specify their onion counterpart, in the same way that they would use the Location header.

Example: Onion-Location: http://vwc43ag5jyewlfgf.onion

This example is perhaps not the best example. I tried to get things working with the Healthy Onions add-on, but found that the developer had interpreted this to mean that the Onion-Location value is just a replacement for the protocol and domain parts of the URL, not a replacement for the whole URL. There may not be a 1:1 mapping in the URL space between the two URL domains. At the very least, I would add a trailing slash (/) to the example. The Healthy Onions developer seems to expect the string to end with ".onion". My personal website is a static site (mostly). In my implementation, I took a list of all possible HTML URLs (excluding images, stylesheets, etc.) and generated a list of corresponding onion locations. I figured that being a blog, people often link to individual pages instead of just to my homepage (which is probably the least useful page on the site). Having the Onion-Location header on every page someone could land on gives the best chance that they will discover the onion service. But then I realised that some of the locations I had generated Onion-Locations for would also be serving Location headers as they were old URLs. What should a browser do in this case? What should an implementer do? In my implementation, I've thrown in the Onion-Location headers regardless of whether or not a Location header is also present because it was easier. It could be preferable that the redirection is followed after switching to the Onion service (i.e. Location header is ignored until user responds to the Onion-Location header prompt), but this would mean the page wouldn't have loaded before you get the prompt to go to the Onion service, which may be confusing for users. Alternatively, if the page has a Location header then the Onion-Location header should be ignored. Thanks, Iain.

Hi, On 13/07/18 16:24, Tom Ritter wrote:

Ah, that makes sense. You want /foo.html to serve an Onion-Location that goes to /foo.html

Exactly! But I might also want that /foo/bar.html goes to /bar.html on the onion service while /baz/bar.html goes to /bar.html on another onion service. Otherwise I don't think we can claim that the Onion-Location header is similar to the Location header.

But you're saying you did this manually for each file? I guess I hadn't thought about how I would implement this (for Apache)... http -> https redirection is done with mod_write, typically something like

My personal website is currently hosted by Netlify. They allow you to provide a file that is used to send custom headers on a per-URL basis. https://www.netlify.com/docs/headers-and-basic-auth/ I've attached the script I'm using for this. It's a manual step in that I have to run the script. I could probably automate it if I learnt a little more Hugo.

I don't mess with Apache/mod_rewrite much, but surely there's a way to write out the Onion-Location header with the supplied path/querystring automatically?

I would imagine there are ways to configure this, but I don't know what they are.

I agree that if a Location header is present, the browser should follow it immediately. If the subsequent location has an Onion-Location header (and no Location header) then the browser should prompt.

This sounds reasonable.

Location is a non-prompt, non-negotiable redirect. Onion-Location is a prompted, user-chosen redirect.

The only question in my mind is if the user has opted in to always following Onion-Location redirects, then the question is: which header do you follow? And I would suggest Onion-Location although I don't have a strong argument for that choice besides "It's our feature, we should give it precedence."

I think in this case, I would prefer to follow the Onion-Location header first, as the user has chosen to make the usability trade-off for security by enabling the automatic redirects. Would it be worthwhile for me to write some text to this effect as a patch for the proposal document? Thanks, Iain.

Georg Koppen:

FYI: the proposal is now the first Tor Browser proposal: https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-...

Sounds great. One nit: | Website operators should be aware that tools like tordnsel have | false positive potential (they might treat Tor users as non-Tor users) -> "false negative" Rusty

(changed the subject to make clear that this is NOT about Alt-Svc anymore) I assume this is limited to onions for sites that do not aim for server side location anonymity.

FYI: the proposal is now the first Tor Browser proposal: https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-...

in the light of the fact that this proposal has been started before Tor Browser 8 with Alt-Svc support for .onions was a thing (and CF jumping on it [0]) I'm wondering how you think about it compared to what benefits Alt-Svc provides over what Onion-Location provides? Are you unsatisfied with what RFC 7838 - HTTP Alternative Services provides or is "onion address is displayed in URL bar" one of your goals/requirements of this proposal? Although Alt-Svc does not work reliably _yet_ and the UI part is missing [3] I find it addresses some rather important issues that 'Onion-Location' does not: - users get the transport security benefits of .onions without Tor Browser displaying hard/impossible to remember/recognize randomly looking strings. Long randomly looking strings in the domain part of the URL that would probably confuse many users and make it harder to answer the question "Am I still on the page I want to be?" (I consider it a major UX improvement that you can display the non .onion domain name while the traffic actually goes to the .onion) - users will use onions transparently without asking them questions they probably don't understand or don't want to be bothered with everytime they visit a website [1] I believe asking fewer questions, safe defaults and configuration options for advanced users are some reasonable goals. - it solves the ".onions can't get DV certs (yet)" issue [0] https://blog.cloudflare.com/cloudflare-onion-service/ [1] https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png [2] https://trac.torproject.org/projects/tor/ticket/27590 [3] https://trac.torproject.org/projects/tor/ticket/27590#comment:2 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

Sorry, the second reference should have been this: https://medium.com/@alecmuffett/different-ways-to-add-tor-onion-addresses-to... On Wed, Sep 26, 2018 at 1:50 AM <dinovirus@gmail.com> wrote:

Before moving on from Alt-Svc, one idea that I thought would be great is adding a new ALPN protocol ID [1] for HTTP/2 over onions, similar to "h2" for HTTP/2 over TLS. Alec's post [2] reminded me of this and I'm sure someone has considered this before, but if not now's a good time.

First, let's all agree that all non-onion websites have to use https, otherwise none of this matters.

*Here's the gist of it:*

Let's consider the case of "h2" ALPN for HTTP/2 over TLS: 1. browser requests "https://foo.com", receives 'alt-svc: h2="bar.onion:443"' 3. browser connects to bar.onion:443 port (this fails if tor socks isn't set up) 4. the host must pass authentication [3], which for "h2" means giving a valid certificate for "foo.com" 5. if authentication succeeds, browser displays "foo.com" but connects using "bar.onion" and shows "bar.onion" in the circuit display.

This scenario is great for common websites because the cookie space is always "foo.com", so the onion address can be transitory. In particular, even if the website doesn't own the private key to the onion service, authentication depends on TLS certificate for "foo.com", which the website owns.

Now, the idea is to add "h2o" ALPN for HTTP/2 over TCP via an onion service: 1. browser requests"https://foo.com", receives 'alt-svc: *h2o* ="bar.onion:80' 3. normal browsers would ignore this, but Tor Browser connects to bar.onion:80 4. the host *must still pass an authentication* step for "h2o" that Tor Browser can invent 5. if authentication succeeds, *Tor Browser redirects to "bar.onion"*, optionally noting "foo.com" in the circuit display.

For the "h2o" authentication step, TBB could: 1. Use a HTTPS Everywhere type extension 2. Require UI announcement + confirmation

This scenario is great for websites that want to separate cookie spaces " foo.com" and "bar.onion" (you probably don't want a whistle-blower logged in to your onion service suddenly send cookies over an exit node) or don't want https+onion. Also, this is pretty much compatible with the Alt-Svc specifications, so it doesn't require adding a new header.

Note that in this case the onion address is no longer transitory, so it's important that the website should own the private key. This is critical because unlike IP addresses, domain names, or even HTTPS certificates, the private key to onion addresses doesn't expire (until offline/delegate keys are implemented).

Thoughts?

[1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-... [2] https://medium.com/@alecmuffett/onion-synopsis-for-susan-hennesey-b28a92f0e9... [3] https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1

On Sat, Sep 22, 2018 at 2:55 PM nusenu <nusenu-lists@riseup.net> wrote:

...

(changed the subject to make clear that this is NOT about Alt-Svc anymore)

I assume this is limited to onions for sites that do not aim for server side location anonymity.

...

FYI: the proposal is now the first Tor Browser proposal:

https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-...

in the light of the fact that this proposal has been started before Tor Browser 8 with Alt-Svc support for .onions was a thing (and CF jumping on it [0]) I'm wondering how you think about it compared to what benefits Alt-Svc provides over what Onion-Location provides?

Are you unsatisfied with what RFC 7838 - HTTP Alternative Services provides or is "onion address is displayed in URL bar" one of your goals/requirements of this proposal?

Although Alt-Svc does not work reliably _yet_ and the UI part is missing [3] I find it addresses some rather important issues that 'Onion-Location' does not:

- users get the transport security benefits of .onions without Tor Browser displaying hard/impossible to remember/recognize randomly looking strings.

Long randomly looking strings in the domain part of the URL that would probably confuse many users and make it harder to answer the question "Am I still on the page I want to be?" (I consider it a major UX improvement that you can display the non .onion domain name while the traffic actually goes to the .onion)

- users will use onions transparently without asking them questions they probably don't understand or don't want to be bothered with everytime they visit a website [1] I believe asking fewer questions, safe defaults and configuration options for advanced users are some reasonable goals.

- it solves the ".onions can't get DV certs (yet)" issue

[0] https://blog.cloudflare.com/cloudflare-onion-service/ [1] https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png [2] https://trac.torproject.org/projects/tor/ticket/27590 [3] https://trac.torproject.org/projects/tor/ticket/27590#comment:2

-- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- mahrud <algorithms.jux-foundation.org/~mahrud/blog>

-- mahrud <algorithms.jux-foundation.org/~mahrud/blog>

On Wed, 26 Sep 2018 at 06:51, <dinovirus@gmail.com> wrote:

...

I want to compare your proposal with the simple situation of "If the server gets a connection from a Tor exit node, return Location: blah.onion." (This would also separate the cookie space) If I understand your proposal correctly, the differences are: 1) Because the client offers h2o in ALPN, the server knows (at initial TLS connection time) the client supports .onion transport. (We also leak this out onto the network in plaintext; but since it comes from an exit node it's not too concerning?) 2) The server offers h2o as an Alt-Svc protocol, so any client not supporting onions will ignore it gracefully. There is no concern that the server could send a Location: blah.onion header to a client not supporting onions; or omit it from a client supporting onions. 3) Tor Browser can implement additional authentication checks for the transfer from blah.com -> blah.onion I'm not clear if the connection to blah.onion involves HTTPS or HTTP; but I suppose both are possible. Because the response from the server comes from So I like to try and keep the intent of headers as close as possible. Alt-Svc is used to redirect routing without visible changes and without user prompting. That's why I'm opposed to Alt-Svc: h2/blah.onion prompting the user, and opposed to the Location: header prompting the user but am perfectly supportive of a new Onion-Location header prompting the user. Creating h2o for Alt-Svc and implementing it in a way that redirects the user violates the intent of Alt-Svc. Additionally, ALPN is designed for negotiating an Application Layer Protocol - what you speak inside TLS. h1 and h2 are different protocols, so one uses ALPN to negotiate h2 in the TLS connection, and the first byte of the application layer protocol is HTTP2. In your proposal; you negotiate a different protocol, but still speak h2. Actually it's not clear if one should speak HTTP or HTTP2 to the server! (We could require http2 but that seems like a bad idea.) The response from the server still comes in the Alt-Svc header; so there's no connection latency to be avoided. I like the goal of giving server operators the ability to separate cookie spaces. But I think that's accomplished by both a prompted Onion-Location redirect or a non-prompted Location redirect. I like the goal of having no ambiguity or confusion about what a browser that does/doesn't support onion should do with an onion address or possibility of not serving an onion address to someone who should get. Onion-Location solves this for prompted redirects. Location does not solve this for promptless redirects. (We could add a 'force' parameter to Onion-Location to bypass the prompt. I think this is a good idea and would suggest we add it to the proposal.) I think the idea of allowing Tor Browser to require and perform additional security checks for the transfer from http(s) -> onion. But I don't see why they couldn't be added/performed as part of the Onion-Location transfer. I like the idea of using ALPN for something; but I don't think this is the right problem to use it for. Because it's used for Application Layer Protocol selection, it is the perfect choice to use to negotiate a Tor connection or a Pluggable Transport connection to a server supporting both a website and Tor. (Imagine if that were deployed on something like Github!) But it's _in plaintext_. So any connection offering such an ALPN could be blocked. I'm still disappointed the WG chose ALPN instead of NPN. With this plaintext limitation, I don't know what we could use ALPN for. Maybe we could use it inside normal Tor connections to negotiate a new Tor protocol that didn't nicely fit into the existing tor protocol version negotiation. -tom

On Tue, Oct 23, 2018, 12:15 PM Alec Muffett <alec.muffett@gmail.com> wrote:

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.

Consciously sacrificing that myth would make uplift to onion networking so much simpler.

I agree. In particular because I want to avoid false positives and false negatives in the reputation system. But by what mechanism do we expose this information? I can't think of one that doesn't have significant drawbacks. And what do we say/what do we mean? (I am onion capable?)

Hi, On 23/10/18 18:15, Alec Muffett wrote:

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. 

We live in a weird world where the Tor community still believes that systems administrators don't have trivial access to IP reputation databases.

IP reputation databases do not reflect the current state of the Tor network exactly. They may be pretty close, even 99%, but they're not exact. You will get false positives, and a lot of false negatives too. Improving exit detection is on the list of tasks for Tor Metrics but it is not our top priority.

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.

Given that false positives are possible, doing this conditionally is going to give some people a terrible user experience by redirecting them to an onion they cannot possibly reach in their browser. This is why I like the Onion-Location header. You don't have to have this conditional. You don't need to have any infrastructure to provide lookups from databases (which ideally would need to be refreshed constantly). You just always serve the header. This also gives you the opportunity to advertise that a service is available via Onion service to all users, some of which might have a browser add-on that lets them know about these things. Thanks, Iain.