Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cookie Store API #36

Open
o-t-w opened this issue Jul 13, 2022 · 9 comments
Open

Cookie Store API #36

o-t-w opened this issue Jul 13, 2022 · 9 comments
Assignees
Labels
blocked Coming to a position is blocked on issues identified with the spec or proposal. concerns: API design The API for this is error-prone, poorly named, or inconsistent with the platform concerns: complexity This proposal seems needlessly complex concerns: integration Can't be used w/ other web platform features (or unclear what happens if used together) from: Google Proposed, edited, or co-edited by Google. topic: http Spec relates to the HTTP (Hypertext Transfer Protocol) family of protocols topic: storage Spec relates to storage mechanisms such as cookies, IndexedDB, or LocalStorage topic: web apis Spec relates to web APIs (entry points for script) venue: W3C TAG Proposal is being reviewed in the W3C Technical Architecture Group venue: WICG Proposal is incubated in the Web Incubator Community Group

Comments

@o-t-w
Copy link

o-t-w commented Jul 13, 2022

Request for position on an emerging web specification

  • WebKittens who can provide input:

Information about the spec

Design reviews and vendor positions

@othermaciej
Copy link

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

@othermaciej othermaciej added venue: WICG Proposal is incubated in the Web Incubator Community Group topic: storage Spec relates to storage mechanisms such as cookies, IndexedDB, or LocalStorage topic: web apis Spec relates to web APIs (entry points for script) topic: http Spec relates to the HTTP (Hypertext Transfer Protocol) family of protocols venue: W3C TAG Proposal is being reviewed in the W3C Technical Architecture Group labels Jul 18, 2022
@othermaciej othermaciej added the from: Google Proposed, edited, or co-edited by Google. label Sep 25, 2022
@annevk
Copy link
Contributor

annevk commented Oct 18, 2022

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 annevk added concerns: complexity This proposal seems needlessly complex concerns: integration Can't be used w/ other web platform features (or unclear what happens if used together) concerns: API design The API for this is error-prone, poorly named, or inconsistent with the platform labels Oct 18, 2022
@hober hober added the blocked Coming to a position is blocked on issues identified with the spec or proposal. label Mar 29, 2023
@hober
Copy link
Member

hober commented Mar 29, 2023

Marking this as blocked until the identified issues are addressed.

@rik
Copy link

rik commented Jul 4, 2023

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

@johnwilander
Copy link

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
Copy link
Contributor

annevk commented Jul 4, 2023

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
Copy link

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.

@o-t-w
Copy link
Author

o-t-w commented Oct 29, 2023

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

@rik
Copy link

rik commented Oct 29, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Coming to a position is blocked on issues identified with the spec or proposal. concerns: API design The API for this is error-prone, poorly named, or inconsistent with the platform concerns: complexity This proposal seems needlessly complex concerns: integration Can't be used w/ other web platform features (or unclear what happens if used together) from: Google Proposed, edited, or co-edited by Google. topic: http Spec relates to the HTTP (Hypertext Transfer Protocol) family of protocols topic: storage Spec relates to storage mechanisms such as cookies, IndexedDB, or LocalStorage topic: web apis Spec relates to web APIs (entry points for script) venue: W3C TAG Proposal is being reviewed in the W3C Technical Architecture Group venue: WICG Proposal is incubated in the Web Incubator Community Group
Projects
Development

No branches or pull requests

8 participants