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/f3d94992-8c71-4321-95b5-ecc068e01ab8%40gmail.com.
