The Browser Can Be the Courier Without Becoming the Vault

Autofill makes a password manager look simpler than it is.

You open a login page, choose an account, and the username and password appear in the right fields. The entire operation feels like one step:

Vault in, password out.

Underneath, several different systems have to cooperate. A vault decides which credential exists. A policy layer decides whether the current site may use it. A browser extension identifies the active page. A content script writes values into the document. The page then receives those values and sends them to the service.

Those systems do not deserve the same level of trust.

A browser extension can be a useful delivery layer without becoming the durable home of the vault. But it cannot make the destination page trusted, and it cannot honestly claim that the browser never sees a password that it fills.

The useful question is therefore not:

Are password manager browser extensions safe?

It is:

Which job does the extension own, what does it learn, and for how long?

The Short Version

A password manager extension does not need a permanent local copy of every credential in order to provide autofill.

It can instead:

1. identify the current site;
2. ask an authoritative local process for matching credential metadata;
3. wait for an explicit user action;
4. request the selected credential's password or a chosen one-time code for that context;
5. verify that the active tab and origin still match the captured values;
6. deliver only the requested result; and
7. close the short-lived provider session.

That is the boundary ChromVoid is designed around.

Availability note — July 29, 2026: ChromVoid currently labels the browser extension as Alpha. It requires Desktop Gateway on the same computer as the browser, and usable platform coverage depends on the current build matrix. See the Browser Extension page and download matrix before planning a setup around it.

The extension is not a second vault. It talks to a local gateway, while Core retains authority over vault state, credential matching, secret access, and lock behavior.

This reduces durable browser state and limits the scope of each read. It does not create zero exposure.

When autofill succeeds, the password is present in the destination page's DOM. A compromised page, browser, extension environment, or operating system may be able to observe it during that session. Local-first custody reduces some exposure paths; it does not make a live compromised endpoint safe.

Storage, Authorization, and Delivery Are Different Jobs

The phrase "the password is in the browser" can describe several very different states.

The first is durable custody. A browser profile or extension database holds a reusable encrypted copy of the vault. It may remain there across browser restarts, profile backups, extension updates, and long periods without the desktop application.

The second is temporary authorization. The extension has permission to ask for a particular action or secret during a bounded session.

The third is momentary delivery. A password moves through extension memory and into the destination field because that is the actual purpose of autofill.

Collapsing these states into one word hides the most important design choices.

Avoiding durable custody does not eliminate delivery. A login page cannot submit a password it never receives. Conversely, the fact that the page receives one password does not mean the browser needs a searchable, persistent copy of the entire vault.

That distinction is the foundation of a thin-extension architecture.

A Content Script Is Isolated, but the DOM Is Shared

Modern browsers give extension content scripts an isolated JavaScript world. Variables created by the page are not automatically visible to the extension, and variables created by the extension are not automatically visible to the page.

That isolation is useful, but it is easy to overread.

Chrome's documentation explains that content scripts run in an isolated world while still using the standard DOM to read and modify the page. Mozilla's WebExtensions documentation describes the same practical boundary: content scripts have their own execution environment, but they can access and change the document.

• Chrome: Content scripts
• MDN: Content scripts

An autofill extension relies on that shared document. It finds an input, assigns a value, and emits the events the page expects.

Once the password is in that input, it is no longer protected merely because the content script used an isolated JavaScript world. The destination page is supposed to receive the value. Page code may process it, validation scripts may inspect it, and the form may submit it.

This is why "the browser never sees your password" is too broad a promise for browser autofill.

A more defensible promise is narrower:

The browser does not have to become the durable source of truth for the vault.

Autofill Is a Security Decision, Not Just a Convenience

Autofill can reduce one common risk: users no longer need to type or paste a credential into a page that does not match the saved site. Domain matching can act as a useful phishing signal.

But autofill also performs a sensitive action inside a complex environment. The extension has to decide:

• which origin is active;
• which saved URLs match it;
• whether a subdomain or iframe is acceptable;
• whether the user intended to fill or only inspect an item;
• whether the active tab changed while the secret was being fetched; and
• whether the value should be copied, filled, or withheld.

The broader industry has been making these boundaries more visible.

Bitwarden documents that autofill on page load is disabled by default because an untrusted page could take advantage of it. Its manual autofill paths also apply URI-matching and iframe checks.

Bitwarden: Autofill from Browser Extension

1Password's current browser-autofill guidance describes clickjacking as a way to trick a user into interacting with an autofill element. It also makes an important bounded claim: this does not expose an entire vault, but a deceptive page may try to induce a fill of one matching item.

1Password: About the Security of Autofill in Your Browser

That is a useful way to reason about browser security. The relevant question is not whether a boundary is perfect. It is how much authority one interaction has and how far a failure can spread.

The ChromVoid Browser Path

ChromVoid treats the browser extension as a high-risk convenience layer. It is allowed to deliver a requested password or one-time code, but it is not allowed to redefine where the vault lives or which layer owns secret policy.

The current implementation follows this path:

Several details matter here.

The Gateway Is Local

The extension accepts only an explicit set of local gateway hosts: chromvoid.local, localhost, 127.0.0.1, and ::1.

It does not connect directly to an internet relay or treat a hosted browser service as the vault. Remote access, when used, remains behind the desktop gateway and the active Core context.

This is an endpoint allowlist, not proof that the resolved service is trustworthy. A compromised local machine can attack loopback services, and local-name resolution is part of the endpoint boundary. Pairing, channel authentication, command policy, vault state, and endpoint security still matter.

Candidate Metadata Comes Before the Secret

The extension can ask for the credentials that match the current web context without receiving every password.

A candidate contains the information needed to present a choice: identifier, label, username, domain, match information, and available OTP profiles. The password or chosen one-time code is requested separately, only for the selected credential and site context.

This separation keeps search and selection from becoming secret-export operations.

A Secret Read Uses a Single-Use Session

Before reading a password or one-time code, the extension opens a provider session. Core checks the credential and context, returns the requested result, and consumes that session.

Reusing the same provider session for a second secret read fails. Locking the vault also makes new provider operations fail closed.

The provider session is not a timeless token that silently turns into standing browser access. It is a narrow authorization step for one read.

The Tab Is Checked Again

Fetching a secret is asynchronous. During that small interval, the user can switch tabs or the page can navigate.

ChromVoid captures the expected tab and origin before the read, checks the active tab again afterward, and passes the expected origin to the content script. The content script compares that value with location.origin before writing anything.

If the active tab ID or its origin differs at that final check, nothing is filled.

This narrows a classic time-of-check/time-of-use problem, but it does not bind the fill to a specific browser document or frame. The current message is addressed by tab ID without a documentId or frameId. A same-origin navigation can replace the document without changing the values being checked, and another frame with the same origin is not distinguished by the origin comparison.

Chrome supports targeting tabs.sendMessage() by document or frame, but that targeting is not part of the current path. The accurate claim is therefore that ChromVoid rechecks the active tab and origin—not that it proves the identity of the exact document receiving the message.

Chrome: tabs.sendMessage() targeting

Credential Values Do Not Become UI State

The popup model uses the password to complete the requested action, but does not add it to the reactive candidate list, selected-item state, or feedback state.

The extension does persist a paired Noise transport identity. That identity is sensitive and must be protected and revocable, but it is not a credential database or a copy of the vault.

This is a more precise boundary than saying the extension "stores nothing." Useful security descriptions should name the state that remains, not hide it behind an absolute.

These are properties of the current code path, not only intended architecture. Extension tests cover the active-tab handoff and exclusion of password values from popup state. Core security tests cover single-use sessions and fail-closed behavior when the vault locks. This evidence does not imply current availability on every platform.

What Zero-Cache Means Here

In this design, zero-cache means the browser extension does not become a durable credential store.

It does not need to serialize the full vault into extension storage, keep a searchable offline password database, or make the browser profile authoritative for credential policy.

The active Core remains the source of truth.

Zero-cache does not mean:

• a password never exists in extension memory;
• the destination page cannot read its own form field;
• JavaScript memory can be proven to disappear immediately;
• a compromised browser cannot observe an active fill;
• another malicious extension cannot attack the browser environment;
• an infostealer or compromised operating system becomes irrelevant; or
• an exact-origin check protects a legitimate site that is itself compromised.

The password still crosses the boundary because the requested action is delivery.

Private by architecture does not mean pretending plaintext never exists. It means making its creation narrow, intentional, and short-lived, then documenting where the guarantee ends.

Autofill Versus the Clipboard

Avoiding autofill does not automatically remove browser risk.

The usual fallback is to copy a password and paste it manually. That moves the secret through the operating-system clipboard, where clipboard history, syncing, other applications, or malware may observe it. Some password managers clear the clipboard after a delay, but clearing later does not undo earlier reads.

Autofill avoids that particular durable or cross-application path, but writes the value directly into the destination document.

The choice is therefore not:

Safe copy versus unsafe autofill.

It is a choice between delivery paths with different exposure surfaces.

For a matching site, an explicit origin-checked fill can be a cleaner boundary than a general clipboard operation. For a suspicious page, a mismatched origin, or an account that should not be used in the browser at all, withholding the credential is the better action.

AI Browsing Makes User Intent More Important

Browser automation adds another actor to the same environment.

An assistant may be able to read a page, click controls, navigate between origins, and interact with an unlocked extension. Instructions on the page may be untrusted, while the assistant is still operating with the user's browser permissions.

1Password published a separate advisory for this class of interaction. Its central observation applies beyond one product: deterministic boundaries should not depend on an AI system correctly interpreting every instruction it encounters.

1Password: Security Advisory for AI-Assisted Browsing

This makes explicit intent, checked context, narrow results, and lock state more important—not less.

An AI click should not quietly turn a thin delivery layer into a general credential API.

A Checklist for Evaluating Any Password Manager Extension

The following questions are more useful than asking whether an extension is simply "safe":

1. Where is the authoritative vault? Is the browser profile the durable source of truth, a synchronized copy, or only a client?
2. What persists in extension storage? Full encrypted vault, metadata, session tokens, pairing identity, preferences, or nothing?
3. Can credential metadata be listed without returning secrets?
4. What user action causes a secret read? Page load, field focus, keyboard shortcut, explicit click, or an automation request?
5. How are origins matched? Exact origin, host, base domain, custom rule, iframe policy, or user override?
6. Is the active tab checked again after the secret is fetched?
7. Are secret-read sessions short-lived or single-use?
8. What happens when the vault locks?
9. Does the value travel through the clipboard or directly to the DOM?
10. Can logs, error reports, reactive state, or analytics capture the value?
11. What can other extensions, page scripts, and local malware observe?
12. Are the limitations documented in a public threat model?

No answer makes the browser a trusted enclave.

The goal is to keep each layer's authority proportional to its job.

The Boundary That Remains

A browser extension is one of the most useful parts of a password manager. It is also one of the most exposed.

The answer is not necessarily to remove autofill or pretend the exposure does not exist.

The browser can be the courier without becoming the vault:

• Core can remain authoritative;
• the extension can receive metadata before secrets;
• a user action can authorize one contextual password or OTP read;
• a single-use session can limit reuse;
• tab and origin checks can reject a fill when that context no longer matches; and
• durable browser storage can avoid containing the credential database.

Then the password reaches the DOM.

That last step is not a design failure. It is the job the user requested. The security boundary is honest only when it says so.

ChromVoid's public Threat Model describes the broader trust boundary and its endpoint-compromise assumptions.