Contact emails
msr...@chromium.org, mk...@chromium.org
Spec
https://w3c.github.io/webappsec-clear-site-data/
Summary
We implement a ‘Clear-Site-Data’ HTTP header which prompts the user agent to clear browsing data associated with the requesting website. The supported browsing data types are cookies, storage (i.e. “site data”), and cache. Data will be deleted for the requesting origin, except for cookies and channel IDs (part of storage) which are more broadly scoped, and will be deleted for the entire eTLD+1.
Motivation
This is a privacy and security enhancing feature. A sensitive website can trigger local data deletion after the user signs out. A website dealing with a persistent XSS attack can use this to ‘reset’ itself to a clean state. See examples.
Interoperability and Compatibility Risk
There is a demand for such feature from developers.
Discussions on w3c mailinglists give feedback on details, but no pushback on the feature itself.
It is conceivable that vendor implementations differ (e.g. interpret some data as part of ‘cache’ instead of ‘storage’), what can be addressed by refining the storage specification. However, given this feature’s use case as a last line of defense, this does not pose a risk.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/features/4713262029471744
Requesting approval to ship?
No.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Will the reset also be able to apply to stored permissions (geolocation, cameras, microphones)? We have a statement in the Mediacapture spec that permissions for devices should be cleared at the same time as cookies, without specifying UI in detail; it's unclear from the spec if this was considered for this option.
I'm nervous about whether spoofing will be easy or hard; if it's not hard, it is a disruptor function. But I guess the W3C discussions have covered that in some detail.On Fri, Apr 29, 2016 at 6:04 PM, Charlie Reis <cr...@chromium.org> wrote:+1 to concern about abuse, and possibly limiting this to secure connections. A MITM on an HTTP page can do many of these things already (e.g., modify cookies), but forcing a reload of all frames (as mentioned in the spec) is a more disruptive and destructive operation.
Forcing a reload of all frames is also tricky to implement correctly. Have you thought about pages with beforeunload handlers, which might try to survive this action? Will you bypass such unload handlers, possibly losing data? Also, be sure to consider the effective origin of about:blank pages, which might be inherited from another frame.
Charlie
password manager auto sign-in