Disable Set-Cookie also + other storage about webappsec-permissions-policy HOT 13 CLOSED

/cc @mikewest

from webappsec-permissions-policy.

Why would this be useful?

I'm thinking that we should isolate subpaths with the suborigin header (when the design is done). This will not disable Set-Cookie nor other storages, however, it will not be possible to access cookies and storage if they were sat outside of the suborigin.

from webappsec-permissions-policy.

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.

from webappsec-permissions-policy.

Hmm, cookie-scope and secure modify behavior of a feature, whereas FP is targeting on/off toggles. Origin-Policy might be a better fit here. A few options:

1. We can pull out cookie entirely out of FP and defer it to Origin-Policy
2. We can modify FP to block both document.cookie and Set-Cookie
3. We can do both

Personally, I see (3) and (2) as redundant if (1) exists. Mike, wdyt?

from webappsec-permissions-policy.

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.
DNT is a general signal that can communicate user agreement in a cache friendly way (using the site-specific tracking protection API https://www.w3.org/TR/tracking-dnt/#exceptions ) but support for it is limited, and it relies on legal compunction which is jurisdiction dependent. Hopefully in the future there will be better support for the DNT API and widely accepted norms for responding to it, but in the meantime first-party sites need a better way to ensure privacy/security for their users (other than only embedding particular contracted parties).
An Origin-Policy manifest could be the best place for many of these things, to minimise response header bloat, and also to leverage caching. DNT already has an origin wide JSON resource (the Tracking Status Resource TSR at /.well-known/dnt) and the EFF introduced their own flavour (text only) at ./well-known/dnt-policy.txt, which makes the browser extensions that use them have to GET both. One idea could be to contain the TSR in an object property of the Origin-Policy manifest, then there would only have to be one GET per site for everything. The TSR already has a "Compliance" array property that could hold the EFF policy Url. The cookie and other storage rules could go into a similar embedded object.
Mike, this is already a problem for JavaScript in frames, for example Firefox throws an exception on accesses to LocalStorage if third-party (only visited) blocking is enabled, so code must already have to take that into account.

-mikeo

from webappsec-permissions-policy.

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.

from webappsec-permissions-policy.

+1 to @ojanvafai's comment.

That aside, we have two different threads here:

• We disable access to document.cookie but allow Set-Cookie: we need to decide if that's OK, if we want to disable both, or if we want to pull out cookie feature entirely out of FP and defer it to CSP. I'm still leaning towards the latter - see #35.
• We might want to disable other storage API's.. Commitment & demand from real-world sites would be really helpful, alongside a clear explanation of what we're trying to solve.

from webappsec-permissions-policy.

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 document.cookie specifically, because it's a terrible API (and synchronous, to boot), then FP seems right. It doesn't seem like we'd be forced to neuter the Set-Cookie header with the same directive, and in fact, I think we would probably still allow a new asynchronous, non-blocking, sane JS cookie read/write API, even when document.cookie is disabled.

(This argument seems to me like advocating removal of Node.appendChild just because we're disabling document.write)

from webappsec-permissions-policy.

Had a chat with @mikewest and I believe we concluded that keeping the binary on/off for document.cookie + Set-Cookie header in FP makes sense. As in, same directive should toggle both. This is useful because FP's disable policy cascades down.

That said, one practical implication of this is that for disable Set-Cookie to be enforced on top-level context, the FP policy has to be delivered via a header, and the client has to wait to receive all headers before it acts on them -- i.e. order of headers does not matter. However, in practice this is already the case for CSP and preload, so this shouldn't be anything new.

from webappsec-permissions-policy.

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.

from webappsec-permissions-policy.

@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.

from webappsec-permissions-policy.

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.

from webappsec-permissions-policy.

@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.

from webappsec-permissions-policy.