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

On 2023-08-02 21:57, Ari Chivukula wrote:
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 <mailto:aric...@chromium.org>,
        miketa...@chromium.org <mailto:miketa...@chromium.org>,
        bing...@chromium.org <mailto:bing...@chromium.org>


        Specification

        
https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
        
<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 <https://crbug.com/1181924>


        Link to entry on the Chrome Platform Status

        https://chromestatus.com/feature/5086241845936128
        <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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B_u5LB6wF%3DT9fu%2B2Svciv%2BWVu-oOVN1CWCvVAeHfVvAA%40mail.gmail.com?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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f8ddecba-5216-969a-cb99-6ec7985a5edc%40gmail.com.

Reply via email to