Classify cookies as site storage

[davidsgrogan]

Where did the "network storage" divide come from? I think of cookies as more like site storage since they are accessible to script. The http cache isn't AFAIK. Further, considering cookies as site storage gets us closer to the ideal of being able to pitch the "first-run" story to developers: if your origin gets purged due to quota pressure or navigator.storage.purge() you don't have to have any special logic to handle it, it will appear that the user has never visited your site before, so your first-run logic will suffice. Obviously, if we don't purge cookies then this story is a lie.

@slightlyoff said it well in his original durable storage page:

what is an application without its Service Workers, Caches, Databases, Cookies, and all the rest? How is a developer meant to reason about having some but not all of these?

Of course we can't guarantee that the user hasn't modified any data locally, e.g. they could have deleted the IDB directory from the browser's profile directory and left the cookies, but at that point the user is on their own.

[annevk]

Perhaps purge() should also consider cookies. Problems with making cookies part of site storage:

• Doing quota properly (in Gecko this is an issue I think)
• How would persistence work?
• Cookies are not origin-bound

Also, if purge() doesn't purge HTTP cache entries, it's still not quite like first-run, is it?

[davidsgrogan]

• Quota: Chrome doesn't currently count cookies in quota calculations either. But we should.
• Persistence: I assume you mean because cookies have expiration times. If so, unclear. But we could say if an origin's default box is persistent then any cookies it can access are also persistent. Where persistent means the browser won't clear them without user intervention, unless they expire.
• Site vs origin: As mentioned above, we could say that any cookie accessible to an origin is treated as persistent if the origin's default box is persistent.
• HTTP cache entries: from the perspective of script logic, it is like first run, except the page might load a bit faster.

These are hairy issues but I'm sure we can tackle them to make devs' jobs easier.

[annevk]

Script can detect HTTP cache entries through timing and can soon even tell through an API whether resources are cached. The UI for clearing cookies needs to clear both network and site storage, otherwise they can be revived.

I guess I would be okay with putting cookies into the other bucket. I wonder what @sicking thinks.

[mikewest]

/ccing myself, as we should do sane things here wrt Clear-Site-Data.

[mikewest]

The big issue with cookies is that they aren't origin-scoped. That is, subdomain.example.com has distinct localstorage with other.example.com, but shares .example.com cookies. It's not clear that there's a good way to model that in an origin-based system.

Clear-Site-Data currently says something like what you're suggesting, @davidsgrogan, in https://w3c.github.io/webappsec/specs/clear-site-data/#clear-cookies. It's not really clear to me whether that's the right answer, but it's at least internally consistent.

[sicking]

I don't have an opinion about this.

[annevk]

@davidsgrogan did you figure any of it out? I'm still a little hesitant to group cookies as they are clearly not origin-scoped and are much more a network-affair than what we cover thus far.

[inexorabletash]

Looping in @bsittler (who won't be able to respond for a few weeks) and @dmurph, who have both been thinking about Cookies vs. storage a bit recently.

[dmurph]

Ah, so, just to chime in here:

We determined that the only 'safe' way to keep or clear cookies is treat them on a 'registerable domain' scope. This means, basically, eTLD+1. So if you're keeping cookies for a site, you need to keep all cookies for that registerable domain, and if you want to clear, you have to clear all cookies for that registerable domain.

Sites often do this kind of cookie usage/communication: plus.google.com -> google.com -> accounts.google.com. So clear accounts.google.com would kill all google sites (at the very least log you out). Websites don't expect this state to happen, so while google might make things technically still 'work' (or make it recoverable), other sites might be in a permanently broken state until all cookies are cleared.

[annevk]

@dmurph right, so you'll put cookies in network storage then and not mix them with site storage?

What about UI though? When the user clears storage, they probably expect cookies to go away too, no? Should the UI always clear on a registrable domain scope?

[annevk]

Also, what does that mean for #4? clear() will only replace an origin's site storage unit's box?

[annevk]

Closing this as I still don't think we want to do this.