Allow document.cookie and maybe Set-Cookie from the server to be controlled

[annevk]

It doesn't seem like a good idea to overload suborigins with this (see w3c/webappsec-suborigins#75).

[clelland]

I know that document.cookie has definitely been considered, from a performance perspective -- the idea would be to remove that attribute from the Document object, and require developers to use something like https://github.com/WICG/async-cookies-api instead.

It sounds, though, like you're thinking more about the security aspects of cookie manipulation -- is that true?

In that case, we'd want to restrict any current or future scriptable access to the cookie jar, not just document.cookie.

I would think that Set-Cookie, if read from the HTTP headers in the document, might still be acceptable -- any attacker who can manipulate headers could likely already override the policy anyway, but <meta http-equiv=Set-Cookie> would probably need to be controlled as well.

[clelland]

Although it looks like you may have been considering Set-Cookie already :)
whatwg/html#1950
whatwg/html#3076

[annevk]

Yeah http-equiv set-cookie is likely gone soon.

I agree that what I'm after should disable every JavaScript API for cookies. I guess I'm also somewhat convinced that HTTP Set-Cookie is at the same level so doesn't matter (although @mikewest did at one point have a CSP extension for it; maybe dropped for the same reason).

There's also something to say for whether outgoing requests should include cookies, but maybe that's best tracked in a separate issue.

[Malvoz]

mikewest did at one point have a CSP extension for it

This: https://w3c.github.io/webappsec-csp/cookies/

There is a lot of expressed interest in controlling cookies:

• Disable Set-Cookie also + other storage #16
• cookie-scope WICG/origin-policy#8
• Thoughts on letting CSP govern attributes that must appear in Set-Cookie webappsec-csp#152
• CSP 4 feature request: cookie policy webappsec-csp#301
• CSP: Provide a way to restrict domain of document.cookie webappsec#432
• CSP: Allow precise control of cookies webappsec#561
• Security consideration: origins unable to restrict non-HTTP APIs cookie setting httpwg/http-extensions#525
• https://lists.w3.org/Archives/Public/public-webappsec/2018Oct/0029.html

[Malvoz]

HTTP State Tokens also mention the potential need for opt-in and opt-out mechanisms as part of the process in (hopefully?) migrating away from cookies.

[clelland]

Cookies is an interesting case -- there are at least three sides to it.

Restricting document.cookie access is straightforward, I think -- it would probably fit nicely into the new sandboxing restrictions model, so you could opt out of doc.cookie usage on a per-document basis, and could prohibit access in subframes (if that was important to you) with a frame attribute which requires acknowledgment from the framed site.

Stopping Set-Cookie from having any effect is feels like it could operate in a similar manner, but Set-Cookie is defined at the HTTP layer, and so would take effect during FETCH, I suspect, long before we hit the "Create a Feature Policy for a browsing context from response" algorithm. (http-equive="set-cookie" is now gone)

Stopping cookies on outgoing requests is interesting. It might be similar to client hints, in that we can control the content of an outgoing request. It definitely fits into tracking protection, and it would be nice to find a way to enable credential-less subresources on the web. First-party cookies seems like the easiest issue to tackle; then possibly third-party subresources. I don't know if we can (or should) restrict cookies on framed document requests, or actual navigations, in any web-compatible way.

(Restricting first-party cookies doesn't have any effect on privacy that I can see, but it has nice properties w.r.t bandwidth and header size)