Cookie event batching and firing

[annevk]

@inexorabletash @DCtheTall @ayuishii could any of you help describe the cookie event batch semantics?

While in theory the current specification allows implementers to do whatever, I'm not convinced that's good enough. It seems quite conceivable that if one implementation batches for incoming responses and another doesn't, web developers will run into issues.

One thing I had in mind is that the IETF Cookies I-D provides a very low-level hook that is called whenever something happens. In theory this would allow for batching, but it might mean that other cookie changes that happen at the same time might also end up in the same batch.

An alternative might be Johann's suggestion of passing around some kind of batch ID when we know we'll process multiple cookies at once.

---

A related query here is when the event should be fired for eviction as it seems there might be some side-channel opportunities there. And we might also not want to continuously monitor for that.

And in particular when the end user evicts probably nothing should be fired and the website should be reloaded to reset state?

cc @johannhof

[annevk]

cc @trikolon @bvandersloot

[johannhof]

To rephrase a question I think Anne's comment is asking: Do we send events to active documents when 1) users are deleting cookies and 2) cookies expire naturally over time?

[annevk]

I have another question. What if you change and delete the same cookie in a single batch? How do you determine from these events what the current state of the cookie is?

[inexorabletash]

This public design doc might be helpful, but no guarantee it matches reality.

Recalling the intent, but not necessarily what is currently implemented:

• Do we send events when... users are deleting cookies? - We don't want a site to observe storage being cleared by the user and restore the storage, as this runs contrary to the user intent and could be abused by malicious sites for user tracking. So in general, when browsing data is cleared by a user we'd like to (a) clear all site storage not just particular elements and (b) now allow pages to maintain state across the action. I don't know if that's been implemented anywhere; I recall the desire to force-reload tabs and service workers in response to Clear-Site-Data, but I don't know if anyone does that. So... in an ideal world we wouldn't have events in this case. In the real world where some UAs have UI to allow users to delete specific cookies, I don't know what behavior we should have.
• Do we send events to active documents when... cookies expire naturally over time? - I believe we discussed firing events when the cookie store observably changes, which in Chromium would correspond to the next fetch after the expiry.
• What if you change and delete the same cookie in a single batch? How do you determine from these events what the current state of the cookie is? - I believe the Chromium implementation is effectively given a map of cookieName → newState , where the new state could be the new value, or that the cookie was deleted, expired, evicted, etc. The implementation divvies those up between the changed and deleted lists, so the same cookie wouldn't appear in each. (Looking at the code, I don't have full confidence that it's actually a map, rather than a list. May require more digging.)

@ayuishii may remember more

[annevk]

Thanks, overall that makes sense as a model to standardize I think. Might need some more thought on how to handle naturally expiring cookies. But perhaps only expiring at the time of a next request or explicit document.cookie or Cookie Store API call (I'm assuming those are also synchronization points) is reasonable.

As for changes, so if you make multiple changes to a single cookie in a response, you'd only get a single event for only the last change. That's fair, but I don't think that's currently defined at all.