Pup - the AI's own browser

@@ -0,0 +1,146 @@+---+name: pup-browser-import+description: How to import a user's existing Chrome logins (passwords, cookies/sessions) into pup's profiles to seed the adom-you profile - the App-Bound Encryption (ABE) wall, the admin/SYSTEM path that defeats it, and the hard-measured reality of what actually imports vs what is blocked. Includes the reverse-engineered playbook from OpenAI Codex Desktop's "Import from Chrome" flow. READ BEFORE building or debugging any Chrome-data import, credential-vault seeding, or "get the user's logins into pup" feature.+---++# Importing the user's Chrome logins into pup (the adom-you seed)++The `pup` core goal (see the root `SKILL.md`) is to build up an **adom-you** profile: the pup+browser accretes the user's real logins so the agent can act as them. The fastest seed for that is+to import the logins the user ALREADY has in their everyday Chrome. This file is the hard-won map of+what is actually possible on a modern (2024+) Windows Chrome, so the next maintainer does not+re-derive it or over-promise a silent import that Windows blocks by design.++Most of what is below was learned on 2026-08-02/03 by watching **OpenAI's Codex Desktop** run its+own "Import from Chrome" flow on John's machine, side by side with our own probes. John's framing:+"the info about Codex's approach is gold." It is - it told us exactly which walls are real.++## The core obstacle: Chrome App-Bound Encryption (ABE)++Since **Chrome 127 (Aug 2024)** on Windows, Chrome no longer protects your passwords/cookies with a+key a normal user process can unwrap. Instead:++- Chrome ships **`elevation_service.exe`**, a helper that runs as **SYSTEM**. It owns the master key+  that decrypts cookies and passwords, and it stores that key **double-wrapped with DPAPI - the+  outer layer under the SYSTEM account**, not the user. In `Local State` this is the+  `os_crypt.app_bound_encrypted_key` field (base64, `APPB` prefix).+- A normal user-context app (our Chrome for Testing, a plain PowerShell/DPAPI helper, Codex's+  non-elevated code) runs as *the user*, so it **cannot** unwrap the SYSTEM layer. This is the whole+  point of ABE: it assumes malware runs as a normal user, so it puts the key one privilege level up.+- Encrypted blob versions tell you which scheme protects a value:+  - `v10` / `v11` = legacy os_crypt (user-DPAPI key). A same-user app CAN decrypt these.+  - `v20` = App-Bound. Needs the SYSTEM-level app-bound key. A user app canNOT decrypt these.++### Measured reality on John's Chrome 150 (2026-08-03)++Probed via `adom-desktop shell_execute` (PowerShell + the desktop's Python, which parsed the actual+`Login Data` SQLite):++- `chrome_version = 150.0.7871.187`+- `Local State` has BOTH `app_bound_encrypted_key` (ABE) AND the legacy `encrypted_key`.+- 4 profiles: `Default`, `Profile 1` (main - 873 logins), `Profile 2`, `Profile`.+- **`Profile 1` Login Data: 873 saved passwords, 829 non-empty, and EVERY non-empty blob is `v20`.+  ZERO `v10`/`v11`.** (A naive byte-scan first reported "784 v10" - that was pure binary noise;+  parsing the SQLite `logins` table showed the truth: all `v20`.)++Lesson: **do not byte-scan for `v10`/`v20` counts. Parse the SQLite `logins.password_value` blobs.**+The desktop has `python` on PATH (`sqlite3` stdlib) - use it, don't hand-roll SQLite in PowerShell.++Consequence: a **DPAPI / copy-the-file import gets ZERO passwords and ZERO cookies** on this machine.+Everything is `v20`. That is why our first plan (silent same-user DPAPI import) was dead on arrival.++## The Codex Desktop playbook (reverse-engineered from its UI)++Codex's "Import from Chrome" is the reference implementation of doing this RIGHT. What we observed:++1. **Import prompt on first run** ("Import data from Chrome - bring over your passwords and cookies+   to the built-in browser", with an Import button). So they seed on first run - mirror this.+2. **Import dialog** with a source-profile picker ("From: Google Chrome adom.inc"), separate+   **Passwords** and **Cookies** toggles (both default ON), and a required consent line:+   > "Administrator approval required. Windows protects Chrome cookies and passwords with App-Bound+   > Encryption, so ChatGPT also needs administrator approval." + an "I understand the app will+   > request administrator approval" checkbox.+   That **admin approval is a UAC elevation** - it is how they reach SYSTEM to unwrap the ABE key.+   There is no way around the prompt; ABE is specifically designed to force it.+3. **Result dialog** ("Import complete"):+   - **Passwords: succeeded (checkmark).** So the admin/SYSTEM path DID decrypt the `v20` passwords.+   - **Cookies: FAILED** - "ChatGPT couldn't access this profile's cookies. A device security+     policy may be blocking access."++### What the result teaches us (the gold)++- **Passwords ARE recoverable from a modern ABE Chrome - but only with administrator/SYSTEM.** The+  admin helper becomes SYSTEM, does the same DPAPI unwrap `elevation_service.exe` does, recovers the+  master key, and decrypts `v20`. Any earlier claim that "even passwords are locked" is WRONG without+  the admin qualifier: locked to a *user* process, open to a *SYSTEM* one.+- **Cookies can be blocked EVEN WITH admin, by a device/enterprise security policy.** John's Chrome+  profile is `adom.inc` - an **enterprise-managed** profile. The cookie unwrap failed where the+  password unwrap succeeded, so the block is cookie-specific and policy-driven (candidates: Intune/MDM+  device policy, a Chrome enterprise policy, DLP, or an ASR rule that specifically guards the cookie+  store / the elevation-service cookie path). It is NOT a generic "ABE is unbreakable" wall - the+  passwords proved the ABE break works on this box; something extra guards the cookies.+- Net: on a managed device, **plan for passwords to import and cookies to be refused.** Do not build+  the feature such that a cookie failure blocks the password import (Codex reports them+  independently - do the same).++## Implications for pup's import feature (the plan)++Priority order, matching what actually works:++1. **Passwords via an admin-elevated SYSTEM helper** (the Codex path). This is the real feature:+   - AD-side (NOT the container bridge - the container can't touch Windows DPAPI or elevate): a+     helper that requests UAC elevation, gets a SYSTEM token, unwraps+     `os_crypt.app_bound_encrypted_key` (strip `APPB`, SYSTEM-DPAPI unwrap, then user-DPAPI unwrap) to+     get the AES-256-GCM master key, copies `Login Data`, decrypts each `v20`+     `password_value` (3-byte version prefix, 12-byte nonce, ciphertext, 16-byte GCM tag), and returns+     `{origin, username, password}` rows.+   - Bridge side: import those rows into pup's **credential vault** (`src/credential_vault.js`) so the+     EXISTING `autoLogin` path signs the agent into sites and builds FRESH sessions (more durable than+     copied cookies, which expire anyway).+   - Never write a plaintext CSV/file. Decrypt in memory, hand to the vault, zero the buffers.+2. **Cookies: attempt, but treat failure as normal.** Same SYSTEM helper can try the `Cookies`+   store (`Network\Cookies`, `v20`, same master key). On a managed profile expect the+   "device security policy" refusal - surface it honestly per-item (Codex-style), do not fail the run.+3. **First-run prompt + a dashboard "Import from Chrome" settings section** (John's explicit ask), so+   the user can run it later if they skip first-run. Per-profile picker (enumerate `Default` ++   `Profile*`). Show the same honest consent about the admin prompt.++### Passkeys and camera (asked about, decided)++- **Passkeys canNOT be imported by anyone** - not Codex, not us. The private key is TPM/Windows-Hello+  bound and non-exportable BY DESIGN. Codex "enumerating passkeys" (its Windows-auth escalation+  window) = listing/using platform credentials via the Windows WebAuthn API, not copying them. pup's+  play is to let a pup window **USE** the user's Windows Hello passkeys during a WebAuthn sign-in (a+  real CfT window on the desktop can invoke the platform authenticator like normal Chrome - VERIFY+  this fires before promising it). Never claim passkey "import".+- **Camera: not needed.** Codex asked for it; pup has no reason to. Do not request it.++## Ethics / framing (so this does not get mis-read as an attack tool)++This is the user decrypting **their OWN** browser data, on **their OWN** machine, with an **explicit+UAC admin prompt** - exactly what every password-manager "import from Chrome" and Codex/ChatGPT+Desktop itself does. It is legitimate. It is ALSO defeating a security control, so:+- Always require the real UAC elevation - never try to hide it or auto-approve it.+- Never build a path that reads another *user's* profile or a profile without the live consenting+  user. Same-machine, same-user, admin-consented only.+- Get the user's explicit go before shipping the elevated helper (John gave it for the design; get it+  again before the elevated code lands).++## Open questions to verify before shipping++- Exactly which policy blocks cookies on the `adom.inc` managed profile (Intune? Chrome enterprise+  policy? ASR?) - and whether an UNmanaged profile on the same box imports cookies fine. That tells us+  whether cookie import is ever worth offering or should be quietly omitted on managed devices.+- Whether AD already has an elevate-to-SYSTEM primitive or that helper is net-new AD-core work (this+  is an AD-boundary question - see `adom-desktop-bridge-ownership`; the elevation primitive is+  probably AD-core, the Chrome-blob decryption + vault import is ours).+- Whether a pup CfT window actually triggers Windows Hello for a passkey WebAuthn ceremony, or whether+  automated Chrome silently routes to a virtual authenticator and needs a flag.++## One-line summary++Modern Chrome (127+) locks passwords AND cookies with App-Bound Encryption; a **user** process gets+nothing (`v20` everywhere). **Admin -> SYSTEM -> DPAPI-unwrap** recovers the master key and decrypts+**passwords** (proven by Codex on John's box); **cookies** can still be refused by an+enterprise/device security policy. Build the password import on the admin/SYSTEM helper, feed the+credential vault + autoLogin, treat cookies as best-effort, and never pretend to import passkeys.