Strip referrer information from non-secure requests.

[mikewest]

It's good to have dreams.

---

Preview | Diff

[mikewest]

(This is a bit difficult to ship, as we have anecdotal evidence that stripping referrers entirely breaks some sites' anti-CSRF mechanisms. A safer alternative (in the less-data-flowing-over-non-secure-wires sense) could be to adopt Brave's model of spoofing the referer header as the target's origin for non-secure resources.)

[fmarier]

Brave's model of spoofing the referer header as the target's origin for non-secure resources

The exact model we converged on is:

• cross-origin requests for iframes and sub-resources have their referrer set to be the origin of the requested resource ("spoofing")
• cross-origin navigations have no referrer at all ("stripping")
• same-origin requests of all kinds keep their normal referrer

The problem with spoofing navigation is that while it's making the CSRF checks pass, it's also effectively disabling that check entirely (it always passes), which is not great for security.

Stripping referrers from iframes leads to a lot of breakage in our experience.

[ericlaw1979]

@fmarier: Current versions of brave (e.g. 1.5.86 Chromium: 80.0.3987.87 (Official Build) dev (64-bit))
seem to do something slightly different:

• cross-site requests for iframes and sub-resources have their referrer set to be the origin of the requested resource ("spoofing")
• cross-site navigations have no referrer at all ("stripping")
• same-site requests of all kinds keep their normal referrer

Is that expected?

Test page: https://www.webdbg.com/test/refer/

[fmarier]

@ericlaw1979 Indeed that's the correct behavior. You're right I forgot to mention that our "origin" checks are actually ETLD+1 checks.

I made a test page for this specific behavior and have updated our documentation.