Setting and clearing data in same response

[triblondon]

From the recent TAG review:

We'd like it the spec to expand on how user agents should treat responses that attempt to create new local data in the same response as a clear-site-data header which would delete it. For example, if a response contains both Clear-Site-Data: cache and Cache-Control: max-age=86400, should it be cached? If a response contains Clear-Site-Data: cookies and Set-Cookie: foo=bar, should it create a cookie?

[jimbo2150]

I to was confused by this as well. I suggest a date be added so that content can be removed prior to the given date so that new content, cookies, etc. will be stored and only stored data prior is removed. Most browsers offer a remove content function in their settings with a date value such as "today," "since yesterday," "this month," "since the beginning of time," etc.

For example:
Clear-Site-Data: cache, prior=2017-09-07T12:55:24+00:00
Should remove cached content prior to August 7, 2017 at 12:55:24 GMT.

I recommend that if the date is in the future or not included (omitted) it should be assumed that all content, even newly set cookies/data should be removed.

Use case: when a site has been attacked or has had an issue where a prior cookie or data is causing issues with browsers correctly loading the site (or possibly caching a redirect that should not exist), the clear-site-data header can be set to indicate that data older than a given date should be invalidated.

Obviously a similar option should be added to the JS API:

navigator.storage.clear({
  types: [ "cache" ],
  prior: new Date('2017-09-07T12:55:24+00:00')
});

[triblondon]

Interesting idea, though note that this suggestion is actually the opposite of how browsers typically offer such granularity. In chrome, for example, I can clear data from "the last hour", which removes data created in the last hour, not data created more than an hour ago.

[annevk]

And that isn't actually granular. No browser keeps storage transactions on a per-origin basis as far as I know. They just remove storage of sites touched in the last hour.

[annevk]

This issue would mostly go away by the way if we define low-level storage primitives and define all this in terms of that. Coupled with defining in Fetch the point at which this header is processed relative to the Set-Cookie headers. (And then there's always the question whether browsers can get their network stack in order to actually make it do the things we want it to do.)

It's still a question at that point of course what we actually want the examples in OP to do. Is removing first and then storing a cookie acceptable? Is removing whenever you get a response (whether from cache or network) that contains the header acceptable? Not sure, but both seem reasonable.

[slightlyoff]

The primary use-case of handling storage eviction after an incident won't be addressed by better primitives (unless the discussion is about ease of specification). It'd be great to have a better defined processing model here, of course, and that would help address the concern about eviction and setting in the same response.

Per usual, would love to see an explainer which would help illuminate some of these discussions.

[annevk]

(unless the discussion is about ease of specification)

It's about correctness.

[annevk]

(Not sure why you'd think it's about ease of specification. What I suggest seems notably harder to achieve.)

[msramek]

To the original question about setting and deleting cookies, it's been clarified in the spec that Clear-Site-Data wins over Set-Cookie.

I think the spec doesn't actually comment on cache. The behavior should be the same, but I'm not 100% sure if that's what our current implementation does.

Both of these questions should be again much clearer from the fetch integration (issue #40 ).

Regarding the increased granularity, this is still one of the most common pieces of feedback for Clear-Site-Data. Some of those are very complex, but specifically for time-range-based deletion, you're right that most browsers already support that in their user-facing features. I agree with @slightlyoff that we may have that discussion over the explainer. @mikewest has just landed one.

[slightlyoff]

Sounds like this is resolved. Can we close it out?

(discussed at today's W3C TAG F2F)

[kennethkufluk]

it's been clarified in the spec that Clear-Site-Data wins over Set-Cookie.

It's not completely clear to me, but it seems that the note in 3.2 says that data is cleared after cookies are set. I'd like to understand that decision. I'm considering the clear-site-data header when logging out of our site, but need to keep a cookie or two for various reasons (visual settings like night mode, language, text size, possibly preserving experiment buckets, as well as tracking across sessions for abuse detection).

The most obvious thing to do is to send Clear-Site-Data: "Cookies" together with Set-Cookie headers to preserve the cookies we still need.

Since the cookies set by the response come from the same authoritative source as the "clear-site-data" header, then the new cookie values should be considered trustworthy. So I don't understand the argument in the note.

Two questions:

1. Can we change the spec to say that data will be cleared first and then cookies will be set as requried by set-cookie, and then the response will be rendered?
2. What is the behaviour of current implementations?

Edit: tested in Chrome 74. It does indeed ignore the set-cookie headers.