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/64f47f10-4fb8-47c3-89dd-43ac1f0594d8%40chromium.org.
