Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Mike Taylor]

The good news is sites can continue to use max-age to reset the 
expiration 400 days in the future, every time the user visits (assuming 
that's desired behavior), for example in JS:


document.cookie = `lol=ok; max-age=${60 * 60 * 24 * 400}`;

We'll work with DevRel to make sure this is properly documented so there 
are fewer surprises some ~400 days ahead of this landing.


On 4/13/22 11:58 AM, Daniel Bratell wrote:


LGTM3

I am slightly concerned with cookies used daily unexpectedly 
disappearing every 400 days. If there was a way to refresh them when 
used, maybe that would make this smoother for web developers, but that 
is a followup feature. If the metrics show that it is a common scenario.


/Daniel

On 2022-04-13 15:53, Mike West wrote:

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
 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
 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
 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
 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
 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 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Daniel Bratell]

LGTM3

I am slightly concerned with cookies used daily unexpectedly 
disappearing every 400 days. If there was a way to refresh them when 
used, maybe that would make this smoother for web developers, but that 
is a followup feature. If the metrics show that it is a common scenario.


/Daniel

On 2022-04-13 15:53, Mike West wrote:

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
 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
 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
 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
 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
 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
 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
 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Mike West]

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  
> 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  
>> 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  
>>> 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  
 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  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  
>> 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  
>>> 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  
 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  
> wrote:
>
>> What happens if a newly logged-in site doesn't refresh its 
>> cookies on every visit, the user visits that site 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

On Tue, Apr 12, 2022 at 9:10 PM Ari Chivukula  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  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 
>> 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 
>>> 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  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 
> 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 
>> 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 
>>> 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 
 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 
> 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 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

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  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 
> 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 
>> 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  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 
 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  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 
>> 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 
>>> 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 
 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

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

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  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 
> 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  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 
>>> 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  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 
> 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 
>> 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 
>>> 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 
 wrote:

> Do I understand correctly and the 400 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

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  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  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 
>> 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  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 
 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 
> 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 
>> 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 
>>> 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 
 wrote:

> Contact emails
>
> aric...@chromium.org, miketa...@chromium.org
>
> Specification
>

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

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  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 
> 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  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 
>>> 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 
 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 
> 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 
>> 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 
>>> 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.



 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

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  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  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 
>> 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 
>>> 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 
 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 
> 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 
>> 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
>>> 
>>>
>>>
>>>
>>> Motivation
>>>
>>> The draft of rfc6265bis
>>> 
>>> 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
>>> (3456 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, 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

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  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  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  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 
>>> 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 
 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 
> 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
>> 
>>
>>
>>
>> Motivation
>>
>> The draft of rfc6265bis
>> 
>> 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
>> (3456 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 
>> (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 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

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  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  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 
>> 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 
>>> 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 
 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
> 
>
>
>
> Motivation
>
> The draft of rfc6265bis
> 
> 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
> (3456 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 
> (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
> 
>
> WebKit: Positive
> 
>
> Web developers: None Yet, but attempting to gather some
> 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

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  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  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 
>> 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 
>>> 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
 



 Motivation

 The draft of rfc6265bis
 
 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
 (3456 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 
 (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
 

 WebKit: Positive
 

 Web developers: None Yet, but attempting to gather some
 .

 Debuggability

 Attempts to set cookies with lifetimes past 400 days will be
 highlighted in the Issues tab
 
 .

 Is this feature fully tested by web-platform-tests?

 There’s some
 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

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  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  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 
>> 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
>>> 
>>>
>>>
>>>
>>> Motivation
>>>
>>> The draft of rfc6265bis
>>> 
>>> 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 (3456 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  (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
>>> 
>>>
>>> WebKit: Positive
>>> 
>>>
>>> Web developers: None Yet, but attempting to gather some
>>> .
>>>
>>> Debuggability
>>>
>>> Attempts to set cookies with lifetimes past 400 days will be highlighted in
>>> the Issues tab
>>> 
>>> .
>>>
>>> Is this feature fully tested by web-platform-tests?
>>>
>>> There’s some
>>> ,
>>> but more will be added once testdriver.js supports it
>>> .
>>>
>>> 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 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

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  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  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
>> 
>>
>>
>>
>> Motivation
>>
>> The draft of rfc6265bis
>> 
>> 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 (3456 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  (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
>> 
>>
>> WebKit: Positive
>> 
>>
>> Web developers: None Yet, but attempting to gather some
>> .
>>
>> Debuggability
>>
>> Attempts to set cookies with lifetimes past 400 days will be highlighted in
>> the Issues tab
>> 
>> .
>>
>> Is this feature fully tested by web-platform-tests?
>>
>> There’s some
>> ,
>> but more will be added once testdriver.js supports it
>> .
>>
>> 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
>> 
>> .
>>
>

-- 
You received this message 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

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  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
> 
>
>
>
> Motivation
>
> The draft of rfc6265bis
> 
> 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 (3456 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  (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
> 
>
> WebKit: Positive
> 
>
> Web developers: None Yet, but attempting to gather some
> .
>
> Debuggability
>
> Attempts to set cookies with lifetimes past 400 days will be highlighted in
> the Issues tab
> 
> .
>
> Is this feature fully tested by web-platform-tests?
>
> There’s some
> ,
> but more will be added once testdriver.js supports it
> .
>
> 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
> 
> .
>

-- 
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/CAL5BFfVqmZDH4sk6qu9KU8corhRXbnvqJKOM4DzXEym9Ms_g9g%40mail.gmail.com.

[blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

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




Motivation

The draft of rfc6265bis

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 (3456 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  (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 

WebKit: Positive


Web developers: None Yet, but attempting to gather some
.

Debuggability

Attempts to set cookies with lifetimes past 400 days will be highlighted in
the Issues tab

.

Is this feature fully tested by web-platform-tests?

There’s some
,
but more will be added once testdriver.js supports it
.

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.