Chrome 96 moved the cookie database, and half the tooling never noticed

Consider code that counts the cookies in a profile. It opens Default\Cookies, finds nothing there, and reports zero.

Zero is a valid answer. A fresh profile has no cookies. A profile that was just cleared has no cookies. Nothing about the number zero says "I looked in the wrong place", so the code does not raise, does not warn and does not log. It returns a number, and the number is wrong in a way that is indistinguishable from the number being right.

Now put that count in a user interface. A profile holding several hundred cookies displays as empty. The operator concludes their profile was wiped, which is the single most alarming thing this category of software can tell somebody, and it is not true.

This is the general shape of the worst class of bug in file-format work: the difference between absent and empty collapses, and every downstream consumer trusts the wrong one.

The current layout, on Chromium builds since 96:

Default\
  Network\
    Cookies
    Cookies-journal
  Local Storage\
  Local Extension Settings\
  Service Worker\
  History
  Preferences

The file is still SQLite. The schema is still recognisable. Values are still encrypted at rest with a key held by the operating system's credential store, which is a separate problem for anybody trying to read them from outside the browser and is the reason cookie import and export is harder than it looks.

The move itself was part of a larger reorganisation of network state inside the profile. It is not a rename anybody needs to have an opinion about. It is a fact you either encode or get wrong.

Three rules, in the order they matter.

1. Distinguish absent from empty, always. A reader that cannot tell "the file is not there" from "the file has no rows" will eventually report data loss that did not happen. Return a result that carries the difference, and make the caller handle both.
2. Check both paths and say which one you used. Old profile directories still exist; people import archives from tools that were written before the change and from backups older than it.
3. Never let a count of zero become a claim about the profile. If the count came from a file that was not found, that is a diagnostic about your reader, not a fact about the operator's data.

Ward's cookie handling is built around the first of those, and it exists because of a neighbouring bug worth its own post: a cookie count taken the instant after the browser closes is not a count either, because Chrome's file handles outlive its process exit on Windows. Same shape, different cause, same consequence - an intact profile reported as empty.

Browser profile directories are undocumented, load-bearing, and change without notice. There is no specification. There is no compatibility guarantee. The layout is an implementation detail of a program that ships every four weeks, and the only reason any of this works is that the implementation details change slowly and visibly.

If you are building anything that reads a profile directory from outside the browser, assume the layout will move again, and design so that the move is loud. The version of this code that fails with an error naming a path is infinitely better than the version that returns a plausible number.

That is the entire lesson, and it cost somebody, somewhere, a very bad afternoon believing their cookies were gone.