Cookie Store API

[o-t-w]

Request for position on an emerging web specification

• WebKittens who can provide input:

Information about the spec

• Spec Title: Cookie Store API
• Spec URL: https://wicg.github.io/cookie-store/
• GitHub repository: https://github.com/WICG/cookie-store

Design reviews and vendor positions

• Mozilla standards-positions issue: Cookie-Store API mozilla/standards-positions#94

[othermaciej]

There is also a TAG review request here: w3ctag/design-reviews#290

[annevk]

This comment by Ehsan on the Mozilla issue still seems applicable and relevant:

Basically I think this API mostly achieves only one of the motivations stated in https://wicg.github.io/cookie-store/#intro-motivation, that is, providing cookie access to service workers, but as far as I can see doesn't really help address the other points mentioned in the Motivation section, such as lack of interoperability in processing cookies among browsers and divergent specs and UA behaviours. Perhaps I'm missing something but I believe if all major browsers just adopted the current Cookie Store API, it would help with none of the problems this research is highlighting for example: http://inikulin.github.io/cookie-compat/.

Another thing that makes me uncomfortable with the existing API is that it provides scripting access to new data about cookies which the platform currently doesn't provide (domain, path, expires, secure, and samesite). It is unclear to me if access to this extra data is completely OK, especially given the fact that it allows scripts to examine the properties of cookies set by scripts coming from another origin. The current spec is silent on any privacy implications. But I believe if Gecko would one day consider implementing this spec with the intention of shipping it, we should probably have a discussion about whether we'd like to expose this new data to the Web platform first.

Based on that I'm adding concerns: API design, concerns: complexity, and concerns: integration.

[hober]

Marking this as blocked until the identified issues are addressed.

[rik]

Is https://bugs.webkit.org/show_bug.cgi?id=258504 an indication that WebKit's position has changed?

[johnwilander]

I don’t know if we’ve had a chance to communicate our latest analysis but it’s important for us that no cookie metadata is exposed through this API. The old document.cookie API provides key+value and that’s the only thing that should be exposed. User agents should be at liberty to honor, change, or not honor cookie directives, and webpages should not be able to check which decision the user agent made. This is important to be able to protect the user and enforce a cookie policy without websites pushing users to change settings.

[annevk]

Yeah, couple of things to add to what John said above:

1. There is no change in position as we do not have a position.
2. Cookie Store API #36 (comment) still stands.
3. We see value in providing asynchronous access to cookies (synchronous access to network state is very far from ideal), provided the capabilities of document.cookie are not exceeded.
4. Parity with document.cookie as a goal resolves some of the concerns as not being able to represent all cookies would no longer be a problem, for instance. It would just be how API cookies "work".
5. We're experimenting to see if a subset of the Cookie Store API can meet all these goals. (In particular when getting a UTF-8-compatible cookie you can only see its value. Not its various attributes.)

It would be interesting to know if @inexorabletash, @ayuishii, et al. could see eventual convergence on this set of ideas so we might all end up with the same API.

[inexorabletash]

Modulo compatibility with deployed content, converging on the above seems reasonable.

Usage of the API per https://chromestatus.com/metrics/feature/timeline/popularity/2510 is higher than I would have expected, so research (as you're doing) would be necessary to ensure a subset of what Chrome currently ships is feasible.