Referrer-Policy: expand applicable media-types + stricter default

[Malvoz]

This PR does 2 things:

• Expanding media-types for which Referrer-Policy should be sent, part of the effort to close out Ensure HTTP headers are applied to the correct Content-Type #187.

  I've reused the same media-type matching as done in CSP, which I think is appropriate for Referrer-Policy as well. I can't say if there are more media-types to cover for sure as this isn't properly documented anywhere on the web AFAICT. Nevertheless, this should be an improvement regarding user's privacy in comparison to the current matching of text/html only. Some resources confirming the applicable media-types:
  https://w3c.github.io/webappsec-referrer-policy/#integration-with-html
  https://w3c.github.io/webappsec-referrer-policy/#integration-with-css
  https://w3c.github.io/webappsec-referrer-policy/#integration-with-fetch
  Referrer policy of referencing in SVG? w3c/webappsec-referrer-policy#108

• Add a stricter default value, replacing no-referrer-when-downgrade with strict-origin-when-cross-origin for 2 reasons:

  • IMO, the example policy should've always been stricter than the default value (otherwise zero value in specifying it).
  • Spec change (!) to have strict-origin-when-cross-origin be the new default - scheduled for release in Chrome 80.

I simplified the Referrer-Policy description as well, current text is more or less copy&paste from spec and is not super developer-friendly.

[Malvoz]

Spec change (!) to have strict-origin-when-cross-origin be the new default

To emphasize, if we don't change the example policy, then people who enable it as-is will downgrade and send more referrer information than the new default value.

[LeoColomb]

• scheduled for release in Chrome 80.

You know my sensitivity regarding coverage. 😉
If we merge it and deploy on servers today, is this value accepted and strong enough?

[Malvoz]

Coverage is important, indeed!

To clarify, the strict-origin-when-cross-origin value already has quite the coverage (CanIUse). In versions of a browser where it isn't supported, it will be treated as an unknown policy value and defer to the default policy (no-referrer-when-downgrade in current browsers, strict-origin-when-cross-origin in those who implement the spec change).

strong enough?

While it is stronger than no-referrer-when-downgrade, the strongest policy is no-referrer (see this MDN table for comparisons), but because people love their analytics metrics, I think it's best to avoid that as the example policy (see the notes on that).

[LeoColomb]

Then it looks good for me 👍

[XhmikosR]

Do we have any info that this is indeed useful for non-HTML resources? Sorry, I don't have the time to follow this repo closely nowadays.

[Malvoz]

I think the most explicit information I have found for this is in the Referrer-Policy spec under the section "integration with CSS" (linked to in #204 (comment)):

ISSUE 1   This requires that CSS style sheets process Referrer-Policy headers, and store a referrer policy in the same way that Documents do.

I interpret that as advice for developers to set the header for stylesheets.

[Malvoz]

And partially confirmed in https://www.chromestatus.com/feature/5696724538490880.