LGTM3 On Fri, Sep 15, 2023 at 11:43 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXp6W%3DzCAt2Fb-EbA2RBq7cQ%3DhrPpKWH1XU3QUSBQGhow%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/CAOMQ%2Bw8jsShft81A%2Bs%3DBd-yQTvvnzW2eTq6mfkQfEc-xb5Agbw%40mail.gmail.com.
