Re: Intent to Implement: Async Cookies API
Benjamin Wiley Sittler
Contact emails
Spec
See the explainer on WICG GitHub for further in-depth discussion of the proposal: https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md
This is experimental and so far there are just an explainer and a document-only polyfill ( https://github.com/WICG/async-cookies-api/blob/gh-pages/cookies.js ).
We want to implement this proposal to gain experience and turn the explainer into a formal specification.
Summary
This proposal brings an asynchronous cookie API to documents and Service Workers. This is important as it isn’t possible to read cookies from Service Workers today. Reading and writing cookies from document is also currently a synchronous IPC to the browser process, inducing jank on pages. Async access addresses both needs.
The API includes a CookieChangeEvent that will wake up service workers. Strategies for balancing power consumption vs. utility are discussed in the explainer, and will be explored further during implementation.
Sample for setting a new cookie:
await cookieStore.set('__Host-COOKIENAME', 'cookie-value');
console.log('Set!');
Sample for reading a cookie’s value:
let cookie = await cookieStore.get('__Secure-COOKIENAME');
console.log(cookie ? ('Current value is ' + cookie.value) : 'Not set');
The API also includes methods for deletion and change monitoring; in a service worker it allows choosing which in-scope request path to use for reading and change monitoring. See https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md#a-taste-of-the-proposed-change
Motivation
Service workers and document scripts sometimes need cookie access, for instance:
... to ensure private data is only displayed or sent while cookies representing user authentication in an unexpired session are still present, and
... to ensure data for one user account is not inadvertently displayed after a session cookie change caused by signing out and then signing in with a different account in the same domain (but potentially in a different origin, since many cookies are scoped more broadly than a single origin.)
An efficient monitoring API can be used to replace power-hungry polling cookie scanners.
Service workers needing access to cookies cannot use the synchronous, blocking document.cookie interface as they both have no document and also cannot block the event loop as that would interfere with handling of unrelated events.
A formal spec sufficiently detailed to allow interoperable implementations across multiple browsers (including Chrome) is the principal goal of implementing this feature behind a runtime flag in Chrome and should incorporate feedback from interested web and browser developers and also from interested members of the web standards community.
Interoperability and Compatibility Risk
Chrome would be the first browser to implement this API, and the initial implementation would be behind a runtime flag.
Edge: No signals (interest in collaboration from Edge-affiliated Cookie Change Events authors, though)
Firefox: No signals
Safari: No signals
Web developers: Positive
Ongoing technical constraints
The code will live partly in Chromium and partly in Blink, re-using some of the same infrastructure used by the chrome.cookies API available in extensions and by the document.cookie API available in document contexts.
This API will cause new service worker start-up after browser start-up in cases where a cookie monitored by the service worker expired while the browser was not running. This will not block other parts of browser start-up, however. Impacts can be mitigated by starting these serially and limiting total runtime.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5658847691669504
Requesting approval to ship?
No