[chromium-dev] Removing Legacy Cookie DB Migrations

[Ari Chivukula]

Introduction

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.

Goal

Define a clear retention period for the cookie database migration code so that we don’t indefinitely build up tech debt.

Proposal

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.

Reasoning

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.

Implementation

A draft CL removing support for older migrations (and related tests) is available to view in https://chromium-review.googlesource.com/c/chromium/src/+/4701765.

[Reilly Grant]

I recommend working with Chrome ATLs to define a project-wide policy on supporting on-disk data migrations from older versions.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

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

[PhistucK]

Considering the intent to delete/ignore cookies older than 2 years old anyway, this seems to have zero impact (unless enterprise policies can override the intent), as long as this is a recoverable error and the browser is still usable following a failed migration.

☆PhistucK

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.

[Ari Chivukula]

This is a little different. It's true that if you have a version of chrome you haven't used or updated in two years all the cookies will be cleared one way or another, but if you have an old version of chrome in use that you then upgrade you would lose cookies due to the db migration changes and not the 400 day expiration day cap.

If an upgrade doesn't support the older cookie db it's simple cleared and the browser remains usable. One would have to login and/or handle cookie opt-outs afresh though.

~ Ari Chivukula (Their/There/They're)

[Mike Taylor]

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.