feat(desktop): resolve Chromium cookie keys on Linux and Windows

[juliusmarminge]

Stacked on #7260 — review that first; this PR's base is browser-import-more-sources.

Chromium calls its cookie encryption OSCrypt and implements it differently per platform. Key acquisition moves into its own module, and the extractor now picks a key per record from its prefix.

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	login keychain (consent prompt)
Linux	v10 AES-128-CBC	hardcoded peanuts passphrase
Linux	v11 AES-128-CBC	libsecret / kwallet
Windows	v10 AES-256-GCM	DPAPI-wrapped key in Local State
Windows	v20	app-bound — not readable, by design

Notes for review

A database can mix schemes, so both Linux keys are derived up front and records we hold no key for are skipped. Failing to reach the keyring is not fatal — those v11 records are skipped and the rest still import. A partial result reported honestly beats refusing everything.

Shelling out to PowerShell for DPAPI is acceptable here in a way it is not on macOS: DPAPI is transparent to any process running as the user, so there's no consent prompt to misattribute and no ACL entry to write against the wrong binary.

App-bound encryption is reported, not fought. Chrome 127+ keeps a key only the browser binary can unwrap; its cookies carry a v20 prefix. Those are skipped, and a profile with no legacy key at all surfaces appBoundEncryption so the UI can say why instead of failing obscurely.

Testing

Only the macOS path can be exercised on the machine this was written on, so the decryption paths are covered by tests that encrypt exactly as each platform does — the v127+ domain binding, a Linux database mixing v10 and v11, a missing keyring degrading to a partial import, Windows AES-GCM, and v20 being skipped rather than throwing.

Real macOS profiles still decrypt unchanged after the refactor: Helium 5,028 cookies across 756 domains, Chrome 54 across 17.

Not verified on real Windows or Linux hardware. The formats and key derivations follow Chromium's documented behaviour and are unit-tested against synthesised ciphertext, but neither DPAPI unwrapping nor a real Secret Service lookup has been run end to end. Worth a check on those platforms before relying on it.

Note

Add Chromium cookie key resolution for Linux and Windows in browser import

• Introduces ChromiumKeys.ts with platform-specific key resolution: macOS uses Keychain, Linux derives a CBC key from 'peanuts' with optional Keyring upgrade, and Windows unwraps the Local State encrypted_key via DPAPI (PowerShell subprocess).
• Adds decryptChromiumValue in ChromiumCookies.ts to route per-record decryption across CBC (v10/v11) and AES-GCM (v10) schemes; records that cannot be decrypted are counted and skipped rather than aborting the import.
• Removes the macOS-only gate from unavailableReason, so Chromium sources are now available on all platforms unless the browser is not installed or is currently running.
• Adds appBoundEncryption as a new BrowserImportUnavailableReason with user-facing copy for Windows Chrome v127+ app-bound keys that cannot be read by third-party apps.
• Risk: Windows key resolution spawns a PowerShell process (ProtectedData.Unprotect) at import time; failure maps to readFailed rather than a partial result.

^{Macroscope summarized cf8dfa2.}

---

Note

Medium Risk
Touches cookie decryption and spawns PowerShell for DPAPI at import time; wrong key handling could silently skip cookies, though empty DPAPI results are guarded and undecryptable rows are counted.

Overview
Chromium browser import is no longer macOS-only: key resolution moves into ChromiumKeys, and cookies decrypt per record from v10 / v11 / v20 prefixes instead of a single macOS-only path.

Linux derives v10 from Chromium’s peanuts fallback and optionally v11 from libsecret/kwallet; a missing keyring yields a partial import, not a hard failure. Windows reads Local State, unwraps the legacy key via DPAPI (PowerShell), and decrypts AES-GCM v10 records. v20 app-bound cookies are skipped; profiles with only an app-bound key surface appBoundEncryption in contracts with user-facing copy.

BrowserImport drops the Chromium-on-non-macOS gate, wires localStatePath and ChildProcessSpawner, and expands tests for cross-platform decryption and DPAPI marker handling.

^{Reviewed by Cursor Bugbot for commit cf8dfa2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: bc7ad5e5-07f1-4b51-8d95-715f5ad63f93

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 46ce064.

This comment will update automatically after the next completed run.

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

2 blocking correctness issues found. This PR enables Chromium cookie import on Linux and Windows, adding substantial new platform-specific credential access and decryption logic. The new capability, security-adjacent nature, and unresolved findings about potentially incomplete Linux imports and domain hash handling warrant human review.

No code changes detected at cf8dfa2. Prior analysis still applies.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🟠 High BrowserImport/ChromiumKeys.ts:232

Linux imports silently omit every v11 cookie when Chromium stores its OSCrypt secret in Secret Service, making the import incomplete. readKeychainSecret uses Keyring.Entry(service, account) with the macOS-style coordinates, but Linux Chromium stores the secret under its custom Secret Service schema (for example, chrome_libsecret_os_crypt_password_v2 with an application attribute); the lookup fails and Effect.orElseSucceed suppresses the error. Use the Linux-specific Secret Service lookup and derive cbcV11 from that result.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/desktop/src/preview/BrowserImport/ChromiumKeys.ts around line 232:

Linux imports silently omit every `v11` cookie when Chromium stores its OSCrypt secret in Secret Service, making the import incomplete. `readKeychainSecret` uses `Keyring.Entry(service, account)` with the macOS-style coordinates, but Linux Chromium stores the secret under its custom Secret Service schema (for example, `chrome_libsecret_os_crypt_password_v2` with an `application` attribute); the lookup fails and `Effect.orElseSucceed` suppresses the error. Use the Linux-specific Secret Service lookup and derive `cbcV11` from that result.

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One convention finding on the new ChromiumKeys module: the known-tag recovery uses catchIf with a schema predicate rather than Effect.catchTags. Everything else in the new key/decrypt split (error structure, structural exitCode/localStatePath context, preserved cause, requirements exposed through Effect.fn.Return) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 7f41045. Configure here.}