Send "null" Origin header on cross-origin .onion requests

[fmarier]

Fixes #1350.

• At least two implementers are interested (and none opposed):
  • Firefox (off by default) / Tor Browser (on by default)
  • Brave
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

One thing remaining here is that if we want to have this check in at least three places, we should probably have an exported "is an onion URL" predicate that takes a URL and returns true or false instead. (Other things are tests, Mike's feedback, whether this should be optional somehow or conditional upon .onion support...)

[domenic]

The other big remaining thing here is making sure this would be on track to become a part of the interoperable web, via implementation (on by default) in WebKit/Gecko/Chromium.

[fmarier]

making sure this would be on track to become a part of the interoperable web

Yes and trying to see whether there's agreement on the correct way to handle these was the reason I created these PRs in the first place.

In the short term, Brave is going to match what the Tor Browser is doing, but ideally we'd like to see if we can align with the browsers that don't bundle Tor directly.

[fmarier]

whether this should be optional somehow or conditional upon .onion support

On this specific point, I would suggest the answer is no, it should be always ON because there's no easy way for the browser to know that the SOCKS5 proxy it's using is the Tor daemon.

[annevk]

This looks good editorially. I guess there's still the question of whether we want to abstract "is an origin URL", but that could happen later as well.

So this mainly hinges on implementer interest and resolving the question as to whether we should expose more information when CORS is used.

[annevk]

Due to "byte-serializing a request origin" we'll also end up with null if they are same origin but there's a cross-origin redirect in between. Ideally we'd test that, but I guess .onion will be hard to test.

[fmarier]

I've got these two no-cors manual test cases on my test page (you can also see it at http://fmarier.com/referrer/onion.html though it's meant to run from a .onion) :

• example.onion --POST--> example.onion --307--> example.com
• example.onion --POST--> example.com --307--> example.onion

For the first one, both Brave and Tor Browser send a null origin (and omit the referrer for that matter).

For the second one, however, Brave sends a null origin but the Tor browser sends the full Origin in that case.

Is a null Origin the desired behavior in both cases or just in the first one?

[annevk]

I'm not sure I understand the examples, what's the starting origin? As long as you are same-origin I would expect a referrer to be included, but once you've gone cross-origin once, it should no longer be possible.

[fmarier]

The starting origin in all cases is example.onion. It issues two 307 redirects.

In the first example, it goes from example.onion to example.onion/anotherpage before ending on example.com.

In the second example, it goes from example.onion to example.com before ending on example.onion/anotherpage.

[annevk]

So the user navigates to the starting origin? I guess then the scenarios would work. (Typically with fetching there's a starting document with some kind of authority and that would do the fetching, which could then result in a redirect. The initial 307 threw me off.)

Assuming the user does the navigation I'd expect:

1. example.onion 307 to example.onion (Origin could be included here, e.g., in case of a POST); example.onion 307 to example.com (it would be null here)
2. example.onion 307 to example.com (it would be null here); example.com to example.onion (it would continue to be null here, as it's been tainted by example.com)

[fmarier]

So the user navigates to the starting origin?

Yes, that's correct. However, I just realized that I made a mistake in my description of the test cases, which probably threw you off.

What I meant was:

1. Navigate to example.onion/index.html.
2. Submit form (POST) to example.onion/another.html.
3. example.onion/another.html is a 307 redirect to example.com.
4. You end up on example.com with a null Origin header.

The second test case is:

1. Navigate to example.onion/index.html.
2. Submit form (POST) to example.com.
3. example.com is a 307 redirect to example.onion/another.html.
4. You end up on example.onion/another.html with a null Origin header.

I had the same expectations as you (regarding the example.com tainting due to the redirect) and that's what I implemented in Brave, but Tor Browser returns an Origin of example.onion in the second case.

[annevk]

That seems like a pretty serious bug. @KershawChang @valenting ^^

[KershawChang]

I've filed bug 1742784 for this.

[ghost]

Remove