1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
# TODO — Future Work
## High Priority
### Key Material Exposure Assessment
- [x] Map where MUK lives — **JS heap as exportable JWK, entire unlocked session. Documented in key-hierarchy.md.**
- [x] Map where SRP-X lives — **JS heap on CTX.session.auth.srpX. Documented in key-hierarchy.md.**
- [x] Trace biometry save flow — **MUK + SRP-X serialized as JSON, sent via native messaging. Documented in key-hierarchy.md.**
- [x] Trace re-auth flow — **MUK + Secret Key + SRP-X used for silent re-auth on 401. No user interaction. Documented in key-hierarchy.md.**
- [x] Trace master password lifecycle — **5-min timebox in closure, set on CTX.user.password temporarily during sign-in then cleared. Documented in key-hierarchy.md.**
- [ ] Determine if the `Rv` (client) class ever explicitly clears the MUK reference on lock (beyond `_dangerousInnerCTX = undefined`)
- [ ] Check if `rA.onLock` triggers WASM-side key zeroing
- [ ] Trace what happens to content-script-side decrypted values after fill completes — are they GC'd promptly?
- [ ] Check if the 5-minute password timebox can be extended by repeated Duo attempts
- [ ] Determine if `lessSafeOpenNaCl` has any key exposure implications
### Deep Reverse Engineering of background.js
- [ ] Beautify/pretty-print the 2.9MB background.js for readable analysis
- [ ] Map all `m5({...})` handler implementations — trace what each handler does after receiving a message
- [ ] Determine if message schema validation exists at the background router level (critical for security posture)
- [ ] Identify the `sdj(wd)` call — appears to register additional handlers or middleware
- [ ] Trace the `VA()` function used for broadcasting events to tabs
### Native Messaging Protocol
- [x] Identify the native app ID used with `chrome.runtime.sendNativeMessage` — **empty string `""`**, Firefox routes via `applications.gecko.id`
- [x] Map the command/response schema for native messaging — **JSON envelope `{name: "core", data: JSON.stringify({type, data})}`, Biometry messages documented in message-catalog.md**
- [x] Determine what operations are delegated to the native app vs handled in-extension — **Biometry (save/unlock/remove MUK+SRP-X), biometry availability, dSecret proxy, device trust signing, desktop connection state**
- [ ] Analyze the 6 localhost ports (12519, 40978, 52115, 22287, 60685, 22322) — what protocol, what data. Are these the same native bridge or separate services?
- [ ] Check if localhost connections use any authentication/signing
- [ ] Determine if the native messaging JSON carries any MAC/signature on the MUK payload
### Frame Relay Security
- [ ] Trace `relay-message-to-frames` handler (`eij`) — does it validate sender frame? Does it restrict what messages can be relayed?
- [ ] Trace `targeted-message-to-inline-menu` handler (`tij`) — same questions
- [ ] Determine if a compromised iframe can spoof messages to another frame's inline menu
- [ ] Check origin validation on all frame-relay paths
### WebAuthn Protocol Hardening Assessment
- [ ] Test if a malicious page can inject fake `op-window-syn-ack` before the real extension responds
- [ ] Test the 100ms re-patching race condition — can a page reliably intercept credentials between overwrite and re-patch?
- [ ] Analyze what happens if two extensions both try to intercept WebAuthn
- [ ] Check if the `stopImmediatePropagation` ordering is reliable at `document_start`
### Save Object Pipeline
- [ ] Trace the save flow end-to-end: DOM capture → `add-save-object` → public key encryption → storage
- [ ] Verify the public key used for save object encryption is authenticated (not injectable)
- [ ] Check what happens if a page injects fake form data before the save prompt
## Medium Priority
### WASM Module Analysis
- [x] Analyze exported functions from `op_wasm_b5x_bg` — **80+ methods documented in architecture.md `rA.*` interface table**
- [x] Determine if key material ever crosses the WASM→JS boundary in plaintext — **YES. MUK exported as JWK, SRP-X cached in JS, decrypted passwords returned to JS for fill. Documented in key-hierarchy.md.**
- [ ] Check `confidential_computing_bg` — what confidential computing features are used and where?
- [x] Analyze `b5_mycelium_bg` — **confirmed as P2P relay for remote autofill. Noise-protocol-like handshake with `wasmpairingsession*` and `wasmsetuptransportsession*` exports.**
- [ ] Map HPKE usage — what is encrypted with HPKE vs AES-GCM vs RSA-OAEP? (`wasmsealed_*` exports use HPKE)
- [ ] Analyze the `b5_trustlog_bg` trust log entries — what operations are logged? (`wasmtrustlogclient_create_add_users_entry`, `_remove_users_entry`, `_add_groups_entry`, etc.)
- [ ] Determine how vault keys are managed inside WASM — are they ever exposed to JS or only used internally?
### External Extension Messaging
- [ ] Trace all 3 `onMessageExternal` handler registrations
- [ ] Determine what messages are accepted from external extensions
- [ ] Check if there's any authentication/validation of the sender extension ID
### Large Chunk Analysis
- [ ] Analyze `chunk-OJR52IF5.js` (1.9MB) — likely contains the bulk of vault/account logic
- [ ] Analyze `chunk-MSIWLBOQ.js` (804KB) — likely UI component library or crypto support
- [ ] Analyze `chunk-22IBMJDR.js` (138KB)
- [ ] Analyze `chunk-QEIU26VY.js` (92KB)
- [ ] Analyze `chunk-PQH6ALAA.js` (156KB)
### Credential Fill Path
- [x] Trace the fill flow: **background calls `rA.fillItem`/`rA.startFillSession` → WASM decrypts → plaintext returned to JS → `chrome.tabs.sendMessage` → content script → DOM injection**
- [x] Identify where decrypted password/OTP/card values exist in JS memory — **JS heap in background (from WASM return), JS heap in content script (from sendMessage), DOM (after fill). No explicit zeroing.**
- [ ] Check if clipboard operations (`clipboardWrite`) properly clear after timeout
- [ ] Analyze `fill-generated-password` flow — is the generated password ever in plaintext outside WASM?
- [ ] Determine how long decrypted values remain reachable in JS (fill session lifecycle)
### Partner Integration Data Minimization
- [ ] Privacy.com: what data is sent to `api.privacy.com`? Card params, user identity?
- [ ] Fastmail: what data is sent to Fastmail JMAP? Email addresses, domain info?
- [ ] Brex: what data flows to `platform.brexapis.com`?
- [ ] Kolide: what health/device data is shared? Analyze `kolide.js` (60KB)
- [ ] Trelica: what app catalog data is exchanged?
### Authentication & Session Security
- [ ] Trace the full SRP exchange — what SRP method/group is used? (SrpMethod, SrpMethodPrefix constants)
- [ ] Determine if transport tokens provide replay protection
- [ ] Analyze the delegated session mechanism — can a compromised context delegate to others?
- [ ] Check if `safeSignOutClient` properly clears all key material (it sets `_srpX = undefined`, `_dangerousInnerCTX = undefined`)
- [ ] Trace the `invalidate` flow — does invalidation zero keys or just remove references?
- [ ] Analyze the offline MFA account tracking (`offline-mfa-accounts` in localStorage) — security of this state
- [ ] Check if the Duo code extraction from URL (`duo_code` parameter) is vulnerable to URL injection
- [ ] Determine if `CTX.getTransportToken()` exposes session-equivalent tokens
### Secure Remote Autofill (director.ai)
- [ ] Analyze `secure-remote-autofill-start-pairing.js` (57KB) — pairing protocol
- [ ] Analyze `secure-remote-autofill-complete-pairing.js` (59KB) — completion flow
- [ ] Determine what crypto is used for the remote autofill channel (likely Mycelium + HPKE)
- [ ] Check if the pairing is bound to specific devices/sessions
### Shell Plugins / AI Agent Integration
- [ ] Map the full shell-plugins subsystem — what AI browsing agents are supported?
- [ ] Analyze credential detection in agent contexts (Browserbase, BrowserUse icons present in chunks)
- [ ] Check what prompts/confirmations exist before saving agent-detected credentials
- [ ] Assess risk of AI agents leaking credential data through their own telemetry
## Lower Priority
### Telemetry Deep Dive
- [ ] Extract all Snowplow event schemas (iglu schema references)
- [ ] Determine exactly what URL/page data appears in telemetry events
- [ ] Verify redaction is applied consistently (not just in fill telemetry)
- [ ] Check if error stack traces sent to Sentry contain sensitive URL parameters
### Popup / App UI
- [ ] Analyze `popup/index.js` (399KB) — what privileged operations can be triggered from popup?
- [ ] Analyze `app/app.js` (682KB) — full window UI capabilities
- [ ] Check for any XSS vectors in UI rendering of vault item data
### Login Detection Heuristics
- [ ] Analyze `heuristics.js` — what classifies as a login page?
- [ ] Check for false positive scenarios that could trigger unintended autofill
- [ ] Verify `LOGIN_EVENT` and `LOGIN_STEP` don't leak sensitive page content
### Internationalization
- [ ] Check if locale-specific code paths have different security properties
- [ ] Analyze `assets/js/messages.i18n-*.js` files for any embedded data beyond translations
### Web-Accessible Resource Fingerprinting
- [ ] Document exactly which resources are web-accessible and can be probed by any site
- [ ] Assess extension detection/fingerprinting risk from these resources
- [ ] Check if `*.js.map` being web-accessible leaks useful information to attackers
## Tooling & Infrastructure
### Analysis Setup
- [ ] Set up JS beautifier pipeline (prettier/esbuild) for all minified files
- [ ] Build automated string extraction for message names, URLs, feature flags
- [ ] Set up AST-based analysis for tracing message handler call chains
- [ ] Create a dynamic analysis harness (load extension in test Firefox profile, intercept messages)
### Documentation
- [ ] Create a visual architecture diagram (Mermaid/D2)
- [ ] Build a cross-reference index: message name → handler file → handler function → effects
- [ ] Document all feature flags and their security implications
|