Re: [w3ctag/design-reviews] `sec-metadata` (#280)

> Given that according to https://www.arturjanc.com/cross-origin-infoleaks.pdf SameSite cookies provide the same level of defense, it's unclear that it's worth the tradeoff.

`SameSite` cookies seem like the right model for security (modulo the lack of a same-origin vs. same-site distinction), but they are -- unfortunately -- almost certainly not the right model for adoptability. I made some notes about this in https://lists.w3.org/Archives/Public/public-webappsec/2018May/0015.html; among other things, `SameSite` cookies make it all but impossible to use CORS (all cross-site requests become unauthenticated) or have resources which are embedded by other sites (when a document is framed cross-site, all its same-origin requests lose cookies because `SameSite` cookies are only sent if the  *top* document is same-site).

`Sec-Metadata` addresses these problems, and has the essential feature of letting developers test the impact of enabling any security restrictions before switching to enforcement, via a server-side equivalent to CSP's report-only policies. This isn't possible with a cookie-based model.

Basically, I see `Sec-Metadata` as a riff on `SameSite` cookies that is much more amenable to being deployed in non-trivial applications; for an opt-in security feature this seems like a critical distinction.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/280#issuecomment-394623002