CSP 4 feature request: cookie policy

[AliceWonderMiscreations]

I would love it if in CSP-4 a policy could be set regarding third party cookies. Default behavior should be always send (if no policy is set) but I would love the ability to say "Only send third party cookies for these domains" and the browser would simply refuse to send cookies, even if it has them, to any domain not in the white-list when requesting the resources.

It would make me feel a lot more comfortable about using some common CDNs out there like code.jquery.com if I knew for a fact that any cookies my users might have are simply not being sent with the request for jQuery.

The other day I disabled privacy badger to see what the facebook WP plugin was doing on a site I frequent - because the site was http, the iframe for the facebook like button was also http. And included a JS file that contained personal information about me. Sent over HTTP.

The site removed the plugin right away when I told them (I have screenshots from Inspect Element), but the carelessness of trackers is often so profound that I think a CSP 4 directive allowing the web application to specify a whitelist of where cookies may be sent would be of great benefit to users who don't know to install something like Privacy Badger.

As long as default is to send all cookies when there is no policy set, it would be completely backwards compatible.

[dveditz]

Would the crossorigin="anonymous" attribute setting for individual elements do what you want? Not quite because it would require more page edits than a page-global policy, but breaking all 3rd party cookies is likely not what you want anyway.

The crossorigin attribute isn't available on all elements (that could be a feature request for the HTML spec), but does already exist for <script>.

[AliceWonderMiscreations]

Breaking third party cookies is what I want. The problem is that WordPress is not safe to not update, plugins often sneak new trackers in. Symphony has literally nobody checking the integrity of an update, if the developer wants to add trackers they can, etc.

So a policy saying "block third party cookies except from these white-listed domains" can be very beneficial in avoiding surprise tracking after an update. Especially if you have a liberal img-src policy as many sites do.

[annevk]

Note that setting the crossorigin attribute would also require the response to opt into CORS.

[Malvoz]

Would the ability to enforce cookie flags such as Secure, HttpOnly, SameSite etc. have to be considered?

[AliceWonderMiscreations]

I'm not sure. What I'm personally looking for is a way to tell a browser "Only send cookies to third parties if they are in this white list" - kind of like how PrivacyBadger operates but defined by the CSP header rather than requiring the user have privacy badger installed and understand how it works.

The issue I'm trying to deal with is when updates to a webapp plugin (e.g. WordPress) sneaks in a new tracker, which I have seen happen before. Especially with GDPR I think it is important for webmasters to have the ability of defining who their site may be a tracking source for.

[dveditz]

Given your April 16 comment would a site-wide policy be fine? We're discussing wrapping up CSP evolution with CSP-3, and while I'm sympathetic to your use case CSP may not be the best fit. If a site-wide policy is good enough (easier to manage in any case) then the proposed Origin Manifests could be a better place for this. https://github.com/WICG/origin-policy

If you need per-document control then CSP (or a new single-purpose header-based mechanism) is more appropriate.

[Malvoz]

In w3c/webappsec-permissions-policy#16 it seems it was decided for cookie control to live in origin policy as @dveditz suggested.

@AliceWonderMiscreations
Do you want to open an issue over there?

[AliceWonderMiscreations]

No issue, I am fine with that, feel free to close as far as I'm concerned.