# Chrome App-Bound Encryption and cookie tools > App-Bound Encryption ties Chrome's cookie key on Windows to Chrome itself, so tools reading the Cookies file broke. Export from inside the browser. Source: https://mosaicbrowser.com/blog/chrome-app-bound-encryption ## App-Bound Encryption, and why tools stopped reading Chrome's cookies App-Bound Encryption ties Chrome's cookie key on Windows to Chrome itself, so tools reading the Cookies file broke. Export from inside the browser. ![The key belongs to the browser that wrote the jar, beside a screenshot: importing a cookie jar into a Mosaic profile](https://mosaicbrowser.com/covers/chrome-app-bound-encryption.webp) App-Bound Encryption is why a script that used to read Chrome's cookies on Windows now gets nothing it can use. Google added it to Chrome on Windows in 2024. The key for the `Cookies` file is wrapped a second time, and only a Chrome service that checks who is calling will unwrap it, so a tool reading the file from outside gets ciphertext. The fix that lasts is to export cookies from inside the browser. ## What changed in how Chrome encrypts cookies The jar is an SQLite file, `Network\Cookies` under the profile folder, and each value in it is encrypted. What App-Bound Encryption changed is where the key lives and who can get it back. Before, the key sat in `Local State` as `os_crypt.encrypted_key`, protected by DPAPI. DPAPI is Windows encrypting something for your user account, which keeps out other accounts on the PC and nobody else. Any program running as you can call it and get the key in one line, because to Windows that program is you. Cookie-stealing malware used exactly that call. Now there is a second entry, `app_bound_encrypted_key`, and Chrome writes new values with a `v20` prefix instead of `v10`. To unwrap it, Chrome asks its own elevation service, `elevation_service.exe`, which runs as SYSTEM and checks that the caller is the Chrome binary in the folder Chrome was installed to. A Python script running as you asks the same question and gets refused. Google's stated goal was to make a cookie thief need admin rights or code injected into Chrome, both of which are noisier than a DPAPI call and easier for antivirus to spot. None of this exists on a Mac. There the key is a login-keychain item called `Chrome Safe Storage`, and a program macOS has not seen before gets a dialog when it asks. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Local first](https://mosaicbrowser.com/features/local-first) ## What broke, and what we take from it On Windows Chrome, whatever opened `Cookies` as a file stopped working: export scripts, test harnesses that reused a logged-in session, command-line downloaders with a "use my browser's cookies" option, and the libraries under all of them. They had done nothing wrong. They read a file whose key used to be reachable, and then it wasn't. Our reading of it: the jar belongs to the browser that wrote it. Chrome picked the key and, for years, left it where any process you ran could fetch it, until Google moved it. Reading from outside worked the whole time, but nobody had ever promised it would keep working. ## Exporting cookies the way that keeps working Ask the browser, not the disk. In each of these Chrome does the decrypting itself: 1. An extension with the `cookies` permission calls `chrome.cookies.getAll()` and writes the result out as JSON or as a Netscape `cookies.txt`. 2. DevTools lists the current site's cookies under Application, then Cookies. Copying rows from there is fine for a one-off. 3. If you started Chrome yourself with a debugging port, `Storage.getCookies` over the DevTools protocol returns every cookie already decrypted, because Chrome is the one answering. All three need the browser open with the profile in it. We think that is right, because a cookie is a login, and the browser holding it should be the one handing it over. ## How Mosaic's cookie jars are encrypted Mosaic met this problem from the browser's side. Our engine starts with `--use-mock-keychain` and `--password-store=basic`, so no profile reads or writes the Mac's login keychain. That was deliberate, because otherwise a keychain dialog greets every profile's browser as it starts. It had a cost, and we found it on 14 September 2026. Under the mock keychain, Chromium derives the cookie key from a password that is a constant in its own public source. We pointed one command at a real profile on our machine, with no special rights, and got this back: ``` DECRYPTED password "mock_password", offset 32 .dev.to _Devto_Forem_Session = "bb0cbcf3b126b691797c6126a7f3ae48" ``` That is a live session cookie, read off the disk in about a second. So we replaced the constant. Mosaic has one data key. Each profile's cookie key is derived from it and the profile's id with scrypt, and the engine gets that key through a switch at launch. The `Cookies` file is now sealed with a key that only Mosaic's vault can produce, and there is no separate key file per profile to keep track of. The store, proxy passwords included, is sealed under the same data key. App lock, under Settings › Security, puts the data key behind your password as well, again through scrypt. With it on, a copied disk is ciphertext until somebody types that password. What it cannot fix is how the key gets to Chromium: as a switch on the command line, which `ps -ef` will print for the user who launched it. So a laptop left in a taxi or a backup on someone else's drive is covered, and malware already running under your login is not. We don't say it is. The upside of holding the key is that Mosaic can open its own jars, which is what the Cookies tab in the profile editor does. Paste in a JSON array, a Netscape `cookies.txt` or a `Cookie:` header and it lands in the profile. Export goes the other way. Change one value while the browser is open and the browser picks it up, no restart. What leaves the jar, and when, is on [local-first](https://mosaicbrowser.com/features/local-first). ## When you need someone else's cookies in a profile App-Bound Encryption closed the route of copying a client's session out of their Chrome by reading the disk. We would not use it anyway. Ask the client to export from inside their browser. Better still, have them sign in themselves, in the profile you set up for them, so the password, the new-device check and the second factor happen once, in the browser that will keep using the session. It also keeps their login out of a Chrome that syncs to somebody's Google account, which is how [Chrome sync quietly joins accounts](https://mosaicbrowser.com/blog/chrome-sync-joins-accounts) you meant to keep apart. When a client relationship ends, [offboarding a client's profiles](https://mosaicbrowser.com/blog/client-offboarding-browser-profiles) covers what to hand back and what to delete. ## Questions ### What is App-Bound Encryption in Chrome? Chrome on Windows, since 2024, wraps its cookie key a second time. Only Chrome's elevation service unwraps it, and it checks that the caller is Chrome, so a script running as you can no longer get the key from DPAPI and read the jar. ### Does App-Bound Encryption apply on a Mac? No. It is Windows only. On a Mac the key is in the login keychain as Chrome Safe Storage, and macOS shows a dialog before handing it to a program it does not know. ### How do I export my Chrome cookies now? From inside the browser. Use an extension that calls chrome.cookies.getAll(), copy rows from the Application panel in DevTools, or call Storage.getCookies on a Chrome you started with a debugging port. Chrome decrypts in all three. ### How does Mosaic encrypt cookie jars? Each profile's cookies are sealed with a key derived from one data key and the profile's id, and the engine is given that key at launch. Turn on app lock and the data key is itself wrapped under your password, so nothing decrypts until you type it. ## Related [Chrome sync quietly joins accounts you meant to keep apart](https://mosaicbrowser.com/blog/chrome-sync-joins-accounts): Chrome sync files everything a profile does under one Google account, whichever account you used in the tab. Two accounts in one profile end up in one history. [Chrome kept third-party cookies. What that means for cookie jars](https://mosaicbrowser.com/blog/chrome-keeps-third-party-cookies): Chrome is not removing third-party cookies: Google dropped the phase-out and then the prompt. A jar per account matters as much as it did before. [Local first: your profiles stay on your computer](https://mosaicbrowser.com/features/local-first): Mosaic has no cloud copy of your profiles. Profiles, cookies and proxies stay on your computer, encrypted on disk, with app lock, daily backups and a trash. [What to do with a client's browser profile when the contract ends](https://mosaicbrowser.com/blog/client-offboarding-browser-profiles): Agency client offboarding goes wrong when access is revoked before the client can sign in. Confirm the handover, export, then trash the profile by id. [Device-bound sessions and the end of copying a cookie](https://mosaicbrowser.com/blog/device-bound-session-credentials): With Device Bound Session Credentials in Chrome, a site reissues its session cookie only to the device with the key. A copied cookie lasts until it expires. [Chromium's mock keychain, and why we encrypt the store](https://mosaicbrowser.com/blog/mock-keychain-cookies): Chromium's --use-mock-keychain keeps cookie encryption on but uses a password from its own source. We read a live session cookie off disk, then sealed it.   ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.