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/7ba41655-f176-4227-b680-ae37446328f1n%40chromium.org.
