Seed renders websites with the Chromium version bundled in our Electron release. Chrome ships security fixes every week or two, often for bugs attackers already use. Electron supports its latest three major versions, and today Seed desktop is behind that line, so the bundled Chromium has not received security fixes since May 2026. In the last year Electron was bumped twice.

Move to a supported Electron now, and commit to a maximum lag behind Electron's stable security releases.

Make auto-update fast and reliable, and sign update manifests so the update channel cannot be used against us.

Add a kill switch: when the bundled Chromium is older than the policy allows, the pane turns off and links open in the user's real browser.

The daemon's localhost API is the most valuable thing on the machine. It must authenticate the desktop app and refuse requests that come from web pages, whatever browser they are in. Browser-side rules about local networks are a second layer, not the first: they differ between Chromium versions, and we measured that they cannot be relied on in the pane as it is today.

Listen on loopback only by default.

Give the desktop app a per-launch secret and require it on every call that reads private data or writes anything. Public content stays public.

Replace the open cross-origin policy with an allowlist of the app's own origins.

Keep a test that runs a page from a public address and proves it gets refused.

Websites run in an Electron web view inside the same window as the Seed app. One renderer bug in the page must not turn into control of the app.

Guest pages get no preload script, no Node, context isolation, the Chromium sandbox, and web security on. Their settings are built from a fixed allowlist.

Pages get no permissions: no camera, microphone, location, notifications, clipboard reading, or USB, serial and HID devices.

Popups, downloads and switches to Seed pages only happen right after a real click, and downloads always show a save dialog.

Client certificates are never picked automatically, and certificate errors are always fatal.

Move the pane from the webview tag to a main-process-owned WebContentsView, so the app renderer never has web view privileges at all.

Every IPC handler and preload API in the app window has to be written as if a hostile page were one bug away. The app window today also embeds third-party iframes for video and social embeds, strips frame-protection headers for local URLs, and exposes a generic IPC bridge to the renderer. All of that needs the same review as the pane.

A browser inside the app makes the usual Electron hardening non-negotiable: Electron fuses set (no running as Node, no Node options, no CLI inspect, ASAR integrity on), macOS entitlements trimmed to what the app uses, a content security policy on the app's own pages, and a permission handler on the app's own session, not only on the browser partition.

Browsers spend years on the address bar: the real domain, the lock icon, certificate warnings, look-alike characters in domain names. The web pane today shows only a title and a favicon, and the website controls both. A page can look exactly like a Seed screen or a sign-in page.

Always show the real origin of the page, in an area the page cannot draw over.

Display look-alike (punycode) domains in their raw form.

Never let website content look like a Seed dialog, especially anything that asks to sign or publish.

HTTPS only: upgrade plain http, warn before loading a page that cannot be upgraded.

Seed has one thing Chrome does not: when a page is a Hypermedia site, Seed can verify which account it belongs to and show that identity beside the origin.

Seed recognizes Hypermedia URLs and opens them as native Seed pages. A website can use this to move the app to a Seed screen, such as site settings or an agent page, without the user asking.

Only switch to a Seed page after a real click on a link, never from a redirect or a script.

Treat a Seed page opened from the web the same as one opened from an unknown email link.

A page in the pane can try to reach localhost and the user's home or office network: the daemon, dev servers, routers, printers. The daemon fix above is the real answer for Seed's own API. For everything else, block navigation and requests from public pages to private addresses, including hostnames that resolve to them, and keep an explicit allow for addresses the user typed themselves.

All websites in the pane share one persistent storage partition, separate from the user's real browser and from the Seed app.

Users must be able to clear it easily ("Clear browsing data" exists in Settings).

Offer a private mode that keeps nothing.

Block third-party cookies, or give each top-level site its own cookie jar.

Signing in to the Seed web vault inside the pane would store web identity keys in that partition. Hypermedia URLs open natively, so this should rarely happen, but it must be checked.

Chrome, Safari and Firefox ship protections that the pane lacks:

warnings for known malware and phishing sites;

a password manager, so users do not type passwords by hand into pages that might be fakes;

content and tracker blocking;

years of tuning for permission prompts, autoplay, and abuse like popup storms.

Some of these are cheap to add with existing open components (blocklists, tracker blocking, secure DNS). A password manager is not. Without it the pane is less safe than the user's normal browser for signing in, which is one more reason to keep it a reading surface.

Letting an agent read and act on a page the user is signed in to is the biggest new risk, because a page can carry instructions meant for the agent. The rules that apply today are on the security task: off until the user allows a website, only for the user's own agents, and agents cannot open private network addresses, fill in secret fields, or post forms to other sites. Any future browser work has to keep those rules, and should add a read-only default where clicks and typing need a second approval.