standards-positions icon indicating copy to clipboard operation
standards-positions copied to clipboard

Cookie Store API

Open o-t-w opened this issue 2 years ago • 9 comments

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: https://github.com/mozilla/standards-positions/issues/94

o-t-w avatar Jul 13 '22 20:07 o-t-w

There is also a TAG review request here: https://github.com/w3ctag/design-reviews/issues/290

othermaciej avatar Jul 18 '22 23:07 othermaciej

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.

annevk avatar Oct 18 '22 11:10 annevk

Marking this as blocked until the identified issues are addressed.

hober avatar Mar 29 '23 18:03 hober

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

rik avatar Jul 04 '23 09:07 rik

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.

johnwilander avatar Jul 04 '23 12:07 johnwilander

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. https://github.com/WebKit/standards-positions/issues/36#issuecomment-1282266977 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.

annevk avatar Jul 04 '23 16:07 annevk

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.

inexorabletash avatar Jul 05 '23 18:07 inexorabletash

The release notes for 17.2 say "Added the change event for the Cookie Store API. (113809948)" It would be good to get some clarity on what parts of the API are supported. https://developer.apple.com/documentation/safari-release-notes/safari-17_2-release-notes

o-t-w avatar Oct 29 '23 19:10 o-t-w

Given that the API is still behind a "testable" flag, I have a feeling the mention in the 17.2 release notes is a mistake and should be removed.

rik avatar Oct 29 '23 19:10 rik