Deal, but let's call metrics for M103 and the feature in M104. ~ 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/CAGpy5DJZO1MxdGYqLGmGT36eoqb3fZqa0%3DD2%3DBgt0fn8FZ5RHw%40mail.gmail.com.
