Top level site partitioned cookies cleared by Javascript API
michael-oneill opened this issue · comments
Generating a Clear-Site-Data header may be difficult in many scenarios. There should be a way to delete partitioned cookies in script also,
At the moment sites can remove top-level cookies by writing to document.cookie, can clear localStorage etc., none of this is available for partitioned storage,
There was a Chrome experimental API for this, it should be made a standard.
There should be a way to delete partitioned cookies in script also
This sounds reasonable to me if we do not end up requiring that Partitioned cookies also have HttpOnly.
At the moment sites can remove top-level cookies by writing to document.cookie, can clear localStorage etc., none of this is available for partitioned storage
IIUC if we do allow Partitioned cookies to be accessed in scripts, then an embedded frame could use document.cookie or the CookieStore API to clear their cookies for only that top-level partition.
Yes it makes sense that embedded iframes can write to their own top-level partitioned cookies (unless HttpOnly of course), but I was only suggesting a top-level contexts being able to clear all storage, in its own origin as well as partitioned by any embedded origin, which the proposal already allows via the Clear-Site-Data response header.
We could slightly extend it by allowing top-levels to set partitioned cookies in embedded origins but only with the agreement of the embedded origin, which is already available as a capability via postMessage (the embedded context could refuse to recognise the message).
This would allow communication from top-level frames to embeds even when there was no embedded iframes e.g. to image subresources etc.. Maybe the subresource would allow the capability via a Permissions-Policy response header, with the target origin set by the domain property in CookieStore API.
This could enable the efficient communication of user consent state from top-level frames to subresources
Yes it makes sense that embedded iframes can write to their own top-level partitioned cookies (unless HttpOnly of course), but I was only suggesting a top-level contexts being able to clear all storage, in its own origin as well as partitioned by any embedded origin, which the proposal already allows via the Clear-Site-Data response header.
Actually, this proposal has changed and we are no longer giving top-level sites the ability to do this. Doing so would introduce an attack vector that top-level sites could use to interfere with code running in embedded frames.
We could slightly extend it by allowing top-levels to set partitioned cookies in embedded origins
We do not think top-level sites should be able to do this, since this would be a violation of the same-origin policy.
Maybe the subresource would allow the capability via a Permissions-Policy response header
An interesting idea, but is there a reason that top-level sites would need this type of mechanism to pass along first-party state to embeds when they already have JavaScript and could write state to the DOM or through server-side collusion?