LGTM2. I recognize Yoav's concern, and I think it's reasonable, but I'm less concerned about it than he is. Still, adding the metrics under discussion here is a good step, and if they cause us to reevaluate the impact, we'll have plenty of time to do so.
-mike On Wednesday, April 13, 2022 at 10:49:29 AM UTC+2 Yoav Weiss wrote: > On Tue, Apr 12, 2022 at 9:10 PM Ari Chivukula <aric...@chromium.org> > wrote: > >> Deal, but let's call metrics for M103 and the feature in M104. >> > > Sure, I should've said N and N+1 > > >> ~ Ari Chivukula (Their/There/They're) >> >> >> On Mon, Apr 11, 2022 at 8:57 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> LGTM1 conditional on: >>> >>> - Landing the metrics in M102 and the feature in M103 >>> - Coming back to this thread when the numbers start coming in on the >>> metrics >>> - Having a flag in place that'd enable us to disable the feature in >>> case the numbers indicate that the loss of cookies due to lack of >>> updates >>> would be very high >>> >>> >>> On Mon, Apr 11, 2022 at 10:58 PM Ari Chivukula <aric...@chromium.org> >>> wrote: >>> >>>> Here's a design doc for the additional data to be measured: >>>> https://docs.google.com/document/d/1x7_2wVY2gSEfMlvpS4AoQtN5x7fHG_AsQ01V4CkSELI/edit >>>> >>>> The target ship date for this thread is now M103, but we're still >>>> looking for LGTMs. >>>> >>>> ~ Ari Chivukula (Their/There/They're) >>>> >>>> >>>> On Mon, Apr 11, 2022 at 7:46 AM Ari Chivukula <aric...@chromium.org> >>>> wrote: >>>> >>>>> Since we don't currently store the last date a cookie was updated in >>>>> chrome (just the original creation date) we wouldn't be able to get data >>>>> on >>>>> how many cookies would expire due to a lack of timely refreshes by the >>>>> site >>>>> (as opposed to a lack of site visits) for up to 400 days. The problem is >>>>> that sites might be tuned to refresh periodically (instead of on every >>>>> visit), which means we would have to wait for that unknown periodic >>>>> refresh >>>>> for a last update date to even be recorded. >>>>> >>>>> I think we should move forward with this change *and* add metrics so >>>>> we have an idea (before the 400 day mark) which sites risk expiration and >>>>> can alert them. >>>>> >>>>> I don't think there's an issue with sites taking 6 months to change >>>>> refresh behavior as the expires logic only affects sites with >>>>> less-than-annually active users. That is, affected users would login to >>>>> use >>>>> a site post-chrome expires change but pre-site refresh change, and then >>>>> wait 400 days to try to use the site again for their login to expire. >>>>> >>>>> ~ Ari Chivukula (Their/There/They're) >>>>> >>>>> On Mon, Apr 11, 2022, 05:18 Yoav Weiss <yoavwe...@chromium.org> wrote: >>>>> >>>>>> IIUC from offline conversations, once we start changing the >>>>>> expiration dates of cookies, we won't have a way to avoid enforcing that >>>>>> expiration date 400 days from now. So we probably want to get this right >>>>>> and avoid breakage for sites that don't currently update their cookies >>>>>> every time (as even if they change their behavior ~6 months from now, >>>>>> they'd accumulate 6 months worth of users that visited their site but >>>>>> will >>>>>> have their cookies expired). >>>>>> >>>>>> Would it make sense to collect data on the cookie update dates (maybe >>>>>> even just data from beta), and only then ship the expiration max-age >>>>>> change? >>>>>> >>>>>> >>>>>> On Mon, Apr 11, 2022 at 11:51 AM Ari Chivukula <aric...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> We don't currently, but we know only 20% of cookies set in chrome >>>>>>> are over the limit (and that 20% will continue to work if not updated). >>>>>>> We're planning proactive communication about the change once it's >>>>>>> approved >>>>>>> since there's a 400 day window from the change going in until effects >>>>>>> are >>>>>>> first felt. >>>>>>> >>>>>>> ~ Ari Chivukula (Their/There/They're) >>>>>>> >>>>>>> On Mon, Apr 11, 2022, 02:03 Yoav Weiss <yoavwe...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks! It seems like we'd need to tell developers then that they >>>>>>>> need to update their cookies on every site visit. I don't know if this >>>>>>>> is a >>>>>>>> big change from what they are already largely doing. Do we have data >>>>>>>> on >>>>>>>> that? >>>>>>>> >>>>>>>> On Fri, Apr 8, 2022 at 7:26 PM Ari Chivukula <aric...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The actual expiration date written to the cookie store is capped >>>>>>>>> at 400 days for any new/updated cookies. >>>>>>>>> >>>>>>>>> If a newly logged-in site doesn't refresh its cookies for 400 days >>>>>>>>> after they are set, the cookies expire and the user will be logged >>>>>>>>> out no >>>>>>>>> matter how often the user visits the site. >>>>>>>>> >>>>>>>>> ~ Ari Chivukula (Their/There/They're) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Apr 8, 2022 at 8:57 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> What happens if a newly logged-in site doesn't refresh its >>>>>>>>>> cookies on every visit, the user visits that site every ~months, and >>>>>>>>>> 400 >>>>>>>>>> days pass? >>>>>>>>>> In other words, when does the 400 days clock get reset: on visit >>>>>>>>>> or on cookie renewal? >>>>>>>>>> >>>>>>>>>> On Fri, Apr 8, 2022 at 4:59 PM Ari Chivukula < >>>>>>>>>> aric...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Cookies already in storage will not have this new limit imposed, >>>>>>>>>>> but any cookies newly set or updated will have it imposed. >>>>>>>>>>> >>>>>>>>>>> If an existing logged-in site isn't visited for 400 days, and it >>>>>>>>>>> previously allowed > 400 day retention, the user will still be >>>>>>>>>>> logged in on >>>>>>>>>>> the 401st day. >>>>>>>>>>> >>>>>>>>>>> If an existing logged-in site newly updates its login cookies >>>>>>>>>>> and then isn't visited for 400 days, the login cookies will expire >>>>>>>>>>> after >>>>>>>>>>> 400 days of inactivity. >>>>>>>>>>> >>>>>>>>>>> Any newly logged-in site will have the 400 day limit imposed. >>>>>>>>>>> >>>>>>>>>>> ~ Ari Chivukula (Their/There/They're) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 8, 2022 at 12:14 AM Yoav Weiss < >>>>>>>>>>> yoavwe...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Do I understand correctly and the 400 days clock will not be >>>>>>>>>>>> reset when the site is visited, but only when cookies are set? >>>>>>>>>>>> Does that mean that if existing sites don't try to re-set >>>>>>>>>>>> cookies when ones are set, their users will be logged out after >>>>>>>>>>>> 400 days, >>>>>>>>>>>> even if they visit the site regularly? >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Apr 6, 2022 at 4:57 PM Ari Chivukula < >>>>>>>>>>>> aric...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Contact emails >>>>>>>>>>>>> >>>>>>>>>>>>> aric...@chromium.org, miketa...@chromium.org >>>>>>>>>>>>> >>>>>>>>>>>>> Specification >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute >>>>>>>>>>>>> >>>>>>>>>>>>> Summary >>>>>>>>>>>>> >>>>>>>>>>>>> When cookies are set with an explicit Expires/Max-Age >>>>>>>>>>>>> attribute the value will now be capped to no more than 400 days >>>>>>>>>>>>> in the >>>>>>>>>>>>> future. Previously, there was no limit and cookies could expire >>>>>>>>>>>>> multiple >>>>>>>>>>>>> millennia in the future. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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.` >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 400 days was chosen as a round number close to 13 months in >>>>>>>>>>>>> duration. 13 months was chosen to ensure that sites one visits >>>>>>>>>>>>> roughly once >>>>>>>>>>>>> a year (e.g., picking health insurance benefits) will continue to >>>>>>>>>>>>> work. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> According to measurements in Chrome, of all cookies set, about >>>>>>>>>>>>> 20% have 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. >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review >>>>>>>>>>>>> >>>>>>>>>>>>> Just an FYI >>>>>>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/729> (this >>>>>>>>>>>>> is a small change that has already landed in the draft spec and >>>>>>>>>>>>> has support >>>>>>>>>>>>> from other browsers, but we'll send an FYI issue to the TAG). >>>>>>>>>>>>> >>>>>>>>>>>>> Compatibility >>>>>>>>>>>>> >>>>>>>>>>>>> Existing cookies will not expire sooner, but any attempts to >>>>>>>>>>>>> update/re-set them will limit the new expiration date to 400 days >>>>>>>>>>>>> at most. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Interoperability >>>>>>>>>>>>> >>>>>>>>>>>>> Safari is already partially compliant (it an upper age limit >>>>>>>>>>>>> of 7 days when cookies are set client side but no limit when set >>>>>>>>>>>>> by the >>>>>>>>>>>>> server), while Firefox and Chrome both support cookies with >>>>>>>>>>>>> expiration >>>>>>>>>>>>> dates orders of magnitude longer than a millenia 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: None Yet, but attempting to gather some >>>>>>>>>>>>> <https://twitter.com/miketaylr/status/1509228889058463749>. >>>>>>>>>>>>> >>>>>>>>>>>>> Debuggability >>>>>>>>>>>>> >>>>>>>>>>>>> Attempts to set cookies with lifetimes past 400 days will be >>>>>>>>>>>>> highlighted in the Issues tab >>>>>>>>>>>>> <https://docs.google.com/document/d/1lDEvj8tMeuvUs1HTTqL-44YiI-7ljeQkusM_WhUfIeE/edit> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> Is this feature fully tested by web-platform-tests? >>>>>>>>>>>>> >>>>>>>>>>>>> There’s some >>>>>>>>>>>>> <http://third_party/blink/web_tests/external/wpt/cookie-store/cookieListItem_attributes.https.any.js>, >>>>>>>>>>>>> >>>>>>>>>>>>> but more will be added once testdriver.js supports it >>>>>>>>>>>>> <https://github.com/web-platform-tests/rfcs/pull/108>. >>>>>>>>>>>>> >>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>> >>>>>>>>>>>>> https://crbug.com/1264458 >>>>>>>>>>>>> >>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>> >>>>>>>>>>>>> https://chromestatus.com/feature/4887741241229312 >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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/CAGpy5DJdgcDqgJQOq%3DHdvLzMV%2BRupiW7Wqv2swPco%2BQzWtziSQ%40mail.gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJdgcDqgJQOq%3DHdvLzMV%2BRupiW7Wqv2swPco%2BQzWtziSQ%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/f15ced2a-64c2-42bb-9728-3d60747b6172n%40chromium.org.
