Just a quick update - these changes have landed and should be enabled in
M95.
-Andrew
On Thu, Aug 12, 2021 at 3:45 PM Alex Russell <slightly...@chromium.org>
wrote:
> LGTM3. Apologies for the delay.
>
> On Thursday, July 29, 2021 at 2:24:19 PM UTC-7 Yoav Weiss wrote:
>
>> LGTM2
>>
>> On Thu, Jul 29, 2021 at 11:14 PM Daniel Bratell <bratel...@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).
>>
>>>
>>> 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
>>>
>>> On Thu, Jul 29, 2021 at 12:43 AM Yoav Weiss <yoavwe...@chromium.org>
>>> wrote:
>>>
>>>> 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
>>>> ?
>>>>
>>>> On Thu, Jul 29, 2021 at 12:55 AM Andrew Williams <awil...@chromium.org>
>>>> wrote:
>>>>
>>>>> Contact Emails:
>>>>>
>>>>> awil...@chromium.org, miketa...@chromium.org
>>>>>
>>>>> Explainer:
>>>>>
>>>>> https://github.com/httpwg/http-extensions/issues/1340
>>>>>
>>>>> Spec:
>>>>>
>>>>> https://github.com/httpwg/http-extensions/pull/1563
>>>>>
>>>>> TAG review N/A
>>>>> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/uBxq9uCpKx0/m/A5LI0NbyAAAJ>:
>>>>> 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
>>>>> <https://github.com/httpwg/http-extensions/issues/1340>, creating
>>>>> interoperability issues and providing a browser fingerprinting mechanism.
>>>>>
>>>>> After the spec change
>>>>> <https://github.com/httpwg/http-extensions/pull/1563> 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
>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:tools/metrics/histograms/histograms_xml/cookie/histograms.xml;l=267;drc=3baa80ce3b3c886aae3d6eb1a1b890372e84a766>
>>>>> 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 <https://crbug.com/1223516>.
>>>>>
>>>>> 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!
>>>>> --
>>>>> 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+unsubscr...@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
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkXAECTLD0hn4L3aUFYA3MnRDJ9BZn8JcZNQgeoDLnm_qg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>> 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+unsubscr...@chromium.org.
>>> 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
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkUQawArW%3DhN22YuvMxksMFDo9KY-AoeBw8LNuzAve%3DN0A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkWdsQVae-Am7GJvHQcUm8MOjVRd%2BqNHu4hnwAzMKAPNnQ%40mail.gmail.com.
