Browser extension overview

The VaultTerm browser extension is a password manager for Chrome, Edge (Chromium) and Firefox. It matches saved logins to the sites you visit, fills them, captures new logins as you create them, and generates one-time codes.

Where the secrets are

The extension keeps an encrypted copy of your vault on the device, so a fill is a local decrypt rather than a round trip, and it works with the browser offline. The organization keeps control of that copy:

• The copy is sealed under a key the server issues. The key is bound to (you, this device, your organization), carries a lifetime, and can be withdrawn — from your own account settings, by an org admin, or by an organization policy that turns offline copies off entirely. Once it is withdrawn or lapses, the copy is wiped on the device’s next sync.
• The lifetime is the backstop, not the main control. Withdrawing a key is what normally ends a copy, and it works on any device that comes back to us. The lifetime is what covers the devices that never do — an uninstalled extension, a wiped laptop, a machine that never reconnects — because on those, nothing we send can reach the copy and only the clock ends it. It defaults to 14 days and an organization can set anything from 1 hour up to a maximum of 30 days.
• A device that keeps in touch is not signed out when the lifetime runs down. While it is still in good standing, its key’s expiry is pushed out quietly on an ordinary sync — the same key, so the copy on the device stays readable and nothing is asked of you. Withdrawal still wins over this: a key that has been revoked, a device that has been revoked, or an account that has been deactivated is not renewed, and the copy is wiped on the next sync as before.
• Unlock releases the key, and nothing else does. Offline, unlock is the account password (a browser extension has no keychain to hold a key behind a fingerprint); online, the local biometric unlock gate applies — see Install and unlock.
• Offline unlock carries across a key replacement, but not indefinitely. A renewal keeps the same key and costs you nothing. A replacement — the key lapsed or was revoked, so the server mints a new one — has to re-anchor your offline unlock to the new key, and the extension does that without asking for your password. That carry is bounded: two key replacements, or 45 days, whichever comes first, counted from the last time you entered your account password, which resets both. Past either bound offline unlock is dropped rather than extended, and the popup says so. See Install and unlock.
• The limits on the copy cannot be edited on the device. The key’s expiry and your organization’s reveal-recording policy are stored with the copy, and they are signed under the same key that seals it. Editing them in browser storage does not extend the copy or relax the policy — it makes the copy refuse to open offline until the device reaches VaultTerm again, which restores the real values. Nothing is erased by that refusal.
• What you may do with each vault is stored with the copy too. Alongside the credentials, the copy records which vaults you could read and change when the server last said so, and the moment it said it. That is what lets the extension answer “may I edit this?” with no connection — it repeats the server’s answer rather than forming one of its own. See Changes you make offline for how far that answer is trusted.
• Every reveal is still recorded. A fill served from the local copy is written to a sealed, hash-chained journal on the device and handed to the server on the next sync, where it becomes an ordinary audit entry. If those records cannot be handed over within the window your organization sets, the extension stops filling from the copy until they are. An organization can also require the strict behaviour — no local reveals at all, so the audit record is always written before the secret is handed over. See Audit logs.
• Some items never go into the copy. Injection-only credentials and honeytokens are listed without their value on purpose. A honeytoken costs a live, audited reveal; an injection-only credential is refused on every reveal path, so the extension cannot fill it at all. That flag keeps the secret out of the extension, not out of the broker — see SSH broker overview for what it does and does not prevent.

This matches VaultTerm’s overall posture: an audited access broker, not zero-knowledge. The server can decrypt your secrets for an authorized session, and so can the key it issued to your device. Envelope encryption and no-plaintext-at-rest apply the same way they do in the web app.

Changes you make offline

Editing a credential, or capturing a new one, goes to the server first. When the server cannot be reached, the change is saved into the encrypted copy on the device and uploaded on the next sync — which means the extension has to decide whether you were allowed to make it, with nobody to ask.

• It decides from the rights stored with the copy, and there are three answers. If those rights say you may write to the vault, the change is saved locally and queued. If they say your access is read-only, it is refused and nothing is queued. If the copy holds no rights it can act on for that vault, the extension says it cannot confirm your access — deliberately not the same sentence as a refusal, and there are three separate reasons for it, below. In both refusal cases nothing is queued and nothing is shown as saved, because a parked change is the same act with a delay on it.
• There are three reasons it can say it cannot confirm, and it tells you which. They withhold the same controls but they are not the same situation, and two of them name something you can do:
  • Never confirmed — no sync has ever carried your rights for that vault to this browser. Signing in to VaultTerm while you are online is what fixes it; nothing done offline will.
  • The offline window lapsed — this browser held real rights and your organization’s window ran out. Reconnecting restores them.
  • No offline window — your organization allows no offline access decision at all. Reconnecting restores the controls; waiting never will.
• The window is your organization’s, not the extension’s. Stored rights are trusted for the same period your organization allows a device to sit on unreported offline reveals — the age limit described in Audit logs. An organization that sets that limit to zero (strict mode) gets no offline decision at all, so nothing can be saved from the extension while it is offline. A browser that has never been told the policy uses a much shorter window of its own.
• Deleting still needs a connection. A credential that exists on the server is never deleted from the queue: offline, the deletion is refused outright rather than shown as done on this device while it stays live everywhere else. The one exception is a credential that has never reached the server — discarding its queued creation really is the whole deletion.
• The server re-authorizes every queued change, and it is the authority. A right stored on the device can be withdrawn by an admin while the browser is offline, so a “yes” given from the copy can be out of date within its window. Nothing is settled on the device: when the change reaches the server it is authorized again, from the server’s current state. If it is refused because your access changed, the change is dropped rather than retried, the local view rolls back to what the server holds, and the extension’s sync panel tells you your access to that vault changed while you were offline. Pending changes are counted there until they land.

The offline decision exists so the extension stays usable without a connection — it is not the access control boundary. The boundary is the server, and it is applied when the change arrives.

What it does

• On-site match detection and autofill. The extension detects login forms on the current page, finds the credentials that match the site, and fills them on request.
• Capture new logins on submit. When you sign in or create an account, the extension can detect the submitted credentials and offer to save them to the vault.
• Built-in TOTP authenticator. Time-based one-time codes (RFC 6238) are generated in the extension for accounts that have a TOTP seed stored, so you do not need a separate authenticator app — see Secret types.
• Phishing / look-alike-domain guard. A deterministic check flags homograph, punycode, typosquat, TLD-swap and brand-embedding domains before you hand over a credential. The classification runs locally and needs no network egress.

Permissions model

The extension requests optional host permissions rather than install-time permissions. It ships with no broad site access; when a feature needs to read or fill a page, you grant access in the popup, and the extension registers its content scripts dynamically at that point. This keeps the default permission footprint small and makes store review fast. Site access can be granted broadly or per site, and features resume immediately after a grant.

Where to go next

• Install and unlock — set up the extension and its device-bound unlock.
• Autofill matching — when a credential is offered versus filled automatically, and how equivalent-domain groups and subdomains are matched.
• Settings and security dashboard — manage enrolled devices, review activity and configure auto-lock.
• Credential Vault — where the secrets the extension fills actually live.