Cookie-Store API

[bakulf]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Cookie Store API
• Specification or proposal URL: https://wicg.github.io/cookie-store/

[marcoscaceres]

@bakulf, anyone in particular you'd like to tag to review the spec and provide feedback?

[bakulf]

The spec is still in an early state and many sections are unwritten yet. But at the same time we have a good WPT coverage. I wrote some code to implement part of this spec, but I wonder if somebody else has feedback.

[annevk]

See https://github.com/w3ctag/design-reviews/issues/290#issuecomment-394959991 for some high-level concerns.

[dbaron]

/cc @ddragana @martinthomson @bzbarsky for additional feedback on this.

The goals stated in the explainer seem reasonable to me -- though I suppose a counterargument to them is that we'd like cookies to disappear and having them not be available on workers helps with that. (Unfortunately, in reality, having them have poor performance characteristics probably doesn't help with that.)

@annevk, I'm not sure I understand what your concerns are. Do they imply opposition to the existence of the API or concerns about the details of how it's being done?

[martinthomson]

Over time I would like to see old janky APIs go away, so I don't think that this is terrible. I have a hard time getting excited about implementing it - it's the sort of long-term work that doesn't have any good short-term payoffs for the cost of implementation - but that's not the assessment we are looking for here.

I interpret Anne's comments as suggesting that there might be more work involved than the proposal contemplates, that's all. Some of the open issues are negated by detaching from the HTTP header grammar, and a whole new tranche are added. I haven't reviewed the details there, but we'd need to be careful about quoting rules and the like.

This could be more opinionated about what it deems to be valuable and consider limiting this to writing of __Host--prefixed names only, and never passing cookies that aren't Secure. I'd like to have a discussion about that sort of question before we started on it.

I'm worth prototyping on this, with the recognition that there are probably other things that we should be investing effort in ahead of that.

[annevk]

I'm concerned about the details. As there's still issues with document.cookie it's unclear that this new API got the architecture right (as such architecture hasn't really been defined to layer things on top on).

It's also not entirely clear to me the API is sound as the design decisions made don't really match those made elsewhere for map-like structures. (Some of these are reported as issues and the issues are still open, so this might sort itself out.)

The other concern with this API is that there's no simple key/value storage API in workers, meaning it's likely this would be abused for that.

[marcoscaceres]

Could we get an official "worth prototyping" on this?... given that we've literally done some prototyping on it (as per https://github.com/mozilla/standards-positions/issues/94#issuecomment-401760556).

I have it in the W3C WebApps WG charter for me to migrate it over, so a formal position would be nice (Google folks are also wanting assurance we are onboard that we think this is generally a good idea, even if it's still a little rough around the edges):

https://github.com/WICG/cookie-store/issues/105

[annevk]

I'd rather we use defer here as it's not clear to me what the right call is. In particular with the anti-tracking work we're doing and how that is impacting APIs such as document.cookie (see https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/ for how Safari deals with it), moving ahead with more granular cookie access seems like a bad call.

[marcoscaceres]

I’m ok with defer also. However, I’d like to have some kind of position from us to know if I should adopt the spec or not. We were the only potential backers of it, so if we want to defer, we can leave it at the WICG for now.

[ehsan]

I agree with @annevk's concerns. 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.

I'm also OK with defer until a later time.

[ayuishii]

Hello all!

Thank you for discussing the Cookie Store API spec. I'd like to request another review since the spec and motivation has been updated from the previous iteration. Some of its updates include addressed feedback from TAG review and changes to encourage secure cookies.

Additional Info

• TAG Review: https://github.com/w3ctag/design-reviews/issues/469
• Explainer: https://github.com/WICG/cookie-store/blob/main/explainer.md
• Specification or proposal URL: https://wicg.github.io/cookie-store/

Some Key Changes

• Addressed feedback from TAG & security review
  • Some changes include...
  • Write only secure cookies
  • Updated API interface for set() / get()
• Updated motivation: Removal of cross-browser incompatibilities

[annevk]

Thanks, I'll reopen this so we can reconsider.

It seems rather problematic to ignore inconsistencies across browsers as those could influence the shape of the API. Also, all browsers are considering or have shipped pretty drastic changes to third-party cookies, as well as the document.cookie API in general (i.e., including in first parties), and that might well impact the API shape too.

[domenic]

It seems rather problematic to ignore inconsistencies across browsers as those could influence the shape of the API.

I think that isn't quite an accurate take on the draft. Rather, it's delegating the cookie data model questions to https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis (which is making significant progress around the interop issues). On top of that pretty-solid foundation, it:

• Takes further steps to ensure interop this time around, by being more precise than the document.cookie spec. (Example: specifying the UTF-8ness of how the bytes are interpreted.)

• Restricting bad edge cases from ever being possible via the writing side of the API. (Example: prohibiting cookies with name = empty string, value = empty string, or name = empty string, value contains the equals sign.)

It is true that, given a weird preexisting cookie string (such as the ones from http://inikulin.github.io/cookie-compat/), it relies entirely on the foundation in https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis to parse those into the base data model, which then gets surfaced unchanged via the JS API. But that seems like good layering to me.

[ayuishii]

Thanks for re-opening this issue!

I believe changes to third-party cookies in the future won't affect the shape of the API, just what may be returned by the API. If third-party cookies were to disappear, the API will work the same way but would return fewer cookies.

The API also adds many other restrictions and defaults that hope to encourage better decisions around security including defaulting to SameSite "strict" and has restricted usage to secure contexts only, while allowing writes for only secure cookies.

[AnthonyLenglet]

Checking back on this API, as since the last activity here, chromium has officially added support for the API back in version 87

I won't be able to give too much insight into the api itself, but I will say that seeing something like this get a full support accross the board would really help clear up this messy part of web development, especially since cookies are still used in newer web apps, as it is still being recommended by bodies like OWASP (not to mention the very rich trove of packages npm)

[annevk]

@domenic I forgot to note this here, but https://github.com/WICG/cookie-store/issues/189 and https://github.com/httpwg/http-extensions/issues/1073#issuecomment-710012476 show a pretty fundamental problem that wasn't resolved (and still isn't). It seems somewhat suboptimal to me to not expose a set of cookies the RFC considers valid.

[Playit3110]

Is the implementation still stuck?

[Atulin]

Seeing how many years it's been, I'd say so, yes

[jesup]

After some discussions with people at Apple, and in light of our comment above by ehsan, we plan to switch from 'defer' to 'positive', with the caveat that it's only for the subset of the API that matches what is exposed by document.cookie. I expect the upcoming implementation from Safari/Webkit will implement the same subset; the draft authors hopefully will update the proposal to restrict it likewise.