Intent to Ship: Cookie Store API on local secure contexts

[Frédéric Wang]

Hello,

For more general context about this, see https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/qtMVkfpd3_U/m/0NFYkxaMAwAJ and https://chromium-review.googlesource.com/c/chromium/src/+/2831586

Contact emails

fw...@chromium.org

Explainer

None

Specification

https://wicg.github.io/cookie-store/

Design docs

https://html.spec.whatwg.org/multipage/webappapis.html#secure-context
https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url

Summary

The Cookie Store API exposes HTTP cookies to service workers and offers an asynchronous alternative to document.cookie. This change is about exposing it to all secure contexts by including allowing local origins (127.0.0.1, localhost address, file://...).

This allows developers to quickly experiment things locally, without the need to set up a HTTPs server.

Blink component

Blink

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This improves alignment with the specification.

Gecko: Positive (https://github.com/WICG/cookie-store/issues/21) They supported restricting to secure context, although the local case was not discussed explicitly.

WebKit: Neutral ( https://lists.webkit.org/pipermail/webkit-dev/2020-August/031365.html ) Cookie Store API not implemented in WebKit, but supportive of the idea in general.

Web developers: Positive ( https://github.com/WICG/cookie-store/issues/21 ) They prefer less restrictions.

Is this feature fully tested by web-platform-tests?

No, see https://github.com/whatwg/html/pull/6587#issuecomment-820585713 for a general problem about testing non-HTTPS secured context. Internal tests will be updated though.

Flag name

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=856362

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5684823895048192

This intent message was generated by Chrome Platform Status.

-- 
Frédéric Wang

[Daniel Bratell]

It seems fine to me to treat local network addresses as more secure, but I wonder a bit about the file:// protocol and cookies. Can locally loaded files have cookies, and if they can, could that be exploited?

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df6dc834-a7e4-1dc1-12ad-82dd8c357fe5%40igalia.com.

[Mike West]

LGTM1.

That said, Daniel's question is a good one. AFAIR, our cookie behavior on `file:` URLs is weird and bad, depending to some extent on the state of command-line flags (`allow-file-access-from-files`, I think?). Shipping this API next to `document.cookie` on file URLs is non-harmful, but I'd like us to make sure that its behavior matches `document.cookie` with regard to capability. Currently, I believe that means we would ignore cookie set operations unless flags are flipped.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3128ac4a-19f0-0826-5b47-86b48f789334%40gmail.com.

[Chris Harrelson]

LGTM2, with the requirement that behavior under file:// urls match behavior for document.cookie (Mike's LGTM1 was contingent on that as well).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dddjrr70PXy6XMDJWFfGK%2BOA9vQEQM8T5ix6f8p0xSCUQ%40mail.gmail.com.

[Alex Russell]

LGTM3 with the same caveats.

[Frédéric Wang]

Hi everybody,

OK I just checked with a simple test (see below). Here is the summary of deleting/setting cookies:

Before my patch:

For file://, "Cannot modify a secure cookie on insecure origin" with cookie store API ; fails without error with document.cookie.
For file:// with --allow-file-access-from-files": Same.
For localhost/127.0.0.1, "Cannot modify a secure cookie on insecure origin" with cookie store API but succeeds with document.cookie.

After my patch:

For file://, "An unknown error occured while writing the cookie." with cookie store API ; fails without error with document.cookie.
For file:// with --allow-file-access-from-files": Same.
For localhost/127.0.0.1: Can modify with both cookie store API and document.cookie.

So it looks we are already having inconsistent result with localhost/127.0.0.0.1 and my patch is only making things better. I'll include document.cookie in my the test for localhost/127.0.0.0.1.

For file://, there is something else preventing the cookies to be modified anyway, but I'll modify my patch to continue to provide the same exception message.

Thanks,

      async function testReadWriteCookies() {
          console.log("*** cookieStore ***")
          try {
              console.log(await cookieStore.get("cookie-name"));
          } catch(e) {
              console.log(e);
          }
          try {
              console.log(await cookieStore.set("cookie-name", "cookie-value"));
          } catch(e) {
              console.log(e);
          }
          try {
              console.log(await cookieStore.get("cookie-name"));
          } catch(e) {
              console.log(e);
          }
          try {
              console.log(await cookieStore.delete("cookie-name"));
          } catch(e) {
              console.log(e);
          }
          try {
              console.log(await cookieStore.get("cookie-name"));
          } catch(e) {
              console.log(e);
          }
          console.log("*** document.cookie ***")
          try {
              document.cookie = "cookiename2=cookievalue";
          } catch(e) {
              console.log(e);
          }
          console.log(`document.cookie: ${document.cookie}`);
          try {
              document.cookie = "cookiename2=cookievalue;expires=Thu, 01 Jan 1970 00:00:01 GMT";
          } catch(e) {
              console.log(e);
          }
          console.log(`document.cookie: ${document.cookie}`);
      }
      testReadWriteCookies();

-- 
Frédéric Wang