LGTM2 On Wed, Sep 13, 2023 at 5:44 PM Daniel Bratell <bratel...@gmail.com> wrote:
> 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 > On 2023-09-13 13:12, Ari Chivukula wrote: > > 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) > > > On Fri, Aug 11, 2023 at 6:23 PM Ari Chivukula <aric...@chromium.org> > wrote: > >> 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) >> >> On Fri, Aug 11, 2023, 07:14 Mike Taylor <miketa...@chromium.org> wrote: >> >>> 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.) >>> On 8/10/23 9:52 AM, Ari Chivukula wrote: >>> >>> 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) >>> >>> On Thu, Aug 3, 2023, 05:45 Daniel Bratell <bratel...@gmail.com> wrote: >>> >>>> 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 >>>> On 2023-08-03 14:03, Ari Chivukula wrote: >>>> >>>> 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) >>>> >>>> On Thu, Aug 3, 2023, 07:44 Daniel Bratell <bratel...@gmail.com> wrote: >>>> >>>>> 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, 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/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/2ad99d54-4409-279e-2818-582158c06000%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2ad99d54-4409-279e-2818-582158c06000%40gmail.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/CAL5BFfXp6W%3DzCAt2Fb-EbA2RBq7cQ%3DhrPpKWH1XU3QUSBQGhow%40mail.gmail.com.
