-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable Set-Cookie also + other storage #16
Comments
/cc @mikewest |
Why would this be useful? I'm thinking that we should isolate subpaths with the |
My original intent was to pull the core of https://w3c.github.io/webappsec-csp/cookies/ into feature policy. It might be a better fit for https://mikewest.github.io/origin-policy/, though. shrug On/off toggles for other forms of storage are probably reasonable to add, though I'm not sure they'll be as easily deployable as you'd like, Mike, given that we'd hide the interface, and probably break frames' JavaScript entirely if they weren't prepared for the policy. |
Hmm,
Personally, I see (3) and (2) as redundant if (1) exists. Mike, wdyt? |
Ilya, Its useful because it gives more control to the first-party sites, who have the legal responsibility. Third party embedees cannot usually converse with the user to get their consent etc, while first-parties can (& must in Europe), and if their ability to use document.cookie can be controlled why not also the return of Set-Cookie headers by other resource types. -mikeo |
I forked this discussion about OriginPolicy elsewhere. I think that's different from what specific things we should include in FeaturePolicy/OriginPolicy/ContentSecurityPolicy. #35 @michael-oneill we're trying to focus V1 of this on things that have obvious value and that have a clear path towards wide adoption. I'm not questioning the value of limiting storage APIs, but it would help to have an actual web site or company committed to using it. To be clear, I expect V2 to be a quick followup to V1, we just want to focus on getting the basic infrastructure out there as soon as possible and too much discussion of individual toggles slows getting V1 out there. |
+1 to @ojanvafai's comment. That aside, we have two different threads here:
|
If we're pulling cookie support out of the platform for security reasons, then CSP seems like the correct place to do it. That already provides a way to define security policies to be enforced by the browser, and we can disable all access to read or write cookies, as the site deems appropriate. On the other hand, if we want to remove (This argument seems to me like advocating removal of Node.appendChild just because we're disabling document.write) |
Had a chat with @mikewest and I believe we concluded that keeping the binary on/off for That said, one practical implication of this is that for disable |
OK, good compromise. But how about having an entry for FP in the Origin-Policy. A header can override it but having it in a cacheable resource would help reduce header bloat. Once the OP exists it will be managed by the privacy/security teams so it would make sense to have all these things declared in one place anyway. |
@michael-oneill assuming Origin-Policy is a ~header delivery mechanism, then what you're describing is implicit.. I don't believe we need to do anything extra. |
Great. So FP is one of the allowed headers in the manifest that is fine. Is there going to be a blacklist or a whitelist of headers in the OP? I would like to lodge a request for the Tk header to be allowed also, which is the server response to a DNT request. https://www.w3.org/TR/tracking-dnt/#responding A minor change to this could allow sites to specify the DNT Tracking Status Resource within it and therefore the OP manifest, to improve efficiency. |
@michael-oneill apologies about the delay, missed this.. Re, whitelist/blacklist: that's a question for the OP spec, I suggest we open an issue there. In the meantime, closing this, as there is nothing spec-actionable for FP here. |
It would be useful to also disable cookie storage via Set-Cookie headers as well as document.cookie writes, i.e. not just for iframes but for any resource.
Along the same lines it would also be useful to have disable feature directives for localStorage, indexDB etc.
The text was updated successfully, but these errors were encountered: