[blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

Contact emails

ari...@chromium.org, mike...@chromium.org

Specification

https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute

Summary

When cookies are set with an explicit Expires/Max-Age attribute the value will now be capped to no more than 400 days in the future. Previously, there was no limit and cookies could expire multiple millennia in the future.

 

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

 

400 days was chosen as a round number close to 13 months in duration. 13 months was chosen to ensure that sites one visits roughly once a year (e.g., picking health insurance benefits) will continue to work.

 

According to measurements in Chrome, of all cookies set, about 20% have 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.

TAG review

Just an FYI (this is a small change that has already landed in the draft spec and has support from other browsers, but we'll send an FYI issue to the TAG).

Compatibility

Existing cookies will not expire sooner, but any attempts to update/re-set them will limit the new expiration date to 400 days at most.

 

Interoperability

Safari is already partially compliant (it an upper age limit of 7 days when cookies are set client side but no limit when set by the server), while Firefox and Chrome both support cookies with expiration dates orders of magnitude longer than a millenia in the future.

Gecko: Positive

WebKit: Positive

Web developers: None Yet, but attempting to gather some.

Debuggability

Attempts to set cookies with lifetimes past 400 days will be highlighted in the Issues tab.

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

There’s some, but more will be added once testdriver.js supports it.

Tracking bug

https://crbug.com/1264458

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4887741241229312

[Yoav Weiss]

Do I understand correctly and the 400 days clock will not be reset when the site is visited, but only when cookies are set?

Does that mean that if existing sites don't try to re-set cookies when ones are set, their users will be logged out after 400 days, even if they visit the site regularly?

--
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/CAGpy5DJdgcDqgJQOq%3DHdvLzMV%2BRupiW7Wqv2swPco%2BQzWtziSQ%40mail.gmail.com.

[Ari Chivukula]

Cookies already in storage will not have this new limit imposed, but any cookies newly set or updated will have it imposed.

If an existing logged-in site isn't visited for 400 days, and it previously allowed > 400 day retention, the user will still be logged in on the 401st day.

If an existing logged-in site newly updates its login cookies and then isn't visited for 400 days, the login cookies will expire after 400 days of inactivity.

Any newly logged-in site will have the 400 day limit imposed.

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

[Yoav Weiss]

What happens if a newly logged-in site doesn't refresh its cookies on every visit, the user visits that site every ~months, and 400 days pass?

In other words, when does the 400 days clock get reset: on visit or on cookie renewal?

[Ari Chivukula]

The actual expiration date written to the cookie store is capped at 400 days for any new/updated cookies.

If a newly logged-in site doesn't refresh its cookies for 400 days after they are set, the cookies expire and the user will be logged out no matter how often the user visits the site.

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

[Yoav Weiss]

Thanks! It seems like we'd need to tell developers then that they need to update their cookies on every site visit. I don't know if this is a big change from what they are already largely doing. Do we have data on that?

[Ari Chivukula]

We don't currently, but we know only 20% of cookies set in chrome are over the limit (and that 20% will continue to work if not updated). We're planning proactive communication about the change once it's approved since there's a 400 day window from the change going in until effects are first felt.

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

[Yoav Weiss]

IIUC from offline conversations, once we start changing the expiration dates of cookies, we won't have a way to avoid enforcing that expiration date 400 days from now. So we probably want to get this right and avoid breakage for sites that don't currently update their cookies every time (as even if they change their behavior ~6 months from now, they'd accumulate 6 months worth of users that visited their site but will have their cookies expired).

Would it make sense to collect data on the cookie update dates (maybe even just data from beta), and only then ship the expiration max-age change?

[Ari Chivukula]

Since we don't currently store the last date a cookie was updated in chrome (just the original creation date) we wouldn't be able to get data on how many cookies would expire due to a lack of timely refreshes by the site (as opposed to a lack of site visits) for up to 400 days. The problem is that sites might be tuned to refresh periodically (instead of on every visit), which means we would have to wait for that unknown periodic refresh for a last update date to even be recorded.

I think we should move forward with this change *and* add metrics so we have an idea (before the 400 day mark) which sites risk expiration and can alert them.

I don't think there's an issue with sites taking 6 months to change refresh behavior as the expires logic only affects sites with less-than-annually active users. That is, affected users would login to use a site post-chrome expires change but pre-site refresh change, and then wait 400 days to try to use the site again for their login to expire.

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

[Ari Chivukula]

Here's a design doc for the additional data to be measured: https://docs.google.com/document/d/1x7_2wVY2gSEfMlvpS4AoQtN5x7fHG_AsQ01V4CkSELI/edit

The target ship date for this thread is now M103, but we're still looking for LGTMs.

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

[Yoav Weiss]

LGTM1 conditional on:

• Landing the metrics in M102 and the feature in M103
  
• Coming back to this thread when the numbers start coming in on the metrics
• Having a flag in place that'd enable us to disable the feature in case the numbers indicate that the loss of cookies due to lack of updates would be very high

[Ari Chivukula]

Deal, but let's call metrics for M103 and the feature in M104.

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

[Yoav Weiss]

On Tue, Apr 12, 2022 at 9:10 PM Ari Chivukula <ari...@chromium.org> wrote:

Deal, but let's call metrics for M103 and the feature in M104.

Sure, I should've said N and N+1 

[Mike West]

LGTM2.

I recognize Yoav's concern, and I think it's reasonable, but I'm less concerned about it than he is. Still, adding the metrics under discussion here is a good step, and if they cause us to reevaluate the impact, we'll have plenty of time to do so.

-mike

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

[Daniel Bratell]

LGTM3

I am slightly concerned with cookies used daily unexpectedly disappearing every 400 days. If there was a way to refresh them when used, maybe that would make this smoother for web developers, but that is a followup feature. If the metrics show that it is a common scenario.

/Daniel

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/f15ced2a-64c2-42bb-9728-3d60747b6172n%40chromium.org.

[Mike Taylor]

The good news is sites can continue to use max-age to reset the expiration 400 days in the future, every time the user visits (assuming that's desired behavior), for example in JS:

document.cookie = `lol=ok; max-age=${60 * 60 * 24 * 400}`;

We'll work with DevRel to make sure this is properly documented so there are fewer surprises some ~400 days ahead of this landing.