|
| 1 | +# Sim browser extension |
| 2 | + |
| 3 | +Implementation scope and research, 2026-10-29. |
| 4 | + |
| 5 | +## Product contract |
| 6 | + |
| 7 | +The extension is another surface of Sim. A native Chrome side panel hosts the actual |
| 8 | +Sim composer and transcript, using existing authenticated Mothership requests, |
| 9 | +conversation persistence, streaming recovery, model controls, tool permissions, |
| 10 | +and workspace authorization. A conversation can continue in the full app. |
| 11 | + |
| 12 | +The user signs in in a normal Sim tab, chooses a workspace, opens or creates a |
| 13 | +conversation, and explicitly attaches the current page or highlighted text. |
| 14 | +Pending snapshots sit beside the composer as compact removable attachments. Opening one |
| 15 | +shows the captured text, source, capture time, and conversation-retention disclosure. |
| 16 | +Partial captures remain labeled in the attachment row. Site access lives in the |
| 17 | +extension options menu; successful delivery adds no persistent status banner. |
| 18 | +They are immutable: navigating to another page cannot silently change an attached |
| 19 | +source. Removing an attachment, changing workspace, or starting a new conversation |
| 20 | +clears pending page context. Several explicitly attached pages can support comparison. |
| 21 | +Assistant accepts page snapshots while retaining its existing restriction on |
| 22 | +workspace-resource contexts. |
| 23 | + |
| 24 | +The extension does not promise complete capture of virtualized documents, canvas |
| 25 | +editors, restricted browser pages, inaccessible cross-origin frames, or PDFs. |
| 26 | +Extraction failure is visible; the model must never infer absent page content. |
| 27 | +Browser interaction, autonomous navigation, screenshot OCR, and native-app control |
| 28 | +are separate capabilities requiring their own permission and execution contracts. |
| 29 | +Existing Sim server tools remain subject to their existing authorization and approval. |
| 30 | + |
| 31 | +## Ownership and data flow |
| 32 | + |
| 33 | +1. `apps/extension`: packaged MV3 service worker, side-panel host, bounded content |
| 34 | + extraction, per-site permission controls, build artifacts, browser verification. |
| 35 | +2. `packages/browser-extension-protocol`: versioned, strictly validated messages and |
| 36 | + immutable page snapshots shared by the extension, app, and server. |
| 37 | +3. `apps/sim/app/extension`: session gate, workspace picker, minimal app providers, |
| 38 | + real chat components, history and a narrow parent-window bridge. |
| 39 | +4. Existing chat context pipeline: `browser_page` input validation, durable message |
| 40 | + projection, restored context chips, untrusted-content formatting, Assistant admission. |
| 41 | +5. Existing Sim API and Mothership: authentication, authorization, billing, tool |
| 42 | + execution and streaming; no alternate inference service or extension API key. |
| 43 | + |
| 44 | +The content script returns text to its extension caller. The extension verifies the |
| 45 | +captured document still belongs to the intended tab, then sends a typed snapshot to |
| 46 | +the exact hosted frame. The frame validates its parent origin and identity, and puts |
| 47 | +the snapshot into pending UI context. The existing send path persists it with the |
| 48 | +message and passes quoted content to Mothership. A page snapshot grants no access to |
| 49 | +other workspace resources or browser-control tools. |
| 50 | + |
| 51 | +## Permission and lifetime rules |
| 52 | + |
| 53 | +- Required browser capabilities: side panel, scripting, active tab, context menus, |
| 54 | + and short-lived session storage for selection handoff. Required host access is |
| 55 | + limited to the configured Sim origin. |
| 56 | +- Other HTTP(S) origins are optional grants requested for the current site from a |
| 57 | + user gesture. Each grant can be revoked. Keeping the panel open is not a grant |
| 58 | + to read every subsequently selected tab. |
| 59 | +- No history, bookmarks, cookie API, debugger, network interception, native |
| 60 | + messaging, external messaging, or arbitrary remote code execution. |
| 61 | +- No always-running page reader. Extraction is tied to an explicit attachment action. |
| 62 | +- Page bytes are not written to extension local/sync storage. Temporary context-menu |
| 63 | + handoff uses trusted-context session storage, expiration and navigation cleanup. |
| 64 | +- Sent snapshots become chat data and follow Sim's chat retention and deletion |
| 65 | + policy. This must be disclosed in the interface and store listing. No claim of |
| 66 | + zero retention is made once a message is sent. |
| 67 | +- No page content or full page URL in extension telemetry or routine logs. |
| 68 | + |
| 69 | +## Boundary controls |
| 70 | + |
| 71 | +- Package all privileged JavaScript. The hosted iframe has no extension API access. |
| 72 | +- Only exact configured Sim origins and exact configured extension IDs are trusted. |
| 73 | + Both directions validate source window, origin, protocol version and message shape. |
| 74 | + There is no arbitrary fetch, JavaScript, navigation or extension-API command bridge. |
| 75 | +- `BROWSER_EXTENSION_IDS` is a bounded comma-separated list of Chrome IDs. Missing |
| 76 | + or malformed configuration disables embedding. Only `/extension` and its children |
| 77 | + receive the corresponding frame policy; ordinary app pages keep their frame denial. |
| 78 | +- Extension pages use a restrictive CSP; the hosted app keeps its app CSP with only |
| 79 | + the embedding ancestor list changed. Sign-in happens in a top-level tab. |
| 80 | +- Allow HTTPS production app origins; HTTP is development-only on loopback. |
| 81 | +- Capture uses bounded traversal and output size, skips hidden and editable/form |
| 82 | + content, and records truncation. It never serializes the entire DOM or reads |
| 83 | + cookies, browser storage, input values, or page-world JavaScript state. |
| 84 | +- Validate snapshots again server-side, including headless execution paths. Bound |
| 85 | + individual and aggregate text/byte sizes. Only HTTP(S) source URLs without embedded |
| 86 | + credentials are accepted; URL secrets should not be carried as source metadata. |
| 87 | +- Snapshot content is explicitly untrusted quoted JSON. This is a model cue, not |
| 88 | + an authorization mechanism: tool access remains independently enforced by Sim. |
| 89 | + |
| 90 | +## Verification planned before implementation |
| 91 | + |
| 92 | +The credible failure modes are cross-origin/frame message forgery; schema-version |
| 93 | +confusion; hostile URL metadata; hidden/form data leakage; unbounded DOM traversal; |
| 94 | +selection or extraction delivered after navigation; stale context on workspace |
| 95 | +switch; persistence mutating the captured text; Assistant silently dropping context; |
| 96 | +and an embed exception accidentally allowing unrelated app pages to be framed. |
| 97 | + |
| 98 | +Use a real Chromium extension against controlled HTTP pages for extraction, |
| 99 | +navigation, permission and message-boundary checks. Emit a caller-configured JSON |
| 100 | +report and screenshot/trace artifacts. Security-boundary tests may cover header |
| 101 | +isolation and durable-context semantics where the running app needs unavailable |
| 102 | +services. Do not replace real Chrome APIs with mocks and describe that as E2E. |
| 103 | + |
| 104 | +The authenticated live-app acceptance gate is: sign in, choose a permitted workspace, |
| 105 | +capture a real page, receive a grounded Mothership answer, reopen the conversation, |
| 106 | +stop/reconnect streaming, switch workspaces, and verify access denial. An absent |
| 107 | +backend or account is an unverified gate, not a pass. |
| 108 | + |
| 109 | +## Research and decisions |
| 110 | + |
| 111 | +- [Glean sidebar](https://docs.glean.com/user-guide/apps/extension-sidebar) and |
| 112 | + [page permissions](https://docs.glean.com/user-guide/apps/why-does-the-chrome-extension-ask-for-those-permissions): |
| 113 | + page context can use address and text without indexing the page. Adopt explicit |
| 114 | + page attachment alongside the existing Sim knowledge and tool experience. |
| 115 | +- [Chrome activeTab](https://developer.chrome.com/docs/extensions/develop/concepts/activeTab) |
| 116 | + and [optional permissions](https://developer.chrome.com/docs/extensions/reference/api/permissions): |
| 117 | + temporary access follows user invocation; cross-origin navigation requires fresh |
| 118 | + authority. Request persistent access per site only when selected by the user. |
| 119 | +- [Chrome extension security](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure) |
| 120 | + and [OWASP extension guidance](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html): |
| 121 | + minimize privileges and treat all incoming page messages as attacker-controlled. |
| 122 | + Do not expose a generic privileged bridge. |
| 123 | +- [Service worker lifecycle](https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle): |
| 124 | + workers are disposable. Stream from the app document; bound temporary handoffs |
| 125 | + independently of worker globals. |
| 126 | +- [Storage and cookies](https://developer.chrome.com/docs/extensions/develop/concepts/storage-and-cookies): |
| 127 | + extension frames have special partition and cookie behavior. Reuse Sim sessions, |
| 128 | + verify enterprise policy and blocked-cookie cases, and show a top-level sign-in |
| 129 | + recovery path instead of copying credentials into extension storage. |
| 130 | +- [MV3 remote-code policy](https://developer.chrome.com/docs/webstore/program-policies/mv3-requirements): |
| 131 | + isolated remote frames are permitted subject to review and user-data rules. All |
| 132 | + privileged capture and message logic remains packaged and inspectable. |
| 133 | +- [User-data disclosures](https://developer.chrome.com/docs/webstore/program-policies/user-data-faq): |
| 134 | + local processing of website content still requires disclosure. Publish actual |
| 135 | + data handling and permission justifications with the store submission. |
| 136 | + |
| 137 | +## Release scope and remaining expansion |
| 138 | + |
| 139 | +Planning estimate for one engineer familiar with Sim: 5–8 engineering days for |
| 140 | +the core surface, context pipeline and security boundaries; 2–4 more days for |
| 141 | +authenticated deployment QA, enterprise cookie-policy checks and release packaging. |
| 142 | +These are estimates for production readiness, not a promise that a working local |
| 143 | +build has completed those gates. Chrome Web Store review is an external timeline. |
| 144 | +Richer document adapters and screenshot capture are roughly another 1–2 weeks; |
| 145 | +autonomous browser actions need a separate design and estimate. |
| 146 | + |
| 147 | +The first implementation targets Chrome MV3 and a configured Sim deployment. It |
| 148 | +includes the shared chat UI and engine, explicit page/selection context, Assistant |
| 149 | +context support, workspace/history navigation, permission controls and verification. |
| 150 | +It does not constitute store publication or proof of every third-party site's DOM. |
| 151 | + |
| 152 | +Follow-on work: screenshot/image attachment through existing authorized upload paths; |
| 153 | +document-specific adapters with measured coverage; Firefox/Safari shells; managed |
| 154 | +enterprise distribution; and separately authorized browser-action tools. Each must |
| 155 | +retain the same source, identity, consent and lifecycle boundaries. |
0 commit comments