Intent to Prototype and Ship: Cookie size limits

[Andrew Williams]

Contact Emails:

awi...@chromium.org, mike...@chromium.org

Explainer:

https://github.com/httpwg/http-extensions/issues/1340

Spec:

https://github.com/httpwg/http-extensions/pull/1563

TAG review N/A: this change is already specified in RFC 6265bis, is (mostly) implemented in at least one browser, and is already partially implemented in Chrome (this improves spec compliance).

Summary:

Enforce limits on the size (in bytes) of cookies set by HTTP responses (Set-Cookie header) and via JS APIs (document.cookie and CookieStore).

Motivation:

RFC 6265bis has long suggested a limit on cookie sizes, but different user agents have implemented limits in subtly different ways, creating interoperability issues and providing a browser fingerprinting mechanism.

After the spec change corresponding to this Intent, user agents are now required to limit the sum of the lengths of the cookie's name and value to 4096 bytes, and limit the length of each cookie attribute value to 1024 bytes. Any attempt to set a cookie exceeding the name+value limit is rejected, and any cookie attribute exceeding the attribute length limit is ignored.

Risks:

Interoperability and Compatibility

Implementing this change in Chrome would improve interoperability. The new limits are very similar to what Firefox enforces (4096 bytes limit on name+value, and 1024 byte limit on the Path attribute, but no analogous limit on the Domain attribute).

Metrics in Chrome indicate that this change is web compatible:

1) Chrome currently enforces stricter limits on the entire Set-Cookie line (including the name, '=', value, and any attributes) to 4096 bytes, so the standardized 4096 byte limit on name+value only means any cookies that are currently accepted will not exceed the proposed 4096 byte name+value limit.

2) The overwhelming majority of cookies either have no Path attribute, or have a Path attribute of '/'. The mean Path attribute length was 1.15 bytes. There were exceedingly few cookies in the sampled data with a Path attribute of over 1024 bytes, only 0.0000003% of currently accepted cookies (and such cookies already do not work in Firefox), which would be rejected after the proposed change.

3) There were almost no cookies in the sampled data with a Domain attribute of more than 1024 bytes. The mean Domain attribute length was 9.58 bytes. Only 0.000000002% of currently accepted cookies would exceed the 1024 byte Domain attribute limit and be rejected after the proposed change.

4) Lengths of other cookie attributes are not relevant, as they take either enum or boolean values.

Any existing cookies on disk that violate these size limits will remain in the cookie store. This is due to implementation considerations: cookies are stored in parsed form rather than as raw Set-Cookie lines, and once a cookie has been parsed, it can be impossible to tell whether its original Set-Cookie line exceeded the limits. The number of cookies to which this applies is expected to be insignificant.

Ergonomics

No performance impacts.

Activation

None required.

Debuggability:

DevTools debugging support will be implemented along with this change. Rejected response cookies are already shown in DevTools in the Network panel, with a status explaining why they were rejected. Another status will be added to annotate cookies rejected due to size limits.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

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

Yes. WPT coverage has been added.

Link to entry on the feature dashboard

https://chromestatus.com/feature/4946713618939904 

Requesting approval to ship?

Yes

Note: This proposal, the associated standards work, and the collection/analysis of the related metrics are all thanks to the hard work of Lily Chen (chlily) and Mike Taylor (miketaylr). Thank you both!

[Yoav Weiss]

Do I understand correctly that this limit is applied on cookies set, but not on cookies sent?

That is, if I have {a,b,c}.example.com each setting a 4096 byte cookie on the domain, would we end up sending ~12K of cookies to d.example.com?

--
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/CAEa0%2BkXAECTLD0hn4L3aUFYA3MnRDJ9BZn8JcZNQgeoDLnm_qg%40mail.gmail.com.

[Andrew Williams]

Hi Yoav,

You are correct - these size limits apply only when each individual cookie is parsed or set (for example, when parsing each Set-Cookie header in an HTTP request).  This proposal aims to replace Chrome’s existing limit on the size of cookies it sets with a similar one that's more in line with what other browsers enforce, and that complies with the latest version of RFC 6265bis.

To illustrate this using your example, the following cookies could be set today (each cookie string is <= 4096 characters) and would be sent in a request:

cookieA=loooo<4058 more characters>ooong; domain=example.com
cookieB=loooo<4058 more characters>ooong; domain=example.com
cookieC=loooo<4058 more characters>ooong; domain=example.com

After the change, the following would be allowed as well (the combined string length of the cookie name and cookie value for each is <= 4096, and the string length of each attribute value is <= 1024) :

cookieA=loooo<4079 more characters>ooong; domain=example.com
cookieB=loooo<4079 more characters>ooong; domain=example.com
cookieC=loooo<4079 more characters>ooong; domain=example.com

-Andrew

[Daniel Bratell]

LGTM1 - seems unlikely to cause serious breakages since it will typically be more accepting than before, and it being the same as at least one other browser engine.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkUQawArW%3DhN22YuvMxksMFDo9KY-AoeBw8LNuzAve%3DN0A%40mail.gmail.com.

[Yoav Weiss]

LGTM2

On Thu, Jul 29, 2021 at 11:14 PM Daniel Bratell <brat...@gmail.com> wrote:

LGTM1 - seems unlikely to cause serious breakages since it will typically be more accepting than before, and it being the same as at least one other browser engine.

/Daniel

On 2021-07-29 22:58, Andrew Williams wrote:

Hi Yoav,

You are correct - these size limits apply only when each individual cookie is parsed or set (for example, when parsing each Set-Cookie header in an HTTP request).  This proposal aims to replace Chrome’s existing limit on the size of cookies it sets with a similar one that's more in line with what other browsers enforce, and that complies with the latest version of RFC 6265bis.

Thanks for confirming. I just wanted to verify we're not limiting the cookies sent (as that would impose a much larger risk IMO).

[Alex Russell]

LGTM3. Apologies for the delay.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

--
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+unsubscribe@chromium.org.

[Andrew Williams]

Just a quick update - these changes have landed and should be enabled in M95.

-Andrew

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/CAEa0%2BkXAECTLD0hn4L3aUFYA3MnRDJ9BZn8JcZNQgeoDLnm_qg%40mail.gmail.com.

--
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.