Cookies are stored in an SQLite database defined by sqlite_persistent_cookie_store.cc. The schema for this database has been updated over time to accommodate new fields and improved indices. If a user upgrades their version of Chrome, and the new version has a different schema, then Chrome performs a migration of the database. The earliest version we can migrate from is v9 from 2015 and the latest version is v18 from 2022.
Define a clear retention period for the cookie database migration code so that we don’t indefinitely build up tech debt.
Retain the earliest version that was state-of-the-art as of two years ago.
For example, if 2.5 years ago we introduced v10 and 1.5 years ago we introduced V11, then v10 should be the earliest supported version we migrate from as it was state-of-the-art two years ago. All versions earlier than v10 could be deleted from the codebase in this example.
We want to pick a retention period beyond which most users will have already upgraded and/or aren’t generally in active use. Two years seems to give us that window from both a release perspective and a usage perspective.
ChromeOS LTS support goes back about 13 months in the codebase. This includes the three month window of code before a branch cut for the Long Term Support Candidate (LTC) release, the one month before the LTC is released, the 3 months the LTC is active, and the following 6 months where the LTC becomes the latest Long Term Support (LTS). A two year period covers all of that and one additional 6 month LTS release so those on this channel won’t fear losing their cookies on a standard upgrade cycle.
Extended stable’s cycle is shorter than ChromeOS LTS, so I did not consider its timeline here.
As of Jul 18, 2023 the version of Chrome on the stable channel two years ago was M91. As of Jul 18, 2023 1% of clients are using M90 or earlier (as judged by Startup.FirstWebContents.MainNavigationFinished split by version back to M76). This is high, but given the cost of such a cutoff is simply the loss of cookies on upgrade it seems reasonable to drop support for databases so far out of support. Out of date clients that update to an LTS version would retain their cookies as legacy migrations won’t be removed from an LTS version for at least 9 months.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGpy5DL8N%3D-T2T591PfJwKGm4jiAgS8LbJAv7R5y4FvT4z5NTA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEmk%3DMa1z-xmiqN9TWcvVvMWkzHTL8Okk1jSB3XavOnSBnsthQ%40mail.gmail.com.
It's also worth chatting with WebView folks (+Beverloo, Torne)
about the implications there (if any...). Deprecations in the
WebView Cinematic Universe™ operate on different timescales than
in Chrome.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGpy5D%2B-8DT5rw33mDH3npu6a6css1xvtQurzjSVuEXmmJbi1w%40mail.gmail.com.