Change the default referrer policy to 'strict-origin-when-cross-origin'.

[mikewest]

This addresses
w3c/webappsec-referrer-policy#125, among other
things.

---

Preview | Diff

[mikewest]

This follows up on w3c/webappsec-referrer-policy#125. It surprises me a bit that we defined the default here rather than there... should we shift it into that document, or is there a good reason that it's defined here and not there?

cc @annevk and @johnwilander

[annevk]

We ended up with this design in #266, PR #280. That didn't really go into where the default should come from however. One reason to define it here is that mutating referrer policy externally would not be great, but we could define some kind of constant in Referrer Policy similar to https://fetch.spec.whatwg.org/#default-user-agent-value and grab that.

[mikewest]

I don't think the current design is terrible, it just surprised me when I was putting the PR together in w3c/webappsec-referrer-policy#125. I expected to find the default there, and had to dig a bit when I didn't.

I do think it would clarify things (or, at least, match my personal expectations) to define a constant in Referrer Policy that's used here. Shall I rework these PRs in that direction?

[mikewest]

(Along the lines of The <dfn export>default referrer policy</dfn> is <a>"<code>strict-origin-when-cross-origin</code>"</a>. in RP and ... set <var>request</var>'s <a for=request>referrer policy</a> to the <a for=/>default referrer policy</a>. here in Fetch.)

[annevk]

Yeah, that's fine with me. (As I mentioned on IRC I'll look for confirmation that Mozilla is on board, but I suspect we are as these are very reasonable changes and with Chrome leading the way there's not much for us to be worried about in terms of compatibility.)

[mikewest]

Great. I'll update the PRs. I expect you'll see an I2I on blink-dev@ in the relatively near future.

[mikewest]

cc @ericlaw1979, who I should have CC'd earlier.

[annevk]

Mozilla is on board modulo compatibility by the way.

[mikewest]

Thanks, @annevk! Chrome's engineering team is running some experiments in beta right now. If the results look reasonable, we'll send out an intent to ship and push it out the door.

[johnwilander]

I think the standard should allow for even stricter defaults such as eTLD+1 referrer (Safari ships one instance of that), no referrer header at all, empty referrer, or always first-party as referrer (I believe Brave does the latter).

[annevk]

Agreed, though that should be part of https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer I think.

[mikewest]

The spec hand-waves in that direction today, noting "Nothing in this specification should be interpreted as preventing user agents from offering options to users which would change the information sent out via a Referer header. For instance, user agents MAY allow users to suppress the referrer header entirely, regardless of the active referrer policy on a page."

I'm happy to extend that with some language either around the "default referrer policy" definition, or as a "Modify |referrerURL| to whatever you like in the interests of minimizing data leakage." step in-between the existing steps 5 and 6 of https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer.

[annevk]

Closing this in favor of #1066 (which is equivalent, but rebased and with a different author).