Intent to prototype: CookieStore API

[Andrea Marchesini]

Summary: CookieStore API is an asynchronous Javascript cookies API for documents and service workers. Together with WebKit, we agreed to ship a subset of the originally proposed API to expose only the cookie details already available through `document.cookie`.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1475599
Specification: https://wicg.github.io/cookie-store/
Platform coverage: Firefox Desktop, Firefox on Android
Preference: `dom.cookieStore.enabled`
Link to standards-positions discussion: https://github.com/mozilla/standards-positions/issues/94
Other browsers:
* Chrome: shipped since 87 (Nov 2020)
* Safari: They are working on the implementation. No official release date yet.
web-platform-tests: /cookie-store

We plan to land a prototype that diverges from the official spec by the following points:

1. Only cookie names and values are shared via `CookieStore.get()`/`getAll()` methods. In this way, we do not expose more than what `document.cookie` already offers.
2. We don't implement the `CookieStoreManager` and the `ServiceWorkerGlobalScope.oncookiechange` event handler, with its `ExtendableCookieChangeEvent` event because we don't want to spawn ServiceWorkers at any cookie change
3. Following up on the previous point, `CookieStore.onchange` event handler is also exposed to ServiceWorkers.

[Daniel Veditz]

I'm very glad we're doing this. `document.cookie` is a horrible interface

We plan to land a prototype that diverges from the official spec by the following points:

I strenuously object to calling it an "official spec". It is a WICG proposal from a single vendor and not currently on any standards track.

1. Only cookie names and values are shared via `CookieStore.get()`/`getAll()` methods. In this way, we do not expose more than what `document.cookie` already offers.

Boooo! A major contributor to cookie-based attacks is the fact that duplicate names can be injected at different scopes, and documents/sites have no way to distinguish a real from injected cookie. The unique key for a cookie is name+domain+path and if we don't return all of those we have not helped the status quo much at all. If all you're allowed to know is 1/3rd of a cookie's key, the only secure choice is `__Host-` prefixed cookies (which have fixed values for domain and path). But those aren't always appropriate.

The domain values can only be the same or a subset of the current site's domain. The site already knows those -- you can't learn any secret sibling domain names. Similarly, the path values have to be a subset of the current URLs path or the cookie wouldn't have been served, so the currently page doesn't learn anything about sibling/parent/descendent sites from that, either. If there's a cookie that you didn't set then you could maybe learn things from the name and value, but that's already true for `document.cookie`.

Are you only supporting get() and getAll(), or do you also plan to support set() and delete()?

3. Following up on the previous point, `CookieStore.onchange` event handler is also exposed to ServiceWorkers.

Meaning we're not going to support CookieStore.onchange, right ?

[Daniel Veditz]

> Summary: CookieStore API is an asynchronous Javascript cookies API for documents and service workers. Together with WebKit, we agreed to ship a subset of the originally proposed API to expose only the cookie details already available through `document.cookie`.

It's not clear whether you plan to expose this to service workers. Here you've described it as an API service workers can use; below you only say you're not supporting the events. But but exposing cookies to ServiceWorker would contradict "only the cookie details already available through `document.cookie`" since service workers don't have access to that.