trash 24 stale root files; clean dist dirs on every build (v1.9.7)

@@ -1,135 +0,0 @@1-# Peach Extension — v1.3.0 Audit2-_April 2026_3-4----5-6-## Summary7-8-v1.3.0 is a genuinely impressive ship. All eleven gap-spec tasks and the full Peach Sync foundation are confirmed implemented in source. The extension now has licensing, canary entries, duress password, secure notes, tags, health dashboard, QR codes, site policy detection, legacy import, and a working Firefox build. Two real bugs need fixing before any money changes hands, and the main bundle needs one more targeted split.9-10----11-12-## Gap Spec — Task-by-Task Status13-14-### ✅ Task 0 — Website copy (Firefox/Android "available now")15-Cannot verify directly — the peachpasswords folder is not mounted in this session. No CONTINUITY entry confirms the change. **Treat as unverified; check `src/data/site.ts` in the peachpasswords repo before any public announcement.**16-17-### ✅ Task 1 — Ed25519 licensing18-`src/background/license.ts` is fully implemented. `validateLicense()` decodes the `PPK-` prefixed base58 string, checks the 76-byte structure (12-byte payload + 64-byte Ed25519 signature), verifies against the hardcoded public key via `crypto.subtle.verify("Ed25519", ...)`, and returns `{ valid, plan, issued }`. `activateLicense()`, `getLicenseInfo()`, and `isProUser()` are all present. License is persisted at `peach_license` in `chrome.storage.local`. Settings.tsx wires in the activate form with error/success states. The Pro gate overlay on Sync settings is rendered.19-20-### ✅ Task 2 — Canary entries21-`VaultEntry` has `canary?: Canary` with `webhookUrl`, `label`, `lastPinged`, `pingCount`. Entry.tsx fires `FIRE_CANARY_PING` on copy, autofill, and submit — with a session-level suppress toggle (🪤 badge visible). Add.tsx has full canary configuration UI including webhook test. Background handler for `FIRE_CANARY_PING` dispatches fire-and-forget fetch.22-23-### ✅ Task 3 — Duress password24-`vault.ts` has `vaultMode: "real" | "decoy"`. Unlock tries the real vault, then falls back to `peach_decoy_vault` if duress is enabled and decoy decryption succeeds. All writes use `vaultMode` to select the storage key. `setupDuress()`, `disableDuress()`, and `isDuressEnabled()` are implemented. Message handlers: `IS_DURESS_ENABLED`, `SETUP_DURESS`, `DISABLE_DURESS`, `VERIFY_MAIN_PASSWORD` all present in `messages.ts`.25-26-### ✅ Task 4 — Secure notes27-`VaultEntry` has `type?: "login" | "note"`. Add.tsx renders a two-tab form (Login / Note) via `selectedType` signal. Note-only entries suppress username/password/URL fields. The health dashboard correctly filters out notes from weak/old/reused password checks.28-29-### ✅ Task 5 — One-tap breach regeneration30-`Entry.tsx` has `showRegenPanel` signal and renders the inline regen panel below the breach badge. The panel is implemented (confirmed at lines 306 and 349).31-32-### ✅ Task 6 — QR codes33-Two QR paths confirmed:34-- **CJK phrase QR** — `CJKExport.tsx` dynamically imports `qrcode`, encodes the phrase string, shows "vault too large" message when it won't fit, with a toggleable overlay.35-- **TOTP QR** — `Entry.tsx` dynamically imports `qrcode` and renders the `otpauth://` URI as a QR modal, triggered by a dedicated glyph button.36-37-Both use `import("qrcode")` so the 23KB `vendor-qr` chunk is only fetched on demand.38-39-### ✅ Task 7 — Site password policy detection40-`content/index.ts` implements `detectPasswordPolicy()` reading `maxlength`, `pattern` attributes, and nearby DOM text (via `aria-describedby`, walking up 3 parent levels to find `.hint`/`.requirement` elements). `GET_SITE_PASSWORD_POLICY` message handler is wired at line 437. `PasswordPolicy` interface is in `shared/types.ts`.41-42-### ✅ Task 8 — Tags43-`VaultEntry` has `tags?: string[]`. Add.tsx has a chip-input with 32-char limit, 10-tag cap, and backspace-to-remove. Vault.tsx renders a horizontal scrollable tag filter strip; selecting multiple tags AND-filters the entry list alongside the text search.44-45-### ✅ Task 9 — Health dashboard46-`src/popup/views/Health.tsx` is fully implemented (282 lines). Four collapsible sections: Breached (sorted by exposure count with `formatExposure`), Reused (SHA-256 hash comparison across all login entries, groups of 2+), Weak (zxcvbn score ≤ 1), Old (365-day threshold, `modifiedAt`). Each row has a Fix button. "Check all breaches" triggers `CHECK_ALL_BREACHES`. Lazy-loaded in App.tsx at the `"health"` view.47-48-### ✅ Task 10 — Legacy Peach JSON import49-`import.ts` has `parsePeachLegacyJSON()` that handles the `exportFormat: "peach-vault"` shape. Maps `entry.name → title`, `login.urls[0] → url`, `login.username`, `login.password`, `login.totp.secret → totp`, `login.notes`, `entry.created/modified → createdAt/modifiedAt`. Non-login types (card, identity, etc.) are skipped with a count. `detectImportFormat()` checks `data.exportFormat === "peach-vault"` before all other formats.50-51-### ✅ Task 11 — Firefox extension52-`manifest.firefox.json` exists with `browser_specific_settings.gecko.id = "[email protected]"`. `webextension-polyfill` and `web-ext` are in `package.json`. `build:firefox` and `package:firefox` scripts are present. `vite.config.ts` selects the correct manifest via `BUILD_TARGET` env var and outputs to `dist-firefox/`. Both `dist-chrome/` and `dist-firefox/` are populated with identical JS chunks.53-54----55-56-## Peach Sync — Status57-58-All TypeScript infrastructure is in place: `src/shared/sync-types.ts`, `src/sync/noise.ts`, `src/sync/manifest.ts`, `src/background/sync.ts` (Native Messaging adapter), `src/background/sync-storage.ts`, `src/background/sync-network.ts`. SyncPairing.tsx and the Settings sync panel are implemented with the Pro gate overlay.59-60-The native Rust host (`native/peach-sync-host/`) is not a scaffold — it's a real implementation: `main.rs` (tokio async, graceful shutdown, structured logging), `lib.rs` (331 lines, HostCore), `noise.rs` (174 lines), `mdns.rs` (153 lines), `tcp.rs` (225 lines), `message.rs`. Total: 883 lines of Rust.61-62-What the native host **does not yet have**: a native messaging host manifest (`com.peachpasswords.sync.json`), an install script (macOS: `~/Library/Application Support/Google/Chrome/NativeMessagingHosts/`, Windows registry, Linux `~/.config/google-chrome/NativeMessagingHosts/`), or a release binary. Users cannot use Peach Sync without these — the extension will silently fail to connect.63-64----65-66-## Bug Reports67-68-### 🔴 BUG 1 — `nativeMessaging` missing from Chrome manifest69-70-`manifest.json` (Chrome) permissions: `["storage", "activeTab", "scripting", "clipboardWrite", "alarms", "idle"]`71-72-`manifest.firefox.json` permissions include `"nativeMessaging"`.73-74-Chrome will reject `chrome.runtime.connectNative("com.peachpasswords.sync")` with a permission error unless `nativeMessaging` is declared. The sync UI will appear for Pro users, they'll try to pair, and it will silently fail. Add `"nativeMessaging"` to the Chrome `manifest.json` permissions array.75-76-### 🟡 BUG 2 — Main bundle still 900KB77-78-The dist-chrome build shows:79-```80-App-Bv6360ZC.js   900KB  ← core popup bundle81-domain-rLGCi-Ud   106KB  ← tldts (content script dep, probably fine)82-CJKExport          91KB  ← lazy ✅83-index.esm          44KB  ← noble/ciphers84-vendor-otp         25KB  ← otpauth85-vendor-qr          23KB  ← qrcode (lazy ✅)86-vendor-parse       19KB  ← papaparse87-vendor-solid       18KB  ← solid-js88-Health-D3mE3jHt   8.6KB  ← lazy ✅89-Settings-DIO2aRqb 6.5KB  ← lazy ✅90-Export-DbL4ASvV   4.4KB  ← lazy ✅91-Generator-FAdaEqya 4.0KB ← lazy ✅92-```93-94-The lazy splitting is working correctly. The 900KB App chunk is dominated by `zxcvbn` (~800KB gzipped: ~200KB). zxcvbn is only needed in the Health view and the Generator strength meter. Both are already lazy chunks, but something is importing zxcvbn into the main path. Find the `import zxcvbn from "zxcvbn"` at the top of `Health.tsx` (line 2) — that import pulls zxcvbn into the lazy chunk, but if any component rendered eagerly also references it (even indirectly), the bundler will hoist it to the main chunk. Audit all non-lazy view files for zxcvbn usage. If the Generator strength bar uses it inline, the fix is to dynamically import zxcvbn within the Generator component.95-96-Splitting zxcvbn out of the main chunk alone would bring the App bundle from ~900KB to ~100–120KB, well under the Chrome Web Store's 4MB popup limit and meaningfully faster to parse on first open.97-98----99-100-## Test Coverage101-102-Seven test files exist: `vault.test.ts`, `cjk.test.ts`, `cjkPayload.test.ts`, `cjkRoundTrip.test.ts`, `cjkSerialise.test.ts`, `crypto.test.ts`, `import.test.ts`. Tests could not be executed in this audit environment (rolldown requires a native arm64 binary not available in the sandbox). Run `npm test` on your local machine to confirm current pass rate. The import tests in particular should cover the new `parsePeachLegacyJSON` path.103-104----105-106-## Chrome Web Store Readiness107-108-Before submitting:109-110-- **Fix the `nativeMessaging` permission** (Bug 1 above). Without it, Sync doesn't work and the store review may flag the missing declaration.111-- **Verify website copy** — confirm Firefox and Android no longer say "available now" in `peachpasswords/src/data/site.ts`.112-- **Native host installer** — without a packaged installer and the host manifest JSON file, Peach Sync is a non-functional Pro feature. Either ship the installer alongside the extension or gate the Sync UI behind a "requires desktop companion" notice until the installer is ready.113-- **Privacy policy URL** — the store listing requires a URL. The security page at peachpasswords.com/security partially covers this but a formal `/privacy` page is expected.114-- **Store listing assets** — screenshots (1280×800 or 640×400), promotional tile (440×280), short description (132 chars max), detailed description. These don't exist yet.115-- **Single-purpose statement** — Chrome requires extensions to have a single, clear purpose. "Zero-knowledge password manager" is clean; make sure the listing doesn't mention future Android/Firefox plans as if they're current.116-117----118-119-## What's Left Before Selling120-121-| Item | Status |122-|------|--------|123-| All gap spec features | ✅ Implemented |124-| Peach Sync TS infrastructure | ✅ Implemented |125-| Native sync host (source) | ✅ Implemented |126-| Native host installer + host manifest | ❌ Missing |127-| `nativeMessaging` in Chrome manifest | ❌ Missing |128-| zxcvbn out of main bundle | ⚠️ Should fix |129-| Website copy (Firefox/Android) | ⚠️ Unverified |130-| Privacy policy page | ❌ Missing |131-| Store listing copy + screenshots | ❌ Missing |132-| Payment flow (Gumroad/Stripe → license key delivery) | ❌ Not reviewed |133-| `npm test` passing locally | ⚠️ Unverified in sandbox |134-135-The extension itself is feature-complete. The remaining work is packaging, infrastructure, and store listing — not feature development.

@@ -1,354 +0,0 @@1-# Peach v1.4.10 — Codebase Audit & State of the Union2-3-_Every source file read, every message handler traced, every security surface examined._4-5----6-7-## 0. Verdict8-9-Peach went from skeleton to working extension in a single session and it shows remarkable structural soundness — the cryptographic core (AES-256-GCM, Argon2id KDF, HIBP k-anonymity, CBOR passkey encoding) is all correctly implemented. The extension is ready for careful daily driving with one critical fix and three high-priority fixes applied first. There are no credential-leaking bugs. There are no plaintext vault bugs. The passkey flow is real and correct. What's broken is largely wiring — a null return where a policy lookup should happen, a WeakMap that doesn't invalidate on SPA navigation, sync handlers that are stubs.10-11----12-13-## 1. Files Audited14-15-| Layer | Files |16-|---|---|17-| Background | entry.ts, vault.ts, messages.ts, alarms.ts, aes.ts, license.ts, passkey.ts, passkey-crypto.ts, sync.ts, sync-storage.ts, sync-network.ts, clipboard.ts |18-| Content | index.ts, inject.ts, detect.ts, fill.ts, save.ts |19-| Crypto | totp.ts, argon2.ts (path traced), aes.ts |20-| Shared | types.ts, generate.ts, domain.ts, sync-types.ts |21-| Popup | App.tsx, Entry.tsx (key sections) |22-| Build | manifest.json, CONTINUITY.md |23-24----25-26-## 2. Critical Bugs (fix before daily driving)27-28-### C-1: Site password policy is permanently broken29-30-**File:** `src/background/messages.ts` line 222  31-**File:** `src/popup/views/GeneratorDrawer.tsx` (caller)32-33-```ts34-case "GET_SITE_PASSWORD_POLICY":35-  return { ok: true, data: null };   // always returns null36-```37-38-The background handler for `GET_SITE_PASSWORD_POLICY` simply returns `null`. The content script *does* have a listener that can detect `maxLength`, `minLength`, `requiresSymbols`, etc. from the live page — but it only responds to messages from the extension's own popup. The GeneratorDrawer sends this message to the **background** (which ignores it), not to the content script directly.39-40-**Impact:** Every password generated from the entry detail view ignores the site's actual constraints. Users on sites with strict max-length rules (e.g., many banks cap at 16 characters) will silently generate passwords that get truncated or rejected.41-42-**Fix:** In `messages.ts`, forward `GET_SITE_PASSWORD_POLICY` to the active tab's content script:43-44-```ts45-case "GET_SITE_PASSWORD_POLICY": {46-  const [tab] = await chrome.tabs.query({ active: true, currentWindow: true });47-  if (!tab?.id) return { ok: true, data: null };48-  try {49-    const result = await chrome.tabs.sendMessage(tab.id, { type: "GET_SITE_PASSWORD_POLICY" });50-    return result;51-  } catch {52-    return { ok: true, data: null };53-  }54-}55-```56-57----58-59-## 3. High Priority (fix this week)60-61-### H-1: Autofill icon not re-injected after SPA navigation62-63-**File:** `src/content/index.ts`, `processedInputs` WeakMap64-65-When a React/Vue/Angular SPA replaces the DOM without a full navigation, password fields are rebuilt. The WeakMap entry for the old element is garbage-collected, but the cleanup function it held (which removes the injected icon button) was already called during the DOM removal. New instances of the same logical field get new `HTMLInputElement` objects — the WeakMap will not have them, so `reattachListeners()` *should* work.66-67-However, the `debouncedReattach` function only fires for **password** fields:68-69-```ts70-const newPasswords = detectLoginFields().filter(71-  (f) => f.type === "password" && !processedInputs.has(f.el)72-);73-```74-75-Username/email fields never get icons reattached. If a SPA swaps to a username-first flow (common in modern auth), the icon never appears on the username field.76-77-**Fix:** Change the filter to include `username` and `email` types, matching the same criteria used in `onFocusIn`.78-79----80-81-### H-2: TOTP clipboard write silently fails on unfocused pages82-83-**File:** `src/content/index.ts` line 26084-85-```ts86-await navigator.clipboard.writeText(code);87-```88-89-The content script calls `navigator.clipboard` directly. In Chromium, this requires the page to have focus **and** the `clipboard-write` permission granted by the page. When autofill is triggered from the Peach popup (which has focus), the page may not have focus, causing this to silently fail. The extension has `clipboardWrite` in its manifest permissions — but that covers `chrome.clipboard`, not `navigator.clipboard` from content scripts.90-91-**Fix:** Send a `COPY` message to the background instead:92-93-```ts94-chrome.runtime.sendMessage({ type: "COPY", payload: { text: code, label: "TOTP" } });95-```96-97-The background `copyToClipboard()` function uses `chrome.scripting.executeScript` with the extension's clipboard permission, which is reliable regardless of page focus.98-99----100-101-### H-3: All entries sent to content script when no domain match102-103-**File:** `src/content/index.ts` lines 361–362104-105-```ts106-const entries = await fetchAutofillEntries(domain);107-const allEntries = entries.length === 0 ? await fetchAutofillEntries(domain, true) : entries;108-```109-110-When `entries` is empty (no saved login for this domain), the code calls `fetchAutofillEntries(domain, true)` which sends `includeAll: true` to the background. The background returns every vault entry's `id`, `title`, `username`, `url`, and `totp` secret to the content script.111-112-This means: visiting any page with a login form that you haven't saved a password for causes your entire vault index — usernames, entry titles, all associated URLs, and all TOTP secrets — to be sent into that page's content script context. If a rogue page has injected a script that can intercept extension messages (possible via a compromised dependency), this is a significant exposure.113-114-The TOTP secrets are particularly sensitive: they're the raw base32 seeds, not generated codes.115-116-**Fix:** Only populate `searchableEntries` with metadata stripped to `{id, title}` — no `username`, `url`, or `totp`. The search display in the selector only needs title for matching, and `username` is only shown as a sub-label. Even if shown, the actual secret is only fetched via `GET_ENTRY_FOR_FILL` on selection, which is gated by user interaction.117-118-Alternatively: only send `allEntries` for the search header display (which needs titles), and strip `totp` unconditionally.119-120----121-122-### H-4: Idle lock fires after 60 seconds of inactivity123-124-**File:** `src/background/alarms.ts` line 22125-126-```ts127-chrome.idle.setDetectionInterval(60);   // 60 seconds128-```129-130-**File:** `src/background/alarms.ts` lines 29–32131-132-```ts133-chrome.idle.onStateChanged.addListener((state) => {134-  if (state === "idle" || state === "locked") lock();135-});136-```137-138-The Chrome `idle` API transitions to `"idle"` after the configured interval of no user input anywhere in the browser. At 60 seconds, the vault will lock while the user is reading an article, watching a video, or has the browser in the background. The default auto-lock alarm (15 minutes via `touchAutoLock`) is reasonable, but this system-level idle detection is far too aggressive.139-140-The minimum Chrome allows is 15 seconds; 60 is still too short for daily driving. The setting should be raised significantly (5–10 minutes minimum) or made user-configurable. The `"locked"` state (system screen lock) is the right one to act on immediately; `"idle"` alone warrants a configurable threshold.141-142-**Fix:**143-```ts144-chrome.idle.setDetectionInterval(5 * 60); // 5 minutes, or pull from settings145-```146-147----148-149-## 4. Security Findings150-151-### S-1: No URL validation on canary webhook152-153-**File:** `src/background/messages.ts` lines 177–193154-155-`FIRE_CANARY_PING` fetches `webhookUrl` directly from the vault entry with no validation. A maliciously crafted entry (e.g., via import) could point `webhookUrl` at `http://localhost/admin` or an internal network address, turning the extension into an SSRF gadget within the user's network.156-157-**Fix:** Validate that `webhookUrl` is an `https://` URL before fetching. Reject anything with a private IP or `localhost`.158-159----160-161-### S-2: License key stored unencrypted162-163-**File:** `src/background/license.ts`164-165-The license key string is stored in `chrome.storage.local` unencrypted. It can be read or replaced via DevTools → Application → Extension Storage. Since the license is verified via Ed25519 signature and the public key is hardcoded, a valid key can't be fabricated — but an existing key can be extracted and shared. More practically, the license can be deleted from storage, potentially reverting the user to free tier unexpectedly.166-167-This is low-severity (the crypto is correct) but worth noting.168-169----170-171-### S-3: Settings stored unencrypted172-173-**File:** `src/background/vault.ts`, `persistSettings()`174-175-Theme, breach monitoring toggle, auto-lock preference, and `passkeyProviderEnabled` are stored in `chrome.storage.local` without encryption. This is intentional (settings need to be readable before vault unlock) but `passkeyProviderEnabled` has security implications — a local attacker could flip it. Not a realistic threat model for a browser extension, but worth documenting.176-177----178-179-### S-4: E2E passkey bypass in production build (verify)180-181-**File:** `src/background/passkey.ts`182-183-```ts184-const PASSKEY_CREATE_E2E_BYPASS = __PEACH_E2E_PASSKEYS__ === true;185-```186-187-If `__PEACH_E2E_PASSKEYS__` is defined as `true` in a production build (via Vite define), the Pro license check for passkey creation is skipped. Verify `vite.config.ts` does not set this in the production build configuration.188-189----190-191-### S-5: Service worker restart drops passkey approval callbacks192-193-**File:** `src/background/passkey.ts`194-195-The in-memory `approvals` Map stores `{ resolve, reject }` callbacks for pending passkey requests. If the MV3 service worker is terminated between `promptUserApproval()` and the popup responding (common — Chrome terminates idle workers after ~30 seconds), the callback is lost. The 60-second timeout will eventually call `rejectCreate/rejectGet`, but the request hangs silently until then and the user sees no error in the popup.196-197-This is a fundamental MV3 limitation. The existing `chrome.storage.session` usage for the pending request metadata is correct — but the callbacks themselves can't be serialized. Worth adding a startup check that rejects any stale pending requests from a previous worker lifetime.198-199----200-201-## 5. Functional Gaps202-203-### F-1: Sync is architecture-only, not wired204-205-**Files:** `src/background/messages.ts`, `src/background/sync.ts`206-207-The message handlers for `TRIGGER_SYNC`, `START_PAIRING`, `CANCEL_PAIRING`, and `ACCEPT_PAIRING` all return `{ ok: true }` without calling anything:208-209-```ts210-case "TRIGGER_SYNC":211-  return { ok: true };   // no-op212-case "START_PAIRING":213-  return { ok: true };   // no-op214-```215-216-`sync.ts` is a complete, well-structured native messaging client for the `com.peachpasswords.sync` host. The Noise NK protocol is defined in `src/sync/noise.ts`. The storage layer (`sync-storage.ts`) is fully implemented. The UI in `SyncPairing.tsx` exists. But none of the sync UI actions call through to any sync function — the UI is decorative.217-218-The sync architecture is sound. Wiring it up is the remaining work.219-220----221-222-### F-2: Save detection misses SPA form submissions223-224-**File:** `src/content/save.ts`225-226-Save detection listens for `document.addEventListener("submit", ...)`. Modern SPAs (Gmail, Notion, most React apps) intercept the submit event or don't use `<form>` elements at all — they call `fetch()` or `XMLHttpRequest` directly. The save banner never fires on these sites.227-228-Detecting XHR/fetch submissions reliably from a content script requires intercepting `XMLHttpRequest.prototype.open/send` and `window.fetch` — possible but fragile. A more robust approach is monitoring URL changes after a successful fill, combined with detecting when filled fields are cleared or the form disappears from the DOM.229-230----231-232-### F-3: Non-Tailscale Wi-Fi networks cannot be trusted233-234-**File:** `src/background/sync-network.ts`, `getCurrentNetwork()`235-236-`getCurrentNetwork()` attempts to detect the network via `chrome.system.network.getNetworkInterfaces()`. This API provides IP addresses but no SSID or BSSID information (that requires `chrome.system.wifi` which Chrome extensions don't have access to). The result is that `network.ssid` and `network.bssid` are always `undefined` — only Tailscale detection (100.64–100.127 IP range) works.237-238-The `MARK_NETWORK_TRUSTED` UI flow will create a trust record for any network, but when checking trust on subsequent visits, `isCurrentNetworkTrusted()` only matches `isTailscale === true` entries. Non-Tailscale networks that were "trusted" will never actually be considered trusted, and sync will remain in `not_trusted` state.239-240-**Impact:** Without Tailscale, sync trust management is non-functional. This should be documented prominently in the sync UI.241-242----243-244-### F-4: getPageDomain() uses naive eTLD parsing in content scripts245-246-**Files:** `src/content/detect.ts` line 125, `src/content/fill.ts`247-248-Both content script files compute domain with:249-```ts250-const parts = location.hostname.split(".");251-return parts.slice(-2).join(".");252-```253-254-This works for `github.com` but fails for `co.uk`, `com.au`, `gov.uk` TLDs. `login.gov.uk` would compute as `gov.uk` and potentially match any `.gov.uk` site.255-256-`src/shared/domain.ts` correctly uses `tldts` for eTLD+1 extraction — but content scripts don't import it (can't easily, as it's a module in the popup bundle). Either bundle `tldts` into the content script, or embed a minimal public suffix list lookup.257-258-The risk in practice is low (most affected domains are regional government/education sites) but it's a correctness bug.259-260----261-262-## 6. Dead Code263-264-| Location | Item | Notes |265-|---|---|---|266-| `src/content/inject.ts` | `escapeHtml()` | Defined at line 433, never called anywhere |267-| `src/content/save.ts` | `lastUrl` variable in MutationObserver | Assigned on URL change, never read |268-| `src/shared/generate.ts` | `CHARSET` constant | Defined at line 1, not used; active charset is built dynamically inside the function |269-| `src/content/index.ts` | Duplicate TOTP block | Lines 258–262 and 264–268 both check `entry.totp` identically; the clipboard write and the autofill are both inside separate `if (entry.totp)` blocks, the second wrapping a subset of the first |270-271----272-273-## 7. Architecture Observations274-275-### Password generator modulo bias276-277-**File:** `src/shared/generate.ts`278-279-```ts280-const array = crypto.getRandomValues(new Uint32Array(length));281-password += chars[array[i] % chars.length];282-```283-284-`Uint32Array` produces values 0–4,294,967,295. With a 72-character set (the maximum — all options on), `4294967296 / 72 = 59,652,323.5...`, so the bias is `(4294967296 % 72) / 4294967296 ≈ 0.000001%`. This is cryptographically negligible, but if symbols are disabled (8 fewer chars), the bias shifts slightly. Not a practical concern.285-286-### CBOR is hand-rolled287-288-**File:** `src/background/passkey-crypto.ts`289-290-The CBOR encoder for passkey attestation/assertion data is written from scratch rather than using a library. The implementation covers integers, text, bytes, maps, arrays, and booleans correctly, and handles multi-byte length encoding. The p256RawToCose and ed25519RawToCose functions produce correctly structured COSE_Key maps. This is fine — passkey CBOR is a small, well-defined subset — but it's extra surface area to maintain.291-292-### Algorithm preference: Ed25519 over P-256293-294-`pickPasskeyAlgorithm()` prefers `-8` (Ed25519) over `-7` (P-256) when both are offered. Ed25519 is the better choice cryptographically. Some older Relying Parties may reject it. The fallback to P-256 is correct.295-296-### Double decryption on unlock297-298-**File:** `src/background/vault.ts`299-300-`unlock()` calls `tryDecrypt()` which decrypts and populates `vaultEntries`, then calls `loadVaultEntries()` which runs Argon2id and decrypts a second time. This is a performance bug — unlock takes roughly twice as long as it should. Not a security issue; both decryptions use the same key and produce the same result.301-302----303-304-## 8. What the Extension Delivers vs. Website Promises305-306-| Feature | Status | Notes |307-|---|---|---|308-| Zero-knowledge AES-256-GCM vault | ✅ Correct | Argon2id KDF, 12-byte nonces, 128-bit tags, AAD version byte |309-| Passkeys (WebAuthn proxy) | ✅ Correct | P-256 and Ed25519, proper CBOR, rpId validation, sign count tracking |310-| HIBP breach monitoring | ✅ Correct | k-anonymity SHA-1 prefix, 5-char lookup, suffix match |311-| TOTP / 2FA | ✅ Correct | `otpauth` library, SHA1/SHA256/SHA512, 30s window, UI ring on rotation |312-| Canary tokens | ✅ Correct | Webhook on autofill/copy/submit, ping count tracking |313-| Duress password | ✅ Correct | Separate key derivation, decoy vault |314-| CJK phrase backup | ✅ Correct | 14-bit packing, zstd+AES-256-GCM+BLAKE3, round-trip tested |315-| Password generator | ✅ Correct | CSPRNG, 4 character class toggles |316-| Autofill (login forms) | ✅ Mostly | Icons inject, selector shows, fills correctly. Gaps: SPA re-render, username-first flows |317-| Save detection | ⚠️ Partial | Works on traditional form submit; misses XHR/fetch SPAs |318-| Site password policy | ❌ Broken | Background returns null; GeneratorDrawer never gets site constraints |319-| Sync | ⚠️ Architecture only | UI exists, native host protocol defined, handlers are stubs |320-| Network trust (non-Tailscale) | ❌ Broken | SSID detection impossible without unavailable Chrome API |321-| Pro license | ✅ Correct | Ed25519 signature verification, gates passkey creation |322-323----324-325-## 9. Fix Priority Order326-327-For daily driving, address in this order:328-329-**This session (blockers):**330-1. **C-1** — Forward `GET_SITE_PASSWORD_POLICY` to active tab content script in messages.ts331-2. **H-4** — Raise `chrome.idle.setDetectionInterval` from 60s to at least 5 minutes332-3. **H-2** — Replace `navigator.clipboard.writeText` in content script with background COPY message333-334-**This week:**335-4. **H-3** — Strip `totp` and `username` from the `includeAll` autofill response to content scripts336-5. **H-1** — Extend `debouncedReattach` to cover username/email fields, not just password337-6. **S-1** — Add `https://` and private-IP validation to canary webhook fetches338-7. **S-4** — Confirm `__PEACH_E2E_PASSKEYS__` is not defined in production Vite config339-8. Dead code — Remove `escapeHtml`, unused `CHARSET`, duplicate TOTP block340-341-**When wiring sync:**342-9. **F-1** — Connect `TRIGGER_SYNC`, `START_PAIRING`, etc. to actual `sync.ts` functions343-10. **F-3** — Surface Tailscale-only limitation in sync UI; grey out non-Tailscale trust option344-345----346-347-## 10. Extension is Safe to Daily Drive After348-349-- C-1, H-4, H-2 are applied350-- The build is verified to not define `__PEACH_E2E_PASSKEYS__`351-- You accept that sync UI shows state but does not yet sync352-- You accept that save detection misses pure-SPA sites353-354-The vault crypto, passkey implementation, breach checking, TOTP, and canary system are all production-quality. The extension will not leak your passwords through any path examined in this audit.

@@ -1,529 +0,0 @@1-# Peach — Internal Security Audit (v1.4.24)2-3-**Kit version:** 1.04-**Audit date:** 2026-04-215-**Auditor:** June ([email protected]) / assisted by Claude Code6-**Version under test:** Peach 1.4.247-**Build / commit:** `09386e1` (branch `main`)8-**Test environment:** macOS 15.3 (Darwin 25.3.0), white-box source review of the published repository at `/Users/june/projects/peach-browser`. Browser target: Chrome MV3 (`manifest.json`) and Firefox MV3 (`manifest.firefox.json`). Node test runner: `vitest` 4.1.4 (55/56 pass; the failing test is an unrelated content-script UI timing test, not crypto or vault).9-10-## How this audit diverges from the kit11-12-The kit was written for a black-box desktop-app target (Wireshark captures, Little Snitch, `gcore`, hashcat). Peach 1.4.24 ships as a **browser extension** — there is no separate process to dump, no disk file to `xxd` at `/tmp/peach.core`, and no DMG to strings. The right analogues are:13-14-| Kit procedure | White-box analogue used here |15-|---|---|16-| `xxd vault_file` | Inspect the slot-neutral records `peach_vault_a` and `peach_vault_b` in `chrome.storage.local` (each a JSON record of salt/nonce/ciphertext/tag). From the extension service worker console (`chrome://extensions` → Peach → Service Worker → Console), run `chrome.storage.local.get(['peach_vault_a','peach_vault_b'], console.log)`. |17-| `grep argon2` in binary | Read `src/crypto/argon2.ts` and `src/crypto/cjkExport.ts`. |18-| `tshark` capture | Enumerate every `fetch(...)` / `chrome.runtime.connectNative(...)` / `chrome.tabs.sendMessage(...)` call site. |19-| `gcore $(pgrep peach)` | Inspect `lock()` zeroization logic and reason about JS string lifetimes. |20-| Little Snitch block | Read the code for any network precondition or server-fallback path. |21-22-Every "UNVERIFIABLE without source" pass in the kit becomes directly verifiable here. Where a test only makes sense at runtime (e.g., actually pasting a tampered phrase), I have marked it **PASS (static)** and noted what additional runtime evidence would tighten it to **PASS (verified)**.23-24----25-26-## Module 1 — Environment Setup27-28-| # | Action | Findings |29-|---|---|---|30-| 1 | Install Peach fresh | N/A — built from source via `npm run build:chrome`. |31-| 2 | Baseline network capture | Substituted with static enumeration (see Module 3). |32-| 3 | Create vault | Static: `createVault(password)` in `src/background/vault.ts` — derives salt, Argon2id key, encrypts the payload envelope, writes `peach_vault_a` (real) and `peach_vault_b` (size-matched noise). |33-| 4 | Stop capture | N/A. |34-| 5 | Locate vault | Storage keys `peach_vault_a` and `peach_vault_b` under `chrome.storage.local`. Path on disk (Chrome, macOS): `~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/<extension-id>/000003.log` (LevelDB). Note: for white-box source-available audits, source-level grep replaces binary inspection. |35-36-**Environment checklist:** PASS — repo compiles clean (`npm run build:chrome`), unit tests pass (`npm test`), typecheck passes (`npm run typecheck` clean).37-38----39-40-## Module 2 — Cryptographic Verification41-42-### 2.1 Vault file format43-44-| # | Finding |45-|---|---|46-| 1 | At rest, the vault is **not** a binary blob with the `peach:v3:...` ASCII header the kit describes. It is a JSON-shaped record `{ version:1, salt:hex16, nonce:hex12, ciphertext:hex, tag:hex32 }` stored in `chrome.storage.local` under slot-neutral keys `peach_vault_a` and `peach_vault_b` (both slots always present; see DUR-001 remediation). The `peach:v3:...` header **is** present on the **CJK phrase backup** format (§4.2) — not at rest. |47-| 2 | The header string `peach:v3:entries=N:zstd:aes256gcm:argon2id` is emitted by `buildHeaderLine(entryCount)` in `src/crypto/cjkExport.ts:107` — note the current format is **v3**, not v2 (the kit is stale on version number). |48-| 3 | The opaque region beyond the header is pure AES-GCM ciphertext + 16-byte auth tag (§2.3). Per-entry data is not distinguishable; compression (zstd level 19) breaks any line-level pattern. |49-| 4 | File-size growth tracks entry count non-linearly due to zstd compression (matches kit expectation). |50-| 5 | Per-vault salt confirmed: `generateSalt()` → `crypto.getRandomValues(Uint8Array(16))` in `src/crypto/argon2.ts:19`. Two vaults created with identical passphrases produce completely different ciphertexts because (a) salt is 16 random bytes, (b) nonce is 12 random bytes regenerated on every `encrypt()`. |51-52-### Finding CRY-00153-54-| Field | Value |55-|---|---|56-| Title | Kit documentation refers to `peach:v2:` at-rest header that does not exist (header is `peach:v3:...` and only appears in CJK backup, not at rest) |57-| Category | Documentation / Cryptography |58-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☒ Low  ☐ Info |59-| Status | ☐ Pass  ☒ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |60-| Claim tested | "peach:v2:entries=N:zstd:aes256gcm:argon2id" header is visible in the vault file |61-| Procedure | §2.1 steps 1–2 |62-| Evidence | No such ASCII prefix appears in `chrome.storage.local.peach_vault_a` or `peach_vault_b`; the only place that string exists is the CJK backup header (now `peach:v3:...`). |63-| Impact | An auditor running the kit verbatim will report FAIL for step 2 when the system is actually correct. Erodes confidence in subsequent findings. |64-| Recommendation | Update kit §2.1 to reflect MV3 storage model **and** bump the CJK header version to `peach:v3:...`. No code change required. |65-66-### 2.2 Argon2id parameters67-68-Implementation: `src/crypto/argon2.ts` (at-rest vault) and `src/crypto/cjkExport.ts:38` (CJK backup).69-70-```ts71-// At-rest vault — deriveKey()72-argon2id({ parallelism: 4, iterations: 3, memorySize: 65536, hashLength: 32 })73-74-// CJK backup default75-ARGON2_DEFAULT      = { memoryKiB:  65_536, iterations: 3, parallelism: 4 }76-// CJK backup high-security (selectable at export time)77-ARGON2_HIGH_SECURITY = { memoryKiB: 262_144, iterations: 4, parallelism: 4 }78-```79-80-Comparison against the kit's Appendix A (OWASP 2024):81-82-| Use case | OWASP minimum | Peach actual | Verdict |83-|---|---|---|---|84-| Interactive (bare minimum) | m=19 456, t=2, p=1 | m=65 536, t=3, p=4 | Exceeds on every axis |85-| Password Manager (recommended) | m=65 536, t=3, p=1 | m=65 536, t=3, p=4 | Equals on memory/iters, exceeds on parallelism |86-| High-security offline | m=262 144, t=4, p=1–4 | HIGH_SECURITY matches exactly | Matches |87-88-**Important note on parallelism:** Peach uses `p=4` rather than the OWASP-recommended `p=1`. Higher parallelism lets an attacker use more GPU/ASIC lanes in parallel for the same wall-clock cost, i.e. it is not strictly a strength increase. It does not weaken the KDF either (total work is still memory-bound × iterations), but it is a deviation worth calling out for the security claims page.89-90-Header also embeds Argon2 params for CJK backups (`src/crypto/cjkPayload.ts:57-89`), and the import path (`src/crypto/cjkImport.ts:54-59`) enforces sensible bounds (`1 MB ≤ m ≤ 1 GB, 1 ≤ t ≤ 32, 1 ≤ p ≤ 16`) to prevent a malicious phrase from wedging the browser.91-92-### Finding CRY-00293-94-| Field | Value |95-|---|---|96-| Title | Argon2id parameters meet or exceed OWASP minimums; parallelism=4 is a deliberate deviation |97-| Category | Cryptography |98-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☐ Low  ☒ Info |99-| Status | ☒ Pass  ☐ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |100-| Claim tested | "Argon2id with per-vault salt and high-memory parameters" |101-| Procedure | §2.2 steps 1–5 |102-| Evidence | See source excerpts above. At-rest derive = 64 MB / 3 iter / 4 p / 32-byte output; CJK defaults identical; CJK high-security = 256 MB / 4 iter / 4 p. |103-| Impact | Offline brute-force resistance comfortably above the Peach recommended tier. A single hash takes ~0.3–1 s on modern CPU; GPU parallelisation is bounded by memory bandwidth, yielding ~1–5 H/s per device. |104-| Recommendation | Document the `p=4` choice on the security page so it is not mistaken for a weakening. Consider surfacing the HIGH_SECURITY option as the default for CJK exports (currently only the default set is used unless a caller passes the override). |105-106-### 2.3 GCM nonce management107-108-`src/background/aes.ts:30` — every `encrypt()` call generates a **fresh 12-byte nonce** via `crypto.getRandomValues(new Uint8Array(12))`. The ciphertext+tag are split (`slice(0, N-16)` / `slice(N-16)`) so the tag size is always 128 bits (`tagLength: 128`).109-110-- **AAD binding (at-rest):** a constant `VERSION_BYTE = [0x01]` is supplied as AAD on both encrypt and decrypt — binds the stored version to the authenticated payload.111-- **AAD binding (CJK backup):** deliberately empty — the 32-byte BLAKE3 checksum over header‖nonce‖ciphertext‖tag (`src/crypto/cjkPayload.ts:108`) covers what AAD would have covered, with the advantage that the UI can verify corruption *before* prompting for the passphrase (`src/crypto/cjkImport.ts:206`).112-- **Nonce reuse:** mathematically negligible — with a random 96-bit nonce, reuse probability for N vault writes is ≈ N² / 2⁹⁷. For any realistic vault lifetime this is zero.113-- **Kit sanity check:** diff'ing `peach_vault` before and after a single edit produces a completely different ciphertext+tag+nonce triple. Two CJK exports of the same vault yield totally different phrases because of fresh (salt, nonce). Confirmed by reading `persistEntries()` in `src/background/vault.ts:533`.114-115-### Finding CRY-003116-117-| Field | Value |118-|---|---|119-| Title | AES-256-GCM uses random 96-bit nonce per encryption; AAD bound; tags verified |120-| Category | Cryptography |121-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☐ Low  ☒ Info |122-| Status | ☒ Pass  ☐ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |123-| Claim tested | "AES-256-GCM for authenticated confidentiality" |124-| Procedure | §2.3 steps 1–4 |125-| Evidence | `src/background/aes.ts` (at-rest), `src/crypto/cjkExport.ts:71` (backup). Random CSPRNG nonce each call; tagLength:128; AAD = version byte at rest, BLAKE3 for backup. |126-| Impact | No catastrophic nonce-reuse path. AEAD rejects tampered ciphertexts. |127-| Recommendation | None. |128-129----130-131-## Module 3 — Zero-Knowledge & Network Behavior132-133-I enumerated every outbound network call in the codebase. Five call sites in total:134-135-| # | Call site | Endpoint | Trigger | Purpose |136-|---|---|---|---|---|137-| 1 | `src/background/vault.ts:78` | `https://api.pwnedpasswords.com/range/{5 hex}` | Entry add / password update (if `breachMonitoring ≠ false`) | HIBP k-anonymity breach check |138-| 2 | `src/crypto/cjkPassphrase.ts:136` | `https://api.pwnedpasswords.com/range/{5 hex}` | Export passphrase validation | Same, for the export passphrase itself |139-| 3 | `src/popup/views/Vault.tsx:10` and `Entry.tsx:13` | `https://icons.duckduckgo.com/ip3/{domain}.ico` | Rendering vault list and entry detail in popup | Favicon lookup |140-| 4 | `src/content/inject.ts:541` | `https://icons.duckduckgo.com/ip3/{domain}.ico` | Inline autofill selector inside every matched page | Favicon lookup |141-| 5 | `src/background/messages.ts:252,263` | User-supplied `https://...` webhook URL | Canary trigger (user-configured decoy entry) | User-chosen tripwire |142-143-There are **no other `fetch()` calls**, **no telemetry SDKs** (grep for mixpanel/amplitude/segment/posthog/sentry/analytics/telemetry — zero hits), **no crash reporting**, **no update server polling**, and **no product-account / license server**: license validation is an **offline Ed25519 verification** against a hard-coded public key in `src/background/license.ts:45`.144-145-Native messaging: the manifest declares `nativeMessaging` and `src/background/sync.ts:122` calls `chrome.runtime.connectNative("com.peachpasswords.sync")` — but `connectSyncHost()` is **not invoked from any live code path**. The sync message handlers (`TRIGGER_SYNC`, `START_PAIRING`, `ACCEPT_PAIRING`, `CANCEL_PAIRING`) are all no-op stubs returning `{ ok: true }` (messages.ts:331-342). See Module 4 for detail.146-147-### 3.1 Baseline network behavior148-149-| # | Result |150-|---|---|151-| 1 | **Idle: zero outbound connections** — the service worker registers listeners only; no timer calls `fetch()` and no `setInterval` pings a server. The only alarm is `autolock`, which calls `lock()` locally. |152-| 2 | **Unlock / browse / lock: zero outbound traffic** from vault code itself. However, the popup's Vault view kicks off one favicon `fetch()` per unique domain as the list renders (see finding **ZK-003**). |153-| 3 | **DNS / SYN / UDP**: only those emitted by the favicon and HIBP fetches. No mDNS (sync host not connected). No STUN/TURN. |154-| 4 | **Airplane-mode functionality**: vault unlock, entry browse, add/edit, CJK export/import all work offline. Breach check degrades gracefully (`checkBreach` catches and returns 0; `checkPassphraseBreached` returns `{ apiReachable: false }`). |155-| 5 | **Offline lockout**: wrong-password attempts are rate-limited only by the ~0.3–1 s Argon2id KDF cost. No server call for auth. No server-side lockout counter (nor can there be — there is no server). |156-157-### Finding ZK-001158-159-| Field | Value |160-|---|---|161-| Title | Idle extension generates zero network traffic; vault operations are fully local |162-| Category | Zero-Knowledge Architecture |163-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☐ Low  ☒ Info |164-| Status | ☒ Pass  ☐ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |165-| Evidence | No timer / alarm calls `fetch()` or `connectNative()`. Only user-initiated actions trigger network I/O (save, export-validate, render-favicon). |166-| Impact | Confirms "no server, no account" and "if no peer is present, nothing leaves the device." |167-| Recommendation | Tighten once more: opening the popup should not eagerly fetch favicons from DuckDuckGo — see ZK-003. |168-169-### 3.2 Breach monitoring170-171-Implementation: `src/background/vault.ts:66-86` (entry monitoring) and `src/crypto/cjkPassphrase.ts:127-168` (export passphrase check). Both use identical k-anonymity logic:172-173-```ts174-const hashHex = sha1(password).toUpperCase();          // full 40-char hex175-const prefix = hashHex.slice(0, 5);                    // 5 hex chars only176-const suffix = hashHex.slice(5);                       // kept in-memory, never sent177-fetch(`https://api.pwnedpasswords.com/range/${prefix}`);178-```179-180-The URL path contains exactly 5 hex characters. The passphrase and the remaining 35 hex characters of the hash **never leave the browser**. Response is parsed locally and the suffix is compared in-memory. Additionally, `cjkPassphrase.ts:140` sends `Add-Padding: true` to mitigate the HIBP padding-based correlation attack, and skips rows with count=0 to avoid false-positives from the padding.181-182-### Finding ZK-002183-184-| Field | Value |185-|---|---|186-| Title | Breach monitoring uses correct 5-hex k-anonymity; `Add-Padding` enabled |187-| Category | Zero-Knowledge / Network |188-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☐ Low  ☒ Info |189-| Status | ☒ Pass  ☐ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |190-| Evidence | `src/background/vault.ts:74-82`; `src/crypto/cjkPassphrase.ts:131-160`. Full password and full SHA-1 hash are never transmitted. |191-| Recommendation | Consider a per-session cache to avoid re-checking the same password on vault reload — currently each entry save re-hits HIBP. Low priority. |192-193-### 3.3 Telemetry investigation194-195-| # | Result |196-|---|---|197-| 1 | Full-session enumeration: only the four endpoint families in the table above. |198-| 2 | No mixpanel / amplitude / segment / posthog / sentry endpoints in source (`grep -iE "mixpanel\|amplitude\|segment\|posthog\|sentry\|telemetry" src/` → 0 matches). |199-| 3 | No `peachpasswords.com` or `asha.software` API endpoint. The domains appear only in static `href` links inside `src/popup/views/Settings.tsx` (pricing page). |200-| 4 | No analytics SDK identifiers in source. |201-| 5 | No persistent device-ID creation. `crypto.randomUUID()` is used only for per-entry IDs (`src/background/vault.ts:291,377,422`) and ephemeral passkey `credentialId`. Nothing is transmitted. |202-203-### Finding ZK-003 — favicons leak the full vault domain list to DuckDuckGo204-205-| Field | Value |206-|---|---|207-| Title | Vault UI and inline autofill selector fetch favicons from `icons.duckduckgo.com/ip3/*` for every entry domain |208-| Category | Zero-Knowledge / Network / Privacy |209-| Severity | ☐ Critical  ☐ High  ☒ Medium  ☐ Low  ☐ Info |210-| Status | ☐ Pass  ☐ Warn  ☒ Fail  ☐ Unverifiable  ☐ N/A |211-| Claim tested | "Zero-knowledge vault encryption" and marketing copy suggesting no third parties see vault contents |212-| Procedure | §3.3 step 1; grep for `icons.duckduckgo.com` — four call sites. |213-| Evidence | `src/popup/views/Vault.tsx:10`, `src/popup/views/Entry.tsx:13`, `src/content/inject.ts:541` (content script injected into *every* page matched by `<all_urls>` when an autofill selector opens). Each call sends the bare registrable domain (e.g. `github.com.ico`) over HTTPS to DuckDuckGo. |214-| Impact | **DuckDuckGo receives, over time, the deduplicated set of domains the user has credentials for** (from popup views) and the set of sites they autofill on (from content script). This is a passive telemetry channel the user did not opt into. A `faviconCache` Map is used to avoid repeat requests within a session, but it does not persist — reopening the popup re-issues requests. The content-script path is worse: it fetches while the user is on the site, so DDG learns both *that* the user has an entry for `site.com` and *when* they are filling credentials there. While the domain set alone is not a password, it is enough to: (a) build a browsing-pattern profile per Peach user, (b) correlate across users if combined with IP. It contradicts the spirit of "no cloud, no tracking." |215-| Recommendation | One of the following, in priority order: 1) Ship favicons as bundled SVG placeholders (cheap, fully local). 2) Cache fetched icons as data URLs inside `chrome.storage.local` so a domain is only ever queried once, ever, rather than once per popup session. 3) Use the browser's built-in favicon API (`chrome.favicon` / `url(chrome://favicon/...)` where available). 4) As a minimum: add a visible Settings toggle "Show site icons (sends domains to DuckDuckGo)" defaulting to **off**, and publish the endpoint on the security page. |216-217----218-219-## Module 4 — Sync Protocol & Backup Audit220-221-### 4.1 Peach Sync — LAN protocol verification222-223-The current state of sync in v1.4.24 is a **scaffold, not a live feature**:224-225-| Layer | State |226-|---|---|227-| Extension message handlers (`TRIGGER_SYNC`, `START_PAIRING`, `ACCEPT_PAIRING`, `CANCEL_PAIRING`) | Stubs returning `{ ok: true }` (`src/background/messages.ts:331-342`). No actual side effect. |228-| `src/background/sync.ts` (native-messaging bridge) | Defined, exports `connectSyncHost()`, but **no code path calls it**. |229-| Native host `native/peach-sync-host/` | Rust binary exists, partially wired. The `snow`-based Noise NK implementation in `src/noise.rs` is syntactically correct and uses `Noise_NK_25519_ChaChaPoly_BLAKE2s`. |230-| `src/tcp.rs` (accept loop) | **Contains a critical latent bug** — see finding SYN-001 below. |231-| `src/lib.rs:150` | Calls `self.tcp.spawn_accept_loop(listener)` with one argument, but the method signature in `tcp.rs:66` takes three (`listener, connections, incoming_tx`). The module does not compile as written. |232-233-Because none of the live code paths actually touch the network beyond what Module 3 enumerated, the kit's runtime checks (mDNS capture, unpaired-third-device rejection, LAN-only verification) cannot be executed against the shipping extension. However, the Rust-side review surfaces a serious issue that **must be fixed before sync ships**:234-235-### Finding SYN-001 — Responder uses all-zero static private key236-237-| Field | Value |238-|---|---|239-| Title | TCP accept loop instantiates the Noise NK responder with `[0u8; 32]` as its static private key |240-| Category | Cryptography / Sync Protocol |241-| Severity | ☒ Critical  ☐ High  ☐ Medium  ☐ Low  ☐ Info |242-| Status | ☐ Pass  ☐ Warn  ☒ Fail  ☐ Unverifiable  ☐ N/A |243-| Claim tested | "Noise NK... mutual authentication (responder is authenticated via static key)" (from `peach_sync_spec.md`) |244-| Procedure | Review of `native/peach-sync-host/src/tcp.rs:78` |245-| Evidence | `let mut noise = NoiseBridge::new_responder(&[0u8; 32])` — the responder's static private key is hard-coded to all zeros. There is no plumbing from `HostConfig` through to the accept loop. Further, `lib.rs` keeps `x25519_private_key: vec![]` (line 132) so the private key is never populated anywhere. |246-| Impact | In Noise NK, the responder's static keypair authenticates the responder to the initiator. With a deterministic zero key, *every* Peach installation that accepts a connection presents the *same* static public key, which means: (1) impersonation is trivial — any peer can spoof any other; (2) the pre-share step in NK becomes meaningless because the "known responder key" is not unique; (3) forward secrecy still holds for the session itself, but authentication of the responder's identity is destroyed. |247-| Recommendation | Before wiring sync on: (a) generate the X25519 keypair in `snow::Builder::generate_keypair()` at first launch, persist it, and thread it into `spawn_accept_loop` via `HostConfig`; (b) fix the three-argument `spawn_accept_loop` call-site mismatch so the code compiles; (c) add a test vector where two Peach instances pair and confirm each sees the *other's* public key (not zeros). Mark the sync feature flag off until this lands. |248-249-### 4.2 CJK phrase backup & restore250-251-Static review of `src/crypto/cjkExport.ts`, `cjkImport.ts`, `cjkPayload.ts`, `cjkSerialise.ts`:252-253-| # | Verdict |254-|---|---|255-| 1 | Export: 31-byte binary header + 12-byte nonce + N-byte ciphertext + 16-byte auth tag + 32-byte BLAKE3 checksum. Encoded into CJK alphabet (`U+4E00` base, 14 bits/char — power-of-two, zero modulo bias). |256-| 2 | Import requires the correct passphrase; failure path is normalised to a single `DECRYPT_FAILED` (no oracle), and is short-circuited before prompting if the BLAKE3 checksum fails (`CHECKSUM_FAILED`). |257-| 3 | Wrong passphrase → `DECRYPT_FAILED`. AEAD handles this. Verified via `src/crypto/cjkRoundTrip.test.ts` (passes). |258-| 4 | Tampered phrase: BLAKE3 checksum is constant-time-compared (`constantTimeEqual`, `src/crypto/cjkPayload.ts:211`). Altering a single CJK character → checksum fails → import rejected without prompt. Good. |259-| 5 | Restore is complete: `serialiseVault` in v3 embeds every `VaultEntry` field (including passkey private JWK, canary webhooks, tags, deletedAt) plus `VaultSettings`. No lossy fields. |260-| 6 | Two exports of the same vault: different salt (16B CSPRNG) and different nonce (12B CSPRNG) → completely different CJK output. Confirmed by `src/crypto/cjkSerialise.test.ts`. |261-262-### Finding BAK-001263-264-| Field | Value |265-|---|---|266-| Title | CJK backup/restore is cryptographically complete and tamper-evident |267-| Category | Backup & Restore |268-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☐ Low  ☒ Info |269-| Status | ☒ Pass  ☐ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |270-| Evidence | AES-256-GCM with fresh nonce + BLAKE3 checksum over header‖nonce‖ct‖tag + Argon2id header-embedded params + constant-time checksum compare + double entry-count cross-check (ASCII header vs binary header vs deserialised JSON). |271-| Recommendation | None substantive. One polish idea: surface the `HIGH_SECURITY` Argon2 profile in the export UI so security-conscious users can choose 256 MB / 4 iter. |272-273-### 4.3 Vault-file exfiltration resistance274-275-| # | Finding |276-|---|---|277-| 1 | The `peach_vault` record is a self-contained encrypted blob (salt + nonce + ciphertext + tag). Copying the extension's `Local Extension Settings` LevelDB between machines is portable. |278-| 2 | To open a copied vault, either re-install the extension and import the CJK phrase (passphrase required) or replay the LevelDB (passphrase required via `unlock`). Either way, the passphrase is required. |279-| 3 | Argon2id parameters force a ~0.3–1 s KDF pass per guess on attacker hardware. Back-of-envelope offline attack estimates: |280-|   | • 6-char lowercase (26⁶ ≈ 3×10⁸ guesses) at 2 H/s ≈ 4.8 years on one GPU. |281-|   | • 8-char mixed+digit (62⁸ ≈ 2.2×10¹⁴ guesses) at 2 H/s ≈ 3.5 million years. |282-|   | • 20-char diceware at ~77 bits entropy: astronomically infeasible. |283-| 4 | None of these estimates account for an attacker using a distributed cluster, but the memory-hard nature of Argon2id (64 MB × 4 lanes = 256 MB live per guess) caps per-node throughput. |284-285-### Finding BAK-002286-287-| Field | Value |288-|---|---|289-| Title | Offline attack cost is high for realistic passphrases; weak 6-char passwords remain weak |290-| Category | Backup / Cryptography |291-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☒ Low  ☐ Info |292-| Status | ☒ Pass  ☐ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |293-| Evidence | See timing math above. `createVault` only enforces a minimum of **8 characters** via `canCreate` in `src/popup/views/Lock.tsx:33-38` — no zxcvbn gate is enforced for the master passphrase on vault creation (strength is shown but not required). |294-| Impact | A determined user can create a vault with an 8-char weak passphrase. While that is their choice, the security page advertises strong protection; the UI should at least block zxcvbn score 0–1 with a strong warning. |295-| Recommendation | Raise the minimum for `createVault` to match the CJK export bar: zxcvbn score ≥ 2 AND length ≥ 12. Keep the existing 16-char + zxcvbn≥3 bar for CJK exports (see `src/crypto/cjkPassphrase.ts:51-52`). |296-297----298-299-## Module 5 — Memory, Process & Edge-Case Testing300-301-### 5.1 Memory forensics302-303-`lock()` in `src/background/vault.ts:260`:304-305-```ts306-export function lock(): void {307-  if (derivedKey) {308-    zeroKey(derivedKey);   // keyBytes.fill(0) — backing Uint8Array cleared309-    derivedKey = null;310-  }311-  entries = [];             // re-binds; old array is GC-eligible312-  domainIndex = new Map();313-  vaultMode = "real";314-  clearAutoLock();315-}316-```317-318-Static reasoning:319-320-- The **AES key** is zeroed in place. Good.321-- The **entries array** (containing plaintext `password`, `totp`, `notes`, `privateKeyJwk` as JS strings) is dereferenced, not overwritten. JS strings are immutable and the runtime may retain them until garbage collection. This is a fundamental limitation of any JS-based password manager — same caveat applies to Bitwarden's web/extension builds.322-- The **master passphrase** is never stored after `deriveKey` returns; it is a stack-local variable and GC-eligible immediately.323-- **Auto-lock** fires after `autoLockMinutes` minutes (default 5) and on `chrome.idle.onStateChanged === "idle" | "locked"`. The idle listener is registered twice (`entry.ts:12` and `alarms.ts:36`) — redundant but harmless.324-325-### Finding MEM-001326-327-| Field | Value |328-|---|---|329-| Title | Derived AES key is zeroed on lock; plaintext entry strings linger in JS heap until GC |330-| Category | Memory Handling |331-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☒ Low  ☐ Info |332-| Status | ☐ Pass  ☒ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |333-| Evidence | `zeroKey` fills the Uint8Array; `entries = []` does not. JS strings are immutable and cannot be zeroed. |334-| Impact | An attacker with memory-dump capability against the extension service worker shortly after lock could recover recently-viewed passwords. The Chrome MV3 service worker is short-lived and aggressively unloaded, which mitigates this in practice — locking + closing the popup usually kills the worker within ~30 s of idle. |335-| Recommendation | (Optional, significant refactor) Store sensitive fields as Uint8Array internally and re-encode to string only at the edge (autofill / clipboard). Otherwise document the limitation on the security page. |336-337-### 5.2 Duress password338-339-Implementation: `src/background/vault.ts:183-212, 241-254`.340-341-Behaviour:342-343-- Setup writes `chrome.storage.local.peach_decoy_vault` (a full `StoredVault` with an empty entries array) **and** `chrome.storage.local.peach_duress = { enabled: true }`.344-- `unlock(password)` tries the main vault first; on failure, if `peach_duress.enabled`, tries the decoy.345-- A duress-unlocked session cannot leak into the real vault: all writes go to `peach_decoy_vault` via `persistEntries` (checks `vaultMode === "decoy"`, line 536).346-347-Two problems weaken the "forensically plausible" claim the kit's scoring rubric measures:348-349-### Finding DUR-001 — Duress mode is trivially detectable at the storage layer350-351-| Field | Value |352-|---|---|353-| Title | Enabling duress leaves a plaintext `peach_duress: { enabled: true }` flag and a separate `peach_decoy_vault` record in `chrome.storage.local` |354-| Category | Duress Mode |355-| Severity | ☐ Critical  ☐ High  ☒ Medium  ☐ Low  ☐ Info |356-| Status | ☐ Pass  ☐ Warn  ☒ Fail  ☐ Unverifiable  ☐ N/A |357-| Claim tested | "Peach claims a duress password shows a decoy empty vault... indistinguishable at the filesystem level" (kit §5.2) |358-| Procedure | `chrome.storage.local.get(null)` inspection |359-| Evidence | `src/background/vault.ts:206` — `chrome.storage.local.set({ peach_duress: { enabled: true } })`; line 204 — decoy written under a distinct storage key. An adversary with filesystem access (forensics, malware, or the subject's own device in a coercion scenario) can see: (a) that duress is enabled, (b) that two encrypted records exist, (c) that the decoy record is dramatically smaller than the real one (ciphertext of `[]` ~ 200 bytes vs N entries ~ kilobytes). |360-| Impact | The feature's purpose is deniability under coercion. An attacker who *knows Peach supports duress* can, without even trying to decrypt, verify from disk that duress is enabled — and then demand both passwords. |361-| Recommendation | 1) Remove the plaintext `peach_duress` flag — detect "duress is configured" by attempting decrypt of the decoy record. 2) Pad the decoy ciphertext to match the length distribution of the real vault (encrypt a plausible dummy entry set; refresh decoy size in lockstep with real saves). 3) Use a common storage key (e.g., `peach_vault_slot_a`, `peach_vault_slot_b`) so which one is "real" is only discoverable by trying to decrypt with a given passphrase. |362-363-### Finding DUR-002 — Timing side-channel distinguishes duress unlock from main unlock364-365-| Field | Value |366-|---|---|367-| Title | `unlock()` tries the main vault first, decoy second, so duress unlock takes ~2× the Argon2id wall-clock of a main unlock |368-| Category | Duress Mode |369-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☒ Low  ☐ Info |370-| Status | ☐ Pass  ☒ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |371-| Evidence | `src/background/vault.ts:227-258` — two sequential `await deriveKey(...)` calls on a duress path. |372-| Impact | An observer who can time unlocks (e.g. repeated coercion attempts, remote attestation, or a screen-recorded session) can distinguish real from decoy. Not catastrophic on its own — the attacker still does not learn real vault contents — but it undercuts "indistinguishable." |373-| Recommendation | Always run both Argon2id derivations in parallel regardless of outcome; only surface the one that successfully decrypts. Total time becomes constant. |374-375-### 5.3 Browser extension & autofill security376-377-**Chrome (`manifest.json`) permissions (MV3):**378-```379-"storage", "tabs", "activeTab", "scripting", "clipboardWrite",380-"alarms", "idle", "nativeMessaging", "webAuthenticationProxy"381-```382-**Firefox (`manifest.firefox.json`):** same minus `webAuthenticationProxy` (not supported by Gecko).383-384-| Permission | Used by | Justified today? |385-|---|---|---|386-| `storage` | Vault + settings + license + sync scaffolding | Yes |387-| `tabs` | Popup → active tab query, broadcasting `VAULT_UNLOCKED` | Yes |388-| `activeTab` | Autofill into current page | Yes |389-| `scripting` | Clipboard fallback injection (`src/background/clipboard.ts:9`) | Yes |390-| `clipboardWrite` | Copy password / TOTP | Yes |391-| `alarms` | Auto-lock | Yes |392-| `idle` | Auto-lock on system idle / screen lock | Yes |393-| `nativeMessaging` | *Declared but unused* — `connectNative` never invoked | **No (today)** — see EXT-002 |394-| `webAuthenticationProxy` | Passkey provider | Yes |395-396-**Content-script scope:** `<all_urls>` — standard and necessary for any extension offering universal autofill. Mitigated by CSP (`script-src 'self' 'wasm-unsafe-eval'; object-src 'none'`) and by only injecting the autofill selector when a real login/signup form is present (`isLoginForm(fields) || isSignupForm(fields)` gate in `src/content/index.ts:404, 418, 439`).397-398-**Autofill scoping:** `src/content/fill.ts:8` uses `extractDomain()` (eTLD+1 via `tldts`) to compare form action domain vs. expected domain before filling. `fillFields` returns early if they differ. Combined with the entry index keyed on eTLD+1 (`buildDomainIndexSync`, `vault.ts:140`), an entry for `github.com` autofills on `github.com` and `gist.github.com` — standard behaviour. Autofill does **not** require user confirmation per-fill; the selector UI is shown and a click is required, which is effectively a per-fill confirmation.399-400-**Subdomain attack (`evil.example.com` vs `example.com`):** `extractDomain` returns `example.com` for both, so an entry saved for `example.com` would offer to autofill on `evil.example.com`. This is the default behaviour of every major password manager, but worth disclosing.401-402-**No network traffic during autofill** from the vault code path itself. The one exception is the favicon fetch already flagged in ZK-003.403-404-### Finding EXT-001405-406-| Field | Value |407-|---|---|408-| Title | Autofill is click-gated and scoped to eTLD+1 of the form action |409-| Category | Browser Extension |410-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☐ Low  ☒ Info |411-| Status | ☒ Pass  ☐ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |412-| Recommendation | Optional: add a Settings toggle for "Strict subdomain matching" that only autofills on exact hostname match. Niche but defensible for high-value entries. |413-414-### Finding EXT-002415-416-| Field | Value |417-|---|---|418-| Title | `nativeMessaging` permission is declared but unused in live code paths |419-| Category | Browser Extension / Permissions |420-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☒ Low  ☐ Info |421-| Status | ☐ Pass  ☒ Warn  ☐ Fail  ☐ Unverifiable  ☐ N/A |422-| Evidence | `manifest.json:47`; `src/background/sync.ts:122` is the only caller of `chrome.runtime.connectNative`, and nothing calls `connectSyncHost`. The Rust sync host does not compile (see SYN-001) and no native-messaging host is installed by the extension today. |423-| Impact | Minor — the extension requests a permission it does not currently exercise. Chrome Web Store reviewers and security-conscious users may ask why. |424-| Recommendation | Gate the permission behind the Peach Sync feature flag, or remove it from the manifest until sync ships. |425-426-### Finding EXT-003 — `clipboardClearSeconds` setting is declared but never consumed427-428-| Field | Value |429-|---|---|430-| Title | Clipboard auto-clear is hardcoded to 30 s; the `clipboardClearSeconds` user setting is ignored |431-| Category | Hygiene / Settings |432-| Severity | ☐ Critical  ☐ High  ☐ Medium  ☒ Low  ☐ Info |433-| Status | ☐ Pass  ☐ Warn  ☒ Fail  ☐ Unverifiable  ☐ N/A |434-| Evidence | `VaultSettings.clipboardClearSeconds?: number` defined at `src/background/vault.ts:29` but the only reader is a Settings UI write. `src/background/clipboard.ts:29` uses a literal `30_000`. |435-| Impact | Users who set this thinking it lowers their exposure window are misled. |436-| Recommendation | Have `copyToClipboard` read `getSettings().clipboardClearSeconds ?? 30` and multiply by 1000. Two lines. |437-438----439-440-## Scoring Rubric441-442-| Category | Weight | Guidance | Score (0–10) | Weighted | Notes |443-|---|---|---|---|---|---|444-| Cryptographic Algorithm Correctness | 20% | 10 = all algorithms correct & verified | **9** | 1.80 | AES-256-GCM, Argon2id, BLAKE3, X25519 all correct. Parameters meet/exceed OWASP. One doc gap (CRY-001) costs 1 point. |445-| Zero-Knowledge Architecture Integrity | 20% | 10 = no network calls, no vault leakage | **7** | 1.40 | No vault content leaves the device. But the favicon fetch leaks the *set* of domains to DuckDuckGo — ZK-003. Two points off. |446-| Network Behavior / Telemetry | 15% | 10 = zero unexpected calls | **7** | 1.05 | No telemetry SDK. HIBP is disclosed. DuckDuckGo favicon is **not** disclosed and not opt-in. |447-| Sync Protocol Security | 15% | 10 = Noise handshake verified, LAN-only, unpaired rejected | **3** | 0.45 | The feature is marketed but not live. The native-host scaffold contains a critical zero-key bug (SYN-001) that must be fixed before ship. Scored low because the kit measures an existing claim — "Local-network peer-to-peer sync only" — that today works only because the feature is dormant, not because it is correctly implemented. |448-| Backup & Restore Safety | 10% | 10 = passphrase required, tamper-detection works | **10** | 1.00 | BLAKE3 checksum, AEAD, constant-time compare, dual entry-count cross-check, full vault fidelity. |449-| Memory Handling | 10% | 10 = canary absent from memory after lock | **7** | 0.70 | AES key zeroed. Plaintext strings linger until GC — fundamental JS limitation (MEM-001). |450-| Duress Mode Integrity | 5% | 10 = vault file indistinguishable | **4** | 0.20 | Plaintext `peach_duress` flag + different-sized decoy blob + timing side channel (DUR-001, DUR-002). Deniability significantly weaker than claimed. |451-| Browser Extension Security | 5% | 10 = no over-permissions, correct scoping | **8** | 0.40 | Click-gated autofill, eTLD+1 scoping, CSP set. One dormant permission (EXT-002) and one dead setting (EXT-003). |452-| **TOTAL** | **100%** |  |  | **70.0 / 100** | |453-454-### Score interpretation455-456-**70 → Conditional.** Architecture and core cryptography are sound. Two material issues hold it back from a confident "Sound" verdict:457-458-1. **ZK-003** — favicons silently leak the domain set to a third party, contradicting the marketing tone.459-2. **SYN-001** — the sync scaffold ships a critical zero-key responder bug. It does not execute today, but it will need to be fixed and re-audited before the Peach Sync feature is enabled.460-461-The duress findings (DUR-001, DUR-002) are also material if the feature is advertised as plausible-deniability-grade. They are small code changes.462-463----464-465-## Part D — Verified Claim Status (peachpasswords.com)466-467-| Claim | Verdict | Evidence |468-|---|---|---|469-| "Your vault stays on your device. No server, no account." | ☒ Pass | No server, no account, no uploads. License is offline-verified (Ed25519). |470-| "Sync it peer-to-peer across your devices." | ☒ Warn | Marketed, not live. Scaffolding exists; critical responder-key bug must be fixed (SYN-001). |471-| "Zero-knowledge vault encryption" | ☒ Pass | AES-256-GCM + Argon2id + per-vault salt. Vault content never leaves the device. |472-| "Zero server dependency" | ☒ Pass | Functions fully offline. HIBP is the only network dependency and degrades gracefully. |473-| "No account creation" | ☒ Pass | Confirmed — no registration flow; licenses are offline-verified blobs. |474-| "No product telemetry" | ☒ Warn | No analytics SDK, but the favicon path constitutes an undisclosed third-party callout (ZK-003). |475-| "No cloud to breach" | ☒ Pass | Storage is local to the browser profile. CJK backups are user-held. |476-| "Local-network peer-to-peer sync only" | ☐ N/A | Feature dormant in 1.4.24. |477-| "AES-256-GCM for authenticated confidentiality" | ☒ Pass | Verified; fresh 96-bit nonce; 128-bit tag; version-byte AAD. |478-| "Argon2id with per-vault salt and high-memory parameters" | ☒ Pass | m=65 536 / t=3 / p=4; per-vault 16-byte CSPRNG salt. |479-| "Authenticated decryption rejects tampered phrases" | ☒ Pass | BLAKE3 checksum (constant-time) **before** passphrase prompt; AES-GCM AEAD after. |480-| "k-anonymity prefix sent for breach checks" | ☒ Pass | 5-char SHA-1 prefix + `Add-Padding: true`. |481-482----483-484-## Additional findings (EXTRA-00X)485-486-### Finding EXTRA-001 — Stale/duplicate AES module487-488-| Field | Value |489-|---|---|490-| Title | `src/crypto/aes.ts` is a near-duplicate of `src/background/aes.ts` and appears unused |491-| Severity | ☒ Info |492-| Status | ☒ Warn |493-| Evidence | `src/background/vault.ts:8` imports from `./aes` (i.e., `src/background/aes.ts`). No other caller references `src/crypto/aes.ts`. |494-| Recommendation | Delete the unused file to reduce audit surface and avoid confusion (future-me reading a finding will grep and get two hits). |495-496-### Finding EXTRA-002 — Minimum master-password length is only 8 characters497-498-| Field | Value |499-|---|---|500-| Title | `createVault` accepts an 8-character master password with no strength gate |501-| Severity | ☒ Low |502-| Status | ☒ Warn |503-| Evidence | `src/popup/views/Lock.tsx:33-38` — `canCreate = password.length ≥ 8`. zxcvbn strength is displayed but not enforced. |504-| Recommendation | Require zxcvbn ≥ 2 and length ≥ 12 for vault creation. (CJK export already enforces length ≥ 16 and zxcvbn ≥ 3; match that bar for the at-rest passphrase, or at least get close.) |505-506-### Finding EXTRA-003 — Redundant idle listener507-508-| Field | Value |509-|---|---|510-| Title | `chrome.idle.onStateChanged` is listened to twice (`entry.ts:12` and `alarms.ts:36`) |511-| Severity | ☒ Info |512-| Status | ☒ Warn |513-| Evidence | Both files register listeners that call `lock()` on `state === "idle" | "locked"`. Harmless (calls are idempotent) but suggests refactor drift. |514-| Recommendation | Keep the listener in `alarms.ts` only and remove the one in `entry.ts`. |515-516----517-518-## Summary recommendation519-520-**Do not ship the sync feature in its current Rust state** (SYN-001). Before next public release:521-522-1. **Fix the favicon privacy leak** (ZK-003). Highest priority — it silently contradicts the Peach tagline.523-2. **Harden duress mode storage** (DUR-001) and make the unlock timing constant (DUR-002).524-3. **Tighten the master-password minimum** (EXTRA-002).525-4. **Wire `clipboardClearSeconds`** (EXT-003) — two-line fix.526-5. **Gate `nativeMessaging`** behind a sync feature flag (EXT-002).527-6. **Update the audit kit** (CRY-001) to reflect the MV3 storage model and the v3 CJK header.528-529-Cryptographic core is solid. The privacy-posture concerns are fixable in a single focused PR; the sync concerns require a Rust-side fix and another round of review before the feature is turned on.

@@ -1,259 +0,0 @@1-# Peach — Post-Remediation Security Audit (v1.4.25)2-3-**Source audit:** `peach_audit_v1424.md` (score 70/100)4-**Remediation spec:** `peach_remediation_spec.md`5-**Audit date:** 2026-04-216-**Auditor:** June ([email protected]) / assisted by Claude Code7-**Version under test:** Peach post-remediation (working tree at `/Users/june/projects/peach-browser`)8-**Scope:** verification of findings closed by the PR 1 + PR 2 remediation bundle. SYN-001 remains deferred per the remediation plan; the D-series (security-page disclosures) is a website task outside this repository.9-10----11-12-## Summary13-14-| Finding | Category | Prior status | New status | Evidence |15-|---|---|---|---|---|16-| ZK-003 | Favicon domain leak | FAIL | **PASS** | `src/shared/favicon.ts`; grep for `duckduckgo` in `src/` returns zero hits. |17-| DUR-001 | Duress forensic detectability | FAIL | **PASS** | `src/background/vault.ts` slot-neutral storage + encrypted `duressConfigured` flag + size-matched slot B. |18-| DUR-002 | Duress unlock timing side channel | WARN | **PASS** | `unlock()` derives both slots in `Promise.all`; spy-based test asserts 2 derivations on every unlock path. |19-| EXT-003 | `clipboardClearSeconds` ignored | FAIL | **PASS** | `src/background/clipboard.ts` reads `getSettings().clipboardClearSeconds`. |20-| EXT-002 | Dormant `nativeMessaging` permission | WARN | **PASS** | Removed from `manifest.json` and `manifest.firefox.json`; will be re-declared in the Sync PR. |21-| EXTRA-001 | Duplicate `src/crypto/aes.ts` | WARN | **PASS** | File deleted; imports redirected to `src/background/aes.ts`. |22-| EXTRA-002 | 8-char master-password minimum | WARN | **PASS** | `src/popup/views/Lock.tsx` now gates on length ≥ 12 AND zxcvbn ≥ 2. |23-| EXTRA-003 | Duplicate idle listener | WARN | **PASS** | `chrome.idle.onStateChanged` handler removed from `src/background/entry.ts`; single canonical registration remains in `src/background/alarms.ts`. |24-| CRY-001 | Kit §2.1 documentation drift | WARN | **PASS** | `peach_audit_v1424.md` §2.1 updated: slot-neutral keys, `peach:v3:` header, source-level grep. |25-| SYN-001 | Noise NK zero static key | FAIL | **DEFERRED** | Feature dormant; to be fixed and re-audited before the Sync feature flag flips on. |26-27----28-29-## Module 2 — Cryptographic Verification (re-run)30-31-### 2.1 Vault file format — slot-neutral storage32-33-Post-remediation the at-rest model is two always-present records:34-35-```jsonc36-// chrome.storage.local37-{38-  "peach_vault_a": { "version": 1, "salt": "...", "nonce": "...", "ciphertext": "...", "tag": "..." },39-  "peach_vault_b": { "version": 1, "salt": "...", "nonce": "...", "ciphertext": "...", "tag": "..." }40-}41-```42-43-No `peach_duress` flag. No `peach_decoy_vault` key. The schema does not distinguish which slot is real.44-45-**Evidence:** `src/background/vault.ts` — constants `SLOT_A = "peach_vault_a"`, `SLOT_B = "peach_vault_b"`; `createVault()` writes both slots; `ensureMigrated()` translates the legacy schema and removes `peach_vault`, `peach_decoy_vault`, and `peach_duress` on first access; `setupDuress()` and `disableDuress()` never write a flag.46-47-**Plaintext envelope.** Inside the AEAD, the plaintext is now a JSON object `{ entries, duressConfigured }` padded to the next 1 KiB boundary with trailing whitespace (JSON.parse tolerates this). The `duressConfigured` bit is therefore encrypted and inaccessible to a storage-level examiner. Legacy plaintext (bare array) is still accepted on decode and rewritten to the envelope shape on the next save.48-49-**Ciphertext sizing.** Slot A is padded to a 1 KiB plaintext bucket. Slot B is sized to match slot A's ciphertext at write time. When duress is not configured, every save regenerates slot B's noise blob to match the new slot A size. When duress IS configured, slot B is left alone (known trade-off: we do not hold the decoy key outside an active decoy-mode unlock; documented in code comment above `persistSlotA`).50-51-### 2.4 Duress mode — redesigned52-53-Acceptance criteria from the remediation spec, verified:54-55-| Criterion | Result |56-|---|---|57-| `chrome.storage.local.get(null)` returns only `peach_vault_a` / `peach_vault_b` (plus optional `peach_settings`) | PASS — new `vault.test.ts` asserts this. |58-| Fresh install with no duress shows two slots of similar size | PASS — `slot A and slot B have matching ciphertext size at fresh install` test. |59-| Forensic examiner cannot determine which slot is real or whether a decoy exists | PASS — the only side channel is slot size, which matches by construction pre-duress and at setup time. |60-| Real passphrase → real entries | PASS — `unlocks with real password and loads real entries`. |61-| Duress passphrase → empty entries | PASS — `unlocks with duress password and loads empty entries`. |62-| Wrong passphrase → failure after both derivations | PASS — spy-based test confirms 2 `deriveKey` calls per attempt. |63-| Legacy schema migrates without data loss | PASS — `migrates legacy peach_vault / peach_decoy_vault / peach_duress schema`. |64-65-### 2.5 Unlock timing (DUR-002)66-67-```ts68-// src/background/vault.ts — unlock()69-const [slotA, slotB] = await Promise.all([loadSlot(SLOT_A), loadSlot(SLOT_B)]);70-const [keyA, keyB] = await Promise.all([71-  slotA ? deriveKey(password, unhex(slotA.salt)) : Promise.resolve(null),72-  slotB ? deriveKey(password, unhex(slotB.salt)) : Promise.resolve(null),73-]);74-const [payloadA, payloadB] = await Promise.all([75-  keyA && slotA ? tryDecryptSlot(slotA, keyA) : Promise.resolve(null),76-  keyB && slotB ? tryDecryptSlot(slotB, keyB) : Promise.resolve(null),77-]);78-```79-80-Both Argon2id derivations run unconditionally in parallel. Wall-clock time is bounded by the slower derivation, which is symmetric in cost since both slots use identical parameters. The real-vs-decoy distinguisher cited in DUR-002 is removed.81-82----83-84-## Module 3 — Network Behavior (re-run)85-86-### 3.1 ZK-003 — Favicon fetch87-88-**Fix.** `src/shared/favicon.ts` resolves a favicon URL via `chrome.runtime.getURL("/_favicon/")` with the `favicon` permission (Chrome MV3). The URL points into the browser's own favicon cache — zero network egress, zero third party. On Firefox (where the API is not exposed), the helper returns `null` and callers render their existing type-specific glyph (`LOGIN_ICON` / `NOTE_ICON` / `PASSKEY_ICON`).89-90-*Deviation from the remediation spec:* the spec cited `chrome://favicon2/` as the URL scheme. That URL is not reachable from extension context in current Chromium; the correct MV3 API is `/_favicon/` gated by the `favicon` permission. Functional outcome is identical (browser-cached icon, no network).91-92-**Content script.** `src/content/inject.ts` now unconditionally uses the inline key glyph in the page-injected autofill selector. This is stricter than the spec required — it avoids exposing `_favicon/*` via `web_accessible_resources` to the page context, and further reduces the disclosure surface (a hostile page with access to extension resources no longer learns *which* stored domain the user is autofilling).93-94-**Evidence.** `grep -r "duckduckgo" src/` → zero hits. `grep -r "icons\.duckduckgo" .` returns only matches inside historical audit markdown and the `dist-chrome/` / `dist-firefox/` artifacts that predate this build.95-96-### 3.2 Enumerated network calls (static, post-remediation)97-98-| Call site | Destination | Disclosed | Status |99-|---|---|---|---|100-| `src/background/vault.ts` (HIBP breach check) | `api.pwnedpasswords.com` (k-anonymity prefix) | yes | PASS |101-| `src/shared/favicon.ts` | `chrome-extension://<id>/_favicon/...` (browser-local) | N/A (local) | PASS |102-| (previously) DDG favicon fetch | — | removed | PASS |103-104----105-106-## Module 6 — Browser Extension Security (re-run)107-108-### 6.1 Manifest permissions109-110-```jsonc111-// manifest.json (Chrome)112-"permissions": [113-  "storage", "tabs", "activeTab", "scripting",114-  "clipboardWrite", "alarms", "idle",115-  "favicon", "webAuthenticationProxy"116-]117-// manifest.firefox.json (Firefox)118-"permissions": [119-  "storage", "tabs", "activeTab", "scripting",120-  "clipboardWrite", "alarms", "idle"121-]122-```123-124-`nativeMessaging` is gone. `favicon` is declared only on Chrome (Firefox does not expose it). All remaining permissions are justified by a live code path.125-126-### 6.2 Clipboard auto-clear (EXT-003)127-128-```ts129-// src/background/clipboard.ts130-const settingsSeconds = getSettings().clipboardClearSeconds;131-const clearAfterMs =132-  (typeof settingsSeconds === "number" && settingsSeconds > 0133-    ? settingsSeconds134-    : DEFAULT_CLEAR_SECONDS) * 1000;135-```136-137-The user's `clipboardClearSeconds` is honored. The default (setting absent) is 30 s, matching the previous hardcoded behavior. Option B from the spec: unconditional clear, no new `clipboardRead` permission.138-139-### 6.3 Idle listener (EXTRA-003)140-141-`chrome.idle.onStateChanged` has exactly one registration, at `src/background/alarms.ts:35–40`. The listener in `src/background/entry.ts` has been removed. `setDetectionInterval` is called once, inside `setupAutoLock()`, with a resolution derived from the user's auto-lock minutes.142-143----144-145-## Module 8 — Vault Creation Hardening (EXTRA-002)146-147-```ts148-// src/popup/views/Lock.tsx149-const MIN_LENGTH = 12;150-const MIN_ZXCVBN_SCORE = 2;151-152-const canCreate = createMemo(153-  () =>154-    password().length >= MIN_LENGTH &&155-    confirmPassword().length >= MIN_LENGTH &&156-    password() === confirmPassword() &&157-    strengthScore() !== null &&158-    strengthScore()! >= MIN_ZXCVBN_SCORE159-);160-```161-162-The gate enforces length AND zxcvbn independently. `handleCreate()` produces a specific error when the strength floor is unmet. Existing vaults are unaffected — this gate applies only at vault creation, so users with shorter legacy passphrases continue to unlock.163-164----165-166-## Scoring Rubric — re-scored167-168-| Category | Weight | Score (prior) | Score (new) | Weighted | Notes |169-|---|---|---|---|---|---|170-| Cryptographic Algorithm Correctness | 20% | 9 | **10** | 2.00 | CRY-001 doc drift fixed; algorithms unchanged and correct. |171-| Zero-Knowledge Architecture Integrity | 20% | 7 | **9** | 1.80 | ZK-003 closed. One point withheld until security page (D-2) is published. |172-| Network Behavior / Telemetry | 15% | 7 | **9** | 1.35 | DDG leak gone. HIBP is the only remaining outbound call, disclosed and opt-outable via `breachMonitoring` setting. |173-| Sync Protocol Security | 15% | 3 | **3** | 0.45 | SYN-001 still open; feature still dormant. Score unchanged until the sync remediation ships. |174-| Backup & Restore Safety | 10% | 10 | **10** | 1.00 | Unchanged. |175-| Memory Handling | 10% | 7 | **7** | 0.70 | Unchanged (MEM-001 is a fundamental JS limitation). Small improvement: `unlock()` now `zeroKey`s the unused derivation. |176-| Duress Mode Integrity | 5% | 4 | **9** | 0.45 | DUR-001 and DUR-002 closed; slot-neutral storage + encrypted flag + constant-time derivation. One point off for the known save-time size-leak trade-off when duress is configured and the real vault grows across a 1 KiB bucket boundary. |177-| Browser Extension Security | 5% | 8 | **10** | 0.50 | EXT-002 and EXT-003 closed. No dormant permissions; clipboard setting wired. |178-| **TOTAL** | **100%** |  |  | **8.25 / 10 → 82.5 / 100** | |179-180-### Score interpretation181-182-**82.5 → Sound, conditional on SYN-001 before Sync ships.** The zero-knowledge posture now matches the marketing; duress is no longer a tell at the storage layer; the extension carries no dormant permissions. The remaining 17.5 points break down as:183-184-- **15 pts** of headroom on Sync (SYN-001) and Memory (MEM-001 — structural JS limitation).185-- **~2 pts** of tightening possible: published D-series disclosures (D-2 favicon, D-4 duress design, D-1/D-3 KDF parameters) would move Zero-Knowledge and Network back to 10.186-- **~0.5 pts** on duress size-leak when duress is configured and the real vault grows (documented trade-off; closable with Option A from the remediation spec if the decoy key is cached at unlock).187-188----189-190-## Re-audit checklist results191-192-| Finding | Target | Actual |193-|---|---|---|194-| ZK-003 | FAIL → PASS | **PASS** |195-| DUR-001 | FAIL → PASS | **PASS** |196-| DUR-002 | WARN → PASS | **PASS** |197-| EXT-003 | FAIL → PASS | **PASS** |198-| EXT-002 | WARN → PASS | **PASS** |199-| EXTRA-002 | WARN → PASS | **PASS** |200-| ZK / Network score | 7 → 9 | **9 / 9** (matches spec target) |201-| Duress score | 4 → 8 | **9** (exceeds target) |202-| Browser extension score | 8 → 10 | **10** (matches) |203-| **Total** | **70 → ~84** | **82.5** (within target band) |204-205----206-207-## What is still open208-209-### SYN-001 — Noise NK zero static key (deferred)210-211-The native-host scaffold at `native/peach-sync-host/` still contains the `[0u8; 32]` responder key and the `spawn_accept_loop` arity mismatch. The feature does not execute in the shipped build. The remediation plan places the fix in a separate sprint so the keypair-generation logic, pairing UX, and re-audit can be done as a coherent package. **This finding remains FAIL and must block the Sync feature-flag flip.**212-213-### D-1 … D-4 — peachpasswords.com/security disclosures214-215-These are documentation updates to the marketing site, not code. Recommended publication text is given in `peach_remediation_spec.md` §Track D. When published, they complete the ZK-003 and DUR-001 story end-to-end.216-217----218-219-## Verified Claim Status — post-remediation220-221-| Claim | Prior | New | Evidence |222-|---|---|---|---|223-| "Your vault stays on your device. No server, no account." | PASS | **PASS** | Unchanged. |224-| "Sync it peer-to-peer across your devices." | WARN | **WARN** | Still dormant; SYN-001 still open. |225-| "Zero-knowledge vault encryption" | PASS | **PASS** | Unchanged. |226-| "Zero server dependency" | PASS | **PASS** | Unchanged. |227-| "No account creation" | PASS | **PASS** | Unchanged. |228-| "No product telemetry" | WARN | **PASS** | DDG favicon leak closed; HIBP is disclosed. |229-| "No cloud to breach" | PASS | **PASS** | Unchanged. |230-| "Local-network peer-to-peer sync only" | N/A | **N/A** | Feature dormant. |231-| "AES-256-GCM for authenticated confidentiality" | PASS | **PASS** | Unchanged. |232-| "Argon2id with per-vault salt and high-memory parameters" | PASS | **PASS** | Unchanged. |233-| "Authenticated decryption rejects tampered phrases" | PASS | **PASS** | Unchanged. |234-| "k-anonymity prefix sent for breach checks" | PASS | **PASS** | Unchanged. |235-| *(new)* "Duress mode leaves no at-rest fingerprint" | — | **PASS (pending D-4 publication)** | DUR-001/002 closed; disclosure pending. |236-237----238-239-## Test posture240-241-- `tsc --noEmit` — clean.242-- `vitest run` — 64 / 65 pass. The single failure (`src/content/index.test.ts > shows saved identities on the first signup username focus`) is a pre-existing content-script UI timing test; it reproduces on unmodified `HEAD` and is unrelated to the remediation.243-- `src/background/vault.test.ts` — 12 / 12 pass, including new DUR-001 / DUR-002 coverage:244-  - `writes both slots A and B on vault creation`245-  - `slot A and slot B have matching ciphertext size at fresh install`246-  - `does not expose a plaintext duress flag after setupDuress`247-  - `unlocks with real password and loads real entries`248-  - `unlocks with duress password and loads empty entries`249-  - `runs both slot derivations in parallel for constant-time unlock (DUR-002)`250-  - `persists duressConfigured across lock/unlock in encrypted payload`251-  - `migrates legacy peach_vault / peach_decoy_vault / peach_duress schema`252-253----254-255-## Sign-off256-257-**Verdict:** Sound (82.5 / 100) for the current feature set. Sync remains gated on SYN-001. Security-page disclosures (D-series) should publish together with the next marketing-site deploy. No new findings introduced by the remediation.258-259-**Next re-audit trigger:** the Sync feature flag flipping on, or any change to `vault.ts` storage schema, `unlock()` pathway, or manifest permissions.