Cookie Store API

[pwnall]

Hello TAG！

I'm requesting a TAG review of:

• Name: Cookie Store API
• Specification URL: The current specification is a placeholder, please ignore
• Explainer, Requirements Doc, or Example code: Explainer
• Tests: cookie-store
• Primary contacts: @pwnall and @inexorabletash

Further details (optional):

• Relevant time constraints or deadlines: feedback by June 22 would be ideal, feedback by July 16 would still be quite useful
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

We are especially interested in feedback around developer ergonomics, such as API shape and naming.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback

[annevk]

My main worry here is that document.cookie itself is rather buggy: https://github.com/whatwg/html/labels/topic%3A%20cookie. whatwg/html#804 in particular suggests that we don't understand the layering on top of the RFCs, which seems problematic if we're adding another API.

[pwnall]

@annevk "rather buggy" isn't very specific / actionable. I would prefer that we focus on concrete concerns.

After reading whatwg/html#804 it seems to me that the problems discussed there fall into two buckets: parsing HTTP header values and character encoding.

This API addresses the parsing issue by switching away from cookie line strings (HTTP header values) to dictionaries where cookie properties are already parsed. Granted, parsing concerns still leak through -- we currently disallow writing a cookie whose name is empty and value contains = to avoid parsing ambiguities. More feedback / help in this area is definitely welcome!

We plan to side-step the encoding issue by using USVString in the specification. The proposal currently states that cookie names and values are serialized using UTF-8. While @bsittler really cared about the latter, I don't see a lot of value in internationalizing an internal detail such as cookies, so I'd be fine with heavily restricting the supported cookie names/values (for example, to printable ASCII) if that's what it takes to get consensus here.

I understand the list of problems above may be limited by my perception and experience, and I'm looking forward to learning about any additional concerns you have. I think it would be best to discuss each concern as a separate issue in https://github.com/WICG/cookie-store/issues because I find it hard to follow mega-issues such as whatwg/html#804.

[annevk]

Even within the ASCII range it seems there's ample room for concern given the constraints put on HTTP headers (that these will eventually be serialized as). It's hard for me to get into specifics without doing all the necessary research to solve the issues myself.

[hadleybeeman]

We've discussed this in our W3CTAG meeting. It would be great to see use cases written out in your explainer, so that we (and implementers) can see what problem you're setting out to solve here — who wants this and why.

It would also be useful if you could describe in your explainer the alternative approaches you considered to solve that problem, and why you decided not to go with them.

Also, have you talked to the IETF? They'll obviously have an interest in anything cookie-related; would be good to get them involved if you haven't already.

[hadleybeeman]

Hi @pwnall and @inexorabletash! Just checking in on this, since it's on our TAG agenda for this week. Do you have comments or thoughts on the points above?

[pwnall]

@hadleybeeman Sorry for the delayed response.

We added a use case section to the explainer. We've been talking to @mikewest who is an editor of the IETF RFC on cookies.

[mikewest]

Hey, @hadleybeeman! I agree that we should work through the ways in which document.cookie does strange things. I don't really think that's in the IETF's scope, however. The cookie RFC defines the storage mechanism (to some extent), and the HTTP-based delivery mechanism. It does not define the document.cookie interface (nor, as @annevk notes, does it do a good job explaining what the document.cookie interface actually does).

One of the things on my list with RFC6265bis is to go through the places in which browsers' behavior diverges from RFC6265, and to adjust the specification accordingly. I haven't taken the time to do that work. I'm hopeful it'll get done this year, but it's not going to get done this quarter.

[hadleybeeman]

Thanks so much to both @pwnall and @mikewest for the thorough replies on this — it looks great.

We'd love to see the spec whenever it's ready.