Intent to Prototype & Ship: Cookie Expires/Max-Age attribute upper limit for prior storage

[Ari Chivukula]

Contact emails

ari...@chromium.org, mike...@chromium.org, bin...@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

Motivation

The draft of rfc6265bis 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 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

WebKit: Positive

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

Tracking bug

https://crbug.com/1181924

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5086241845936128

[Alex Russell]

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

[Ari Chivukula]

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)

[Daniel Bratell]

I like the idea of automatically clearing out unused cookies, but I am unclear if that is what happens here.

In an hypothetical scenario, a user of website awesomeapp.tv will make some customization the first time they are there, and the site will store that customization in a cookie with an expire date far, far into the future. If this hypothetical user keeps using awesomeapp.tv without changing any settings, and with no cookie updates, will they still lose their customization after 400 days?

If the hypothetical scenario could play out, do we have any idea how common it would be?

To create some context, we have an informal "this breakage is acceptable if needed to move the web forward of" limit of 0.003% of page loads. The numbers you list set an upper limit on the amount of problems and the real number of possibly problematic page loads or affected sites will be much lower, but how low?

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

[Ari Chivukula]

I guess I'm a little confused on the direction of the conversation. If a user starts using chrome today no cookie can set an expiration date more than 400 days in the future, so all sites must already adapt to that present reality.

Some users with cookies stored before this limit was imposed around a year ago have cookies that expire years in the future. After this change via a DB migration, those cookies would be capped to 400 days after the DB migration was run. No user will lose cookies in the DB migration itself.

I don't think we know how many sites depend on cookies that are set once and never again, but given cookie retention timelines are not guaranteed sites should not do this. The actual expiration time of the cookie isn't returned in the cookie header or document.cookie, so sites should already be refreshing cookies (by setting them again) on occasion.

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

[Daniel Bratell]

So my assumption is the pessimistic one that most sites won't notice this policy change even if we publish posts about it. And even if users and sites can survive lost cookies, it might still be a disruption that was unexpected and unwanted. But I don't have any good idea of how disruptive and how common it will be. It might not be a real problem at all, but I am missing the knowledge and data to understand what the size of the risk is.

My hope was that you would have some information or data that would show to me that there is nothing to be concerned about. I don't think I'm there yet, but if cookies are already limited to 400 days, that is a good indication it can't be too much of a problem.

/Daniel

[Ari Chivukula]

It's true we don't have a lot of data on the impact of this specifically, but part of that is due to 400 day lag between enforcement and anyone in prod feeling the effects. We could try to produce data on the amount of cookies already in the store that would be newly capped, but that won't really tell us what will happen if they expire a year from now.

Some sites may have to adapt their preferences to be re-written to the cookie store if they haven't already, but this change is starting another 400 day counter for sites to adapt the same way was done a year ago.

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

[Mike Taylor]

Perhaps we could delay this change until M119 as I understand that the first cookies that were set more than 400 days ago are due to expire in the M118 window. That should give us some time to understand the impact in more concrete terms and mitigate some of the impact, were it to turn out to that 400 days is not the right balance between utility and protecting users.

(I should note that I'm supportive of this change as proposed as a net positive for security, but am recused from voting on it.)

[Ari Chivukula]

I have no objections to delaying until M119. I'll check back in a week or two after the September 6 cliff when cookies in stable that were limited to 400 days as of M104 start expiring. It's important to note we will only be able to discuss the presence of lack of bug reports from sites and users (there won't be other additional data available).

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

[Ari Chivukula]

Re-opening this since it's been a month and we're a week after the September 6th cliff where cookies in stable that were limited to 400 days as of M104 start expiring (if they were not subsequently renewed).

I haven't seen any negative feedback or questions around unexpected cookie expirations in the past week and the latest metrics show < .035% of page loads (and falling) sending cookies that had not been renewed in the last 350-400 days.

I think it's reasonable to impose the same limit on cookies that happened to be stored before M104 as the limit imposed on those after (the 400 day expiration cap) and we should do so in M119.

It's important to note this cap will *not* simply retroactively expire all older cookies but instead cap any cookies with expirations more than 400 days after M119+ is first launched by a user to expire no more than 400 days after that time. For example:

Site X stored Cookie Y pre-M104 expires January 1, 9999.

M119 first launched by user January 1, 2024.

Cookie Y now expires February 4, 2025.

Site X renews Cookie Y by storing it again January 1, 2025.

Cookie Y now expires February 5, 2026.

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

[Daniel Bratell]

LGTM1

There will be some day late in 2024, early in 2025 that will be the death of many cookies. I now believe the risk of that being a problem is low enough.

/Daniel

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2ad99d54-4409-279e-2818-582158c06000%40gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXp6W%3DzCAt2Fb-EbA2RBq7cQ%3DhrPpKWH1XU3QUSBQGhow%40mail.gmail.com.