Safari does not encrypt its cookies. It stores them in a proprietary
`Cookies.binarycookies` file whose protection is TCC rather than cryptography:
the file sits inside the app container, which only apps with Full Disk Access
may read. So the gate is a permission the user grants in System Settings, and
a denial is reported as exactly that rather than as a generic read failure.

Two details the format forces:

Timestamps count seconds from 2001-01-01, not the UNIX epoch, so every expiry
needs rebasing or cookies import as long expired.

The format predates SameSite and carries no equivalent field. Imported cookies
are marked Lax, the modern browser default — claiming "none" would widen the
scope of every cookie Safari ever set.

Safari keeps one jar for the whole app rather than per-profile, so it exposes
a single implicit profile, and it has no observable lock file since the jar is
written atomically.

The parser is covered by tests that build the binary format byte for byte,
including a multi-page file — Safari pages its jar, and a single-page reader
would silently return only the first slice. That coverage matters because the
real file cannot be read on this machine without the very permission the
feature asks for; the TCC path itself was verified against the live file,
which denies with EPERM and reports `needsFullDiskAccess`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>