LGTM1
There will be some day late in 2024, early in 2025 that will be the
death of many cookies. I now believe the risk of that being a problem is
low enough.
/Daniel
On 2023-09-13 13:12, Ari Chivukula wrote:
Re-opening this since it's been a month and we're a week after the
September 6th cliff where cookies in stable that were limited to 400
days as of M104 start expiring (if they were not subsequently renewed).
I haven't seen any negative feedback or questions around unexpected
cookie expirations in the past week and the latest metrics show <
.035% of page loads (and falling) sending cookies that had not been
renewed in the last 350-400 days.
I think it's reasonable to impose the same limit on cookies that
happened to be stored before M104 as the limit imposed on those after
(the 400 day expiration cap) and we should do so in M119.
It's important to note this cap will *not* simply retroactively expire
all older cookies but instead cap any cookies with expirations more
than 400 days after M119+ is first launched by a user to expire no
more than 400 days after that time. For example:
Site X stored Cookie Y pre-M104 expires January 1, 9999.
M119 first launched by user January 1, 2024.
Cookie Y now expires February 4, 2025.
Site X renews Cookie Y by storing it again January 1, 2025.
Cookie Y now expires February 5, 2026.
~ Ari Chivukula (Their/There/They're)
On Fri, Aug 11, 2023 at 6:23 PM Ari Chivukula <aric...@chromium.org>
wrote:
I have no objections to delaying until M119. I'll check back in a
week or two after the September 6 cliff when cookies in stable
that were limited to 400 days as of M104 start expiring. It's
important to note we will only be able to discuss the presence of
lack of bug reports from sites and users (there won't be other
additional data available).
~ Ari Chivukula (Their/There/They're)
On Fri, Aug 11, 2023, 07:14 Mike Taylor <miketa...@chromium.org>
wrote:
Perhaps we could delay this change until M119 as I understand
that the first cookies that were set more than 400 days ago
are due to expire in the M118 window. That should give us some
time to understand the impact in more concrete terms and
mitigate some of the impact, were it to turn out to that 400
days is not the right balance between utility and protecting
users.
(I should note that I'm supportive of this change as proposed
as a net positive for security, but am recused from voting on it.)
On 8/10/23 9:52 AM, Ari Chivukula wrote:
It's true we don't have a lot of data on the impact of this
specifically, but part of that is due to 400 day lag between
enforcement and anyone in prod feeling the effects. We could
try to produce data on the amount of cookies already in the
store that would be newly capped, but that won't really tell
us what will happen if they expire a year from now.
Some sites may have to adapt their preferences to be
re-written to the cookie store if they haven't already, but
this change is starting another 400 day counter for sites to
adapt the same way was done a year ago.
~ Ari Chivukula (Their/There/They're)
On Thu, Aug 3, 2023, 05:45 Daniel Bratell
<bratel...@gmail.com> wrote:
So my assumption is the pessimistic one that most sites
won't notice this policy change even if we publish posts
about it. And even if users and sites can survive lost
cookies, it might still be a disruption that was
unexpected and unwanted. But I don't have any good idea
of how disruptive and how common it will be. It might not
be a real problem at all, but I am missing the knowledge
and data to understand what the size of the risk is.
My hope was that you would have some information or data
that would show to me that there is nothing to be
concerned about. I don't think I'm there yet, but if
cookies are already limited to 400 days, that is a good
indication it can't be too much of a problem.
/Daniel
On 2023-08-03 14:03, Ari Chivukula wrote:
I guess I'm a little confused on the direction of the
conversation. If a user starts using chrome today no
cookie can set an expiration date more than 400 days in
the future, so all sites must already adapt to that
present reality.
Some users with cookies stored before this limit was
imposed around a year ago have cookies that expire years
in the future. After this change via a DB migration,
those cookies would be capped to 400 days after the DB
migration was run. No user will lose cookies in the DB
migration itself.
I don't think we know how many sites depend on cookies
that are set once and never again, but given cookie
retention timelines are not guaranteed sites should not
do this. The actual expiration time of the cookie isn't
returned in the cookie header or document.cookie, so
sites should already be refreshing cookies (by setting
them again) on occasion.
~ Ari Chivukula (Their/There/They're)
On Thu, Aug 3, 2023, 07:44 Daniel Bratell
<bratel...@gmail.com> wrote:
I like the idea of automatically clearing out unused
cookies, but I am unclear if that is what happens here.
In an hypothetical scenario, a user of website
awesomeapp.tv <http://awesomeapp.tv> will make some
customization the first time they are there, and the
site will store that customization in a cookie with
an expire date far, far into the future. If this
hypothetical user keeps using awesomeapp.tv
<http://awesomeapp.tv> without changing any
settings, and with no cookie updates, will they
still lose their customization after 400 days?
If the hypothetical scenario could play out, do we
have any idea how common it would be?
To create some context, we have an informal "this
breakage is acceptable if needed to move the web
forward of" limit of 0.003% of page loads. The
numbers you list set an upper limit on the amount of
problems and the real number of possibly problematic
page loads or affected sites will be much lower, but
how low?
/Daniel
On 2023-08-02 21:57, Ari Chivukula wrote:
According to measurements in Chrome, of all cookies
set, about 20% request an Expires/Max-Age further
than 400 days in the future. Of that 20%: half
target 2 years, a quarter target 10 years or more,
and the remainder are spread over the rest of the
range.
Keep in mind this is looking at the usage of sites
*before* any cap was imposed. Although the
distribution of cookies with expirations more than
400 days in the future will be the same, the amount
will be under 20% of current storage and shrinking
as any cookies added or updated will now be forced
to respect the 400 day cap.
The motivation for this change is to require, now
that we're about to hit 400 days since the cap was
imposed on new/updated cookies, that no special
privileges be extended to cookies that just
happened to have been stored before.
~ Ari Chivukula (Their/There/They're)
On Wed, Aug 2, 2023 at 3:47 PM Alex Russell
<slightly...@chromium.org> wrote:
Hey Ari,
It isn't clear to me that the change in the RFC
is a motivator to make this change, or that it
reduces potential risk.
There are details here will matter a lot to the
risk profile. IIRC, we'll be going first with
regards to the lifetime of first-party,
server-set cookies? Do we have an analysis of
what fraction of cookies will be impacted?
Thanks,
Alex
On Tuesday, August 1, 2023 at 8:59:59 AM UTC-7
Ari Chivukula wrote:
Contact emails
aric...@chromium.org
<mailto:aric...@chromium.org>,
miketa...@chromium.org
<mailto:miketa...@chromium.org>,
bing...@chromium.org
<mailto:bing...@chromium.org>
Specification
https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
<https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute>
Summary
Since M104 cookies newly created or updated
with an expiration date would have that
date capped at no more than 400 days in the
future. This same limit will now be
retroactively applied to cookies already in
storage to cap their expiration dates to no
more than 400 days after the first time
Chrome M118+ starts up and does a one time
database migration. The impact of this
change will not be felt by users until at
least 400 days after M118 is released, and
then only for existing cookies that have
not been updated in that period.
Blink component
Internals>Network>Cookies
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies>
Motivation
The draft of rfc6265bis
<https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute>now
contains an upper limit for Cookie
Expires/Max-Age attributes. As written:
`The user agent MUST limit the maximum
value of the [Max-Age/Expiration]
attribute. The limit MUST NOT be greater
than 400 days (34560000 seconds) in
duration. The RECOMMENDED limit is 400 days
in duration, but the user agent MAY adjust
the limit to be less. [Max-Age/Expiration]
attributes that are greater than the limit
MUST be reduced to the limit.`
This limit should be enforced retroactively
to comply with the specification and clear
old cookies with high expiration dates out
on a reasonable timetable.
TAG review
Supportive
<https://github.com/w3ctag/design-reviews/issues/729>of
original change
Compatibility
In general, websites should never depend on
cookies existing for some predictable
length of time. The browser can and will
evict for any number of reasons.
Interoperability
Safari is already partially compliant (with
an upper age limit of 7 days when cookies
are set client side but no limit when set
by the server), while Firefox supports
cookies with expiration dates millennia in
the future.
Gecko: Positive
<https://github.com/mozilla/standards-positions/issues/592>
WebKit: Positive
<https://lists.webkit.org/pipermail/webkit-dev/2022-January/032096.html>
Web developers: Mostly negative or neutral
on expires limits in general
Debuggability
Existing DevTools affordances for debugging
cookie attributes will work as expected here
Is this feature fully tested by
web-platform-tests?
Yes
<http://third_party/blink/web_tests/external/wpt/cookie-store/cookieListItem_attributes.https.any.js>
Tracking bug
https://crbug.com/1181924
<https://crbug.com/1181924>
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5086241845936128
<https://chromestatus.com/feature/5086241845936128>
--
You received this message because you are
subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B_u5LB6wF%3DT9fu%2B2Svciv%2BWVu-oOVN1CWCvVAeHfVvAA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B_u5LB6wF%3DT9fu%2B2Svciv%2BWVu-oOVN1CWCvVAeHfVvAA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2ad99d54-4409-279e-2818-582158c06000%40gmail.com.
