According to measurements in Chrome, of all cookies set, about 20% request
an Expires/Max-Age further than 400 days in the future. Of that 20%: half
target 2 years, a quarter target 10 years or more, and the remainder are
spread over the rest of the range.

Keep in mind this is looking at the usage of sites *before* any cap was
imposed. Although the distribution of cookies with expirations more than
400 days in the future will be the same, the amount will be under 20% of
current storage and shrinking as any cookies added or updated will now be
forced to respect the 400 day cap.

The motivation for this change is to require, now that we're about to hit
400 days since the cap was imposed on new/updated cookies, that no special
privileges be extended to cookies that just happened to have been stored
before.

~ Ari Chivukula (Their/There/They're)


On Wed, Aug 2, 2023 at 3:47 PM Alex Russell <slightly...@chromium.org>
wrote:

> Hey Ari,
>
> It isn't clear to me that the change in the RFC is a motivator to make
> this change, or that it reduces potential risk.
>
> There are details here will matter a lot to the risk profile. IIRC, we'll
> be going first with regards to the lifetime of first-party, server-set
> cookies? Do we have an analysis of what fraction of cookies will be
> impacted?
>
> Thanks,
>
> Alex
>
> On Tuesday, August 1, 2023 at 8:59:59 AM UTC-7 Ari Chivukula wrote:
>
>> Contact emails
>>
>> aric...@chromium.org, miketa...@chromium.org, bing...@chromium.org
>>
>> Specification
>>
>>
>> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
>>
>> Summary
>>
>> Since M104 cookies newly created or updated with an expiration date would
>> have that date capped at no more than 400 days in the future. This same
>> limit will now be retroactively applied to cookies already in storage to
>> cap their expiration dates to no more than 400 days after the first time
>> Chrome M118+ starts up and does a one time database migration. The impact
>> of this change will not be felt by users until at least 400 days after M118
>> is released, and then only for existing cookies that have not been updated
>> in that period.
>>
>>
>> Blink component
>>
>> Internals>Network>Cookies
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies>
>>
>>
>> Motivation
>>
>> The draft of rfc6265bis
>> <https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute>
>> now contains an upper limit for Cookie Expires/Max-Age attributes. As
>> written:
>>
>> `The user agent MUST limit the maximum value of the [Max-Age/Expiration]
>> attribute. The limit MUST NOT be greater than 400 days (34560000 seconds)
>> in duration. The RECOMMENDED limit is 400 days in duration, but the user
>> agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that
>> are greater than the limit MUST be reduced to the limit.`
>>
>>
>> This limit should be enforced retroactively to comply with the
>> specification and clear old cookies with high expiration dates out on a
>> reasonable timetable.
>>
>> TAG review
>>
>> Supportive <https://github.com/w3ctag/design-reviews/issues/729> of
>> original change
>>
>> Compatibility
>>
>> In general, websites should never depend on cookies existing for some
>> predictable length of time. The browser can and will evict for any number
>> of reasons.
>>
>>
>> Interoperability
>>
>> Safari is already partially compliant (with an upper age limit of 7 days
>> when cookies are set client side but no limit when set by the server),
>> while Firefox supports cookies with expiration dates millennia in the
>> future.
>>
>> Gecko: Positive
>> <https://github.com/mozilla/standards-positions/issues/592>
>>
>> WebKit: Positive
>> <https://lists.webkit.org/pipermail/webkit-dev/2022-January/032096.html>
>>
>> Web developers: Mostly negative or neutral on expires limits in general
>>
>> Debuggability
>>
>> Existing DevTools affordances for debugging cookie attributes will work
>> as expected here
>>
>> Is this feature fully tested by web-platform-tests?
>>
>> Yes
>> <http://third_party/blink/web_tests/external/wpt/cookie-store/cookieListItem_attributes.https.any.js>
>>
>> Tracking bug
>>
>> https://crbug.com/1181924
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5086241845936128
>>
>>

-- 
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/CAGpy5D%2B_u5LB6wF%3DT9fu%2B2Svciv%2BWVu-oOVN1CWCvVAeHfVvAA%40mail.gmail.com.

Reply via email to