Autofill without trusting the browser.
The extension is a thin client. It reaches Core through Desktop Gateway on localhost — secrets, policies, and grants never leave Core. Nothing is cached in the browser.
Back to main siteThe extension detects username, password, and OTP fields, but the commands start from the ChromVoid popup. Extension controls are not injected into the form DOM.
Browser-grade UX without turning the browser into the vault.
This page explains why the extension still feels like familiar autofill while refusing to become a second secret store inside the browser profile.
Localhost-only transport
The extension cannot reach WebRTC, WSS, or a cloud relay. Desktop Gateway on `127.0.0.1` is the only entry point.
Zero-cache runtime
No secrets persist in extension storage. The browser holds only pairing and grant metadata with explicit TTL boundaries.
Scoped grants, normalized errors
Core controls grant scope: session, site, or single action. Error responses are normalized — the browser learns nothing about vault state or secret existence.
One request path, one localhost boundary, one policy authority.
Every request takes the same route: page and popup go through the service worker, Desktop Gateway brokers the call, and Core decides whether a short-lived grant can exist.
Explicit PIN pairing
Open the pairing link or scan the QR code. The desktop shows a one-time PIN. Trust is established via PIN-derived `XXpsk0` — no silent background enrollment.
Single service worker broker
All extension contexts route requests through the service worker. Traffic goes to the localhost gateway — no separate channels to Core.
Core issues scoped grants
Desktop Gateway asks Core to validate origin, vault state, and user confirmation. Core responds with a session, site, or single-action grant.
Access revoked on lock or expiry
Vault locked, session expired, or pairing revoked — the extension loses access immediately. No fallback cache for “offline convenience”.
What stays in the browser, and what must stay outside it.
The architecture is explicit by layer. The browser gets interface convenience; Gateway gets brokering; Core keeps the secrets and the policy decisions.
UI boundary
The extension lives inside the browser runtime, so its contract stays narrow: render the interface, send the request, receive the answer.
- Stores only pairing and grant metadata with explicit TTLs.
- Provides popup, autofill, and TOTP without a local browser vault.
- Cannot talk directly to cloud relays, WebRTC, or the phone.
Local broker
Desktop Gateway is the only entry point on `127.0.0.1`. It brokers every service-worker request and prevents the browser from growing a side channel.
- Brokers all extension traffic through localhost.
- Separately checks reachability, authorization, and session state.
- Loses access immediately on lock, revoke, or grant expiry.
Policy and secrets
Core remains the only place where secrets, policy, and grant decisions exist. Even error responses are shaped to avoid proving too much.
- Validates origin, vault state, and user confirmation.
- Issues session, site, or single-action grants.
- Normalizes errors so the browser cannot prove secret existence.
Limits and prerequisites
Real constraints to know before you build your workflow around the extension.
Practical workflows
- The extension requires Desktop Gateway running on the same machine. It is not a standalone browser-only password manager.
- The extension does not replace OS credential providers. For system-wide autofill outside the browser, use Credential Provider separately.
- Remote and phone-backed sessions still route through desktop localhost. The extension does not pair with the phone directly.
Browser workflows without browser trust
Install the extension for in-browser autofill and TOTP. Add Credential Provider separately if you need OS-level autofill outside the browser.