Intent to Ship: Allow cookie domain attributes to be the empty string

[Kyra Seevers]

Contact emails

kyras...@chromium.org, mike...@chromium.org, jadek...@chromium.org

Explainer

https://github.com/httpwg/http-extensions/issues/1332
https://github.com/httpwg/http-extensions/pull/1709

Specification

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#section-5.4.3

Design docs

https://docs.google.com/document/d/1oyG_OF9YrMR1icbvh9rAT6dFcb7qiKOf2wCngKIWNto/edit?usp=sharing

Summary

Updates the parsing of cookie strings to allow a cookie's domain attribute to be set to the empty string. This change will also correct the failing web-platform tests related to an empty string domain. Previously, in Chrome's ParsedCookie class and related unit and web-platform tests, a cookie string with an empty string domain would not set the domain attribute. Functionally, this caused a cookie’s domain value to equal the previously specified domain for this cookie (if present). However, this behavior conflicts with the draft RFC6265bis, as the resulting cookie in this situation should simply be bound to its request url’s host, termed a “host cookie.” Shipping this feature will align Chrome’s behavior with the domain attribute handling described in the draft RFC6265bis, and will improve interoperability with Safari and Firefox by matching their treatment of an empty cookie domain attribute.

Blink component

Internals>Network>Cookies

TAG review

This is a small bug-fix and does not require a TAG review.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This feature is relatively small so we do not expect many risks. To verify this, we landed a UMA metric to measure when a ParsedCookie is set up with more than one domain attribute and one of those domain values is the empty string. Results from stable show that only 0.00005% of cookies currently exhibit this behavior. Additionally, when considering only cookies from unique hosts, the results suggest only 0.00001% of cookies have a host requesting this behavior.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive (https://github.com/httpwg/http-extensions/issues/1332#issuecomment-939039730)

Other signals: None

Debuggability

This change will not require debugging support outside of the existing DevTools support for cookies.

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

Yes

Flag name

CookieDomainAttributeEmptyString

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5674723800252416

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/kcvn81WtlvM/m/i37EZjnMBwAJ

This intent message was generated by Chrome Platform Status.

[Kyra Seevers]

[Yoav Weiss]

LGTM1

Usage seems tiny and other browsers are already shipping this. Aligning makes sense!

On Friday, January 21, 2022 at 10:49:45 PM UTC+1 Kyra Seevers wrote:

Contact emails

kyras...@chromium.org, miketa...@chromium.org, jadekessler...@chromium.org

[mkwst via Chromestatus]

LGTM2.

[chrishtr via Chromestatus]

LGTM3