Re: [whatwg/fetch] Proposal: `Sec-Site` should capture information about the requester of a resource (#700)

That's a good point; though I think this would only happen if a UA adopted a default RP of `no-referrer`, which would likely break other existing things (any other default RP should be okay here).

The way to tackle it probably depends on whether we think it would be the responsibility of the UA or site authors to prevent applications using `Sec-Site` from breaking: 
- If we think the `no-referrer` default is the right model in the long term, we could ask developers with resources loaded cross-origin to configure requesting origins with `Referrer-Policy: strict-origin` or directly add the `referrerpolicy` attribute to any authenticated resource requests in JS libraries. Then, whenever UAs stop sending the Referrer, it would be a no-op for applications which use `Sec-Site` and have a custom RP.
- If the `no-referrer` default is more of an optional feature that will not be broadly deployed by UAs -- and hence we can't get developers to make their sites compatible with it -- we could prevent breakage by having the UA not send the `Sec-Site` header in such cases. For example, in a hypothetical private browsing mode which removes the Referrer completely, the UA could perhaps opt out of the security protections of `Sec-Site` under the (somewhat optimistic) assumption that users are less likely to have long-lived authenticated sessions which benefit from cross-site infoleak protections.

I don't really like the explicit security vs. privacy tradeoff of the second option, but depending on how we see the Referrer-disabling mode being used, maybe it could be worth considering.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/700#issuecomment-381392289