Hey, So for Mike's feedback:
> I don't see any mention of the concept of "cookie-age-limit" (400 days) > that 6265bis defines - how does that work for CookieStore? > https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.5 The Cookie Store API sends the maxAge value to 6265bis to be stored in https://cookiestore.spec.whatwg.org/#set-cookie-algorithm, the 400 day limit is enforced at that level instead of in this specification. The cookie would be set with a max age of 400 days if the value exceeds that amount. Step 13.1 of https://cookiestore.spec.whatwg.org/#set-cookie-algorithm > <https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.5> > returns > failure when a cookie has both expires and max-age, but > https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.7 > requires > that max-age wins. Is there any reason for the difference for Cookie Store? The logic was suggested by Anne here <https://github.com/whatwg/cookiestore/pull/292#pullrequestreview-3479097170>. The expectation is that this behavior will soon be enforced in 6265bis, but since this is a new API we would prefer to start throwing errors now, instead of having to specify this behavior later and break callers? Lmk if that is unreasonable. Can we add a test for max-age=0 value? This has been recently allowed > explicitly in the grammar defined in 6265bis (and is supported by all > browsers): Sounds good, https://github.com/web-platform-tests/wpt/pull/57119 And Jeffrey's: > Have you considered Temporal integration, since Temporal is shipping in > M144? I suspect the right behavior is to overload between a `number` and a > `Temporal.Duration`. I am not sure how needed that is for developers, it seems pretty simple to set maxAge to be Temporal.Duration.seconds <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/Duration/seconds> for that case. Welcome to hear other opinions though, and there is an ongoing discussion you might be referencing about temporal timestamps generally that might need IDL-side changes and seems out of scope of this feature on https://github.com/whatwg/cookiestore/issues/243? On Thu, Jan 8, 2026 at 2:30 PM Jeffrey Yasskin <[email protected]> wrote: > Have you considered Temporal integration, since Temporal is shipping in > M144? I suspect the right behavior is to overload between a `number` and a > `Temporal.Duration`. > > On Thu, Jan 8, 2026 at 8:47 AM 'Anusha Muley' via blink-dev < > [email protected]> wrote: > >> >> Contact emails >> >> [email protected] >> >> Explainer >> >> No information provided >> >> Specification >> >> https://github.com/whatwg/cookiestore/pull/292 >> >> Summary >> >> Allows callers to specify a `maxAge` when setting a cookie with the >> Cookie Store API. Cookie expiry time is already configurable using the >> `expires` attribute, but `maxAge` provides a more idiomatic option and >> aligns the Cookie Store API with the options provided by `document.cookie` >> and the `Set-Cookie` HTTP Header. >> >> Blink component >> >> Blink>Storage>CookiesAPI >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorage%3ECookiesAPI%22> >> >> Web Feature ID >> >> cookie-store <https://webstatus.dev/features/cookie-store> >> >> Motivation >> >> Currently, developers can use the `expires` attribute when setting a >> cookie with the Cookie Store API to set an absolute timestamp for expiry. >> This can be unintuitive and is impacted by client-side clock skew. >> RFC6265bis >> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/> and >> the document.cookie API provide a `Max-Age` attribute, which allows for >> relative cookie lifetimes and ergonomic deletion. We should provide a >> `maxAge` option in the Cookie Store API to support relative expiry and >> align with these APIs. >> >> Initial public proposal >> >> https://github.com/whatwg/cookiestore/issues/57 >> >> TAG review >> >> Not requested, this is a relatively small feature that has no impact on >> behavior or new information exposed through the API. >> >> TAG review status >> >> Not applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> Additive feature with no impact to existing cookies/behavior. Does not >> expose additional information or functionality-- setting a cookie's >> absolute expiry with the `expires` value is already supported in the API. >> >> Gecko: Positive ( >> https://github.com/mozilla/standards-positions/issues/1334) >> >> WebKit: No Signal ( >> https://github.com/WebKit/standards-positions/issues/597) >> >> We are actively developing this feature in collaboration with WebKit >> https://github.com/whatwg/cookiestore/pull/292#pullrequestreview-3538599229 >> >> Web developers: Positive (https://github.com/whatwg/cookiestore/issues/57) >> Could be easier for developers to work with now-relative values, aligns the >> Cookie Store API with the features provided by document.cookie and >> RFC6265bis >> >> Other signals: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> No >> >> >> Debuggability >> >> Cookies (and their properties such as expiry time) are debuggable through >> the Application > Cookies tab on DevTools >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? >> >> Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> >> >> https://wpt.fyi/results/cookiestore/cookieStore_set_maxAge.https.any.html?label=master&label=experimental&aligned >> >> >> https://wpt.fyi/results/cookiestore/cookieStore_set_maxAge.https.any.serviceworker.html?label=master&label=experimental&aligned >> >> >> Flag name on about://flags >> >> No information provided >> >> Finch feature name >> >> CookieStoreAPIMaxAge >> >> Rollout plan >> >> Will ship enabled for all users >> >> Requires code in //chrome? >> >> False >> >> Tracking bug >> >> https://issues.chromium.org/430926231 >> >> Estimated milestones >> >> Shipping on desktop >> >> 145 >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> >> None >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5190778418757632 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68847eee-f32e-4ef8-85f1-1413a18a2bcen%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68847eee-f32e-4ef8-85f1-1413a18a2bcen%40chromium.org?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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOJwDD54Swah7GeuvZ5R01JfphQ9E4WVemXZW9y8QvDwf%3D_tyQ%40mail.gmail.com.
