TOTP codes in Chrome. Your secrets never leave your device. No host permissions.
Install ·
Website ·
How it works ·
Security ·
Privacy ·
FAQ
A privacy-focused TOTP authenticator for Chrome. Your secrets, account names and codes never leave your device: accounts are stored by the browser, and optionally synced through your own Google account — see Where your data lives. The extension does check in with our server once a day with an anonymous install id and a handful of numbers, for the free plan and Pro — see What is sent to our server.
Features
- TOTP code generation (SHA-1, SHA-256, SHA-512; 6 to 10 digits, 7 included — it is issued in the wild). Counter-based HOTP is deliberately refused rather than stored as TOTP, which would look healthy and never once be valid.
- QR code import from image upload, the visible tab, or a camera
- Right-click a code field on any site to insert the code for it, or anywhere else on the page to copy it, without opening the popup (see Inserting a code into a page)
- Websites for an account — tie an account to the sites it is for (Edit
Account → Websites, or right-click it → Use on this site). There it is
pinned first and filled without asking; each subdomain can have an account
of its own (see Which account a site gets)
- Optional password protection — AES-256-GCM encryption of every account
record and backup, with a recovery code so a forgotten password is not a
dead end (see Password protection)
- Passkey unlock — open a password-protected vault with Touch ID, Windows
Hello or your phone through the WebAuthn PRF extension, with no new permission
(see Unlocking with a passkey)
- Share an account's codes by link, for five minutes to an hour — the link
carries pre-computed codes, never the secret, and there is no server behind
it (see Sharing codes by link)
- Open where you need it — the toolbar icon can open the popup, a floating
window, or Chrome's side panel; the last two stay put while you switch tabs,
which a popup cannot do because it closes as soon as it loses focus
- Groups and pins — sort accounts into groups and filter the list by them;
create, rename, reorder and delete groups, move many accounts at once, and
pin the ones you use most to the top. Group names, their order and pins live
inside the account records, so password protection encrypts them too
- Right-click an account to copy, pin, move, share, edit or delete it; from
the keyboard, Enter in the search box copies the first match and the arrow
keys walk the list
Permissions
The extension requests the minimum permissions required for its functionality:
| Permission | Reason |
|---|
storage | Store accounts and settings in chrome.storage (local, session and optional sync) |
activeTab | Read the current tab's hostname to highlight the matching account, capture the tab for QR scanning, and — only when you pick the right-click item — insert a code into that tab |
contextMenus | Add "Insert 2FA code" to the right-click menu on text fields, and "Copy 2FA code for this site" everywhere else on a page |
scripting | Run the insert routine in the tab, for that one invocation, under the activeTab grant the click provides |
sidePanel | Open the app in Chrome's side panel, when you pick that in Settings → Open as. It grants the extension nothing about the browser or its tabs: it is what lets an extension page be docked beside them |
Camera scanning needs no manifest permission: it uses the browser's standard
camera prompt on an extension page, granted per extension origin and revocable
in site settings. It is never requested until the scanner is opened.
The extension does not request:
host_permissions of any kind- Content scripts — nothing of this extension is declared to run on any page,
and nothing of it is running on a page you have not invoked it from
tabs, cookies, webRequest, or any other broad permissions
This means the extension cannot read or modify any page on its own. Two
things happen on your instruction and nowhere else: under activeTab it reads
the active tab's hostname while the popup is open, to highlight the account
matching that site — switchable off in Settings, which also erases the history
it collected — and it inserts a code into a page when you pick it out of the
right-click menu.
Inserting a code into a page
Right-clicking a text field offers one item, "Insert 2FA code"; right-clicking
anywhere else on a page offers "Copy 2FA code for this site", which puts the
same code on the clipboard and never types it into a field. Both are removable
in Settings. The same action has a keyboard shortcut, Ctrl+Shift+Y
(⌘⇧Y on macOS), which can be changed or cleared at
chrome://extensions/shortcuts. Choosing either is what grants activeTab: for
that one invocation, in that one tab, the extension may put the code for the
site into the field you clicked. The grant ends with the invocation, nothing is
left behind in the page, and no code of ours runs there again until you ask
again.
Which account a site gets
An account can carry websites, set by hand: Edit Account → Websites, or
right-click the account with the page open → Use on that site. They are
stored as hostnames, www. dropped, inside the account record — so password
protection encrypts them, and exports and cloud backup carry them. A website
covers itself and its subdomains, and the most specific one wins: with
main.com on one account and sub1.main.com on another, sub1.main.com gets
only the second, and main.com or sub2.main.com only the first. An account with
websites is never guessed for any other site.
Websites outrank everything below, and they count even with suggestions
switched off — that setting is about what is learned and guessed, and a site
you typed in is neither. One account on the site is inserted without asking;
several are all pinned at the top of the popup, and inserting picks the one
you used there before, or asks.
Without websites, which account is chosen is deliberately conservative. An account you have
already used on that site wins — inserted into a field there, or picked when
this asked you which account the site wanted. Failing that, the site's name has
to match exactly one account. Anything less certain — several plausible
accounts, none at all, or a locked vault — opens the popup and lets you pick,
because these forms often submit themselves on the last digit and a wrong code
spends one of the few attempts the service allows.
A code copied out of the popup is deliberately not treated as evidence about
the site behind it. Codes get copied for things that are not the page at all —
a VPN client, an SSH prompt, a phone — so a copy never displaces the account a
site names, and never authorises inserting anything on its own.
If the field will not take the code — some sites build their inputs in ways no
insertion survives — it is copied to your clipboard instead and a note in the
page says so. The fallback is the point: the worst case is the paste you would
have done anyway.
Password protection
Password protection is optional and off by default. With it off, account
records are stored unencrypted in chrome.storage.local, protected by the OS
user account and the Chrome profile — the same model as most authenticator
extensions. With it on:
| Property | Value |
|---|
| Cipher | AES-256-GCM (random 96-bit IV per record) |
| Key derivation | PBKDF2-HMAC-SHA256, 600,000 iterations, 128-bit random salt |
| Master key | 256-bit random, generated once; the password only wraps it |
| Fingerprints | HMAC-SHA256 under an HKDF subkey of the master key |
| Unlocked key store | chrome.storage.session (memory only, cleared on browser exit) |
| Auto-lock | Every open / 5 / 15 / 60 min idle / until browser closes |
Design notes:
- Two-level keys. Data is never encrypted with a password-derived key
directly. A random master key encrypts the records; PBKDF2 output only wraps
that master key. Changing the password rewrites 32 bytes rather than
re-encrypting every record — the bulk rewrite is where data gets lost.
- Recovery code. A 160-bit code independently wraps the same master key, so
a forgotten password is recoverable. It is shown once, must be typed back to
confirm, and is rotated after each use. A reset writes nothing until the
replacement code has been typed back, so until then the old password and the
old code both still work.
- What is encrypted. The entire account record except its
id and
fingerprint — including the service name, so a stolen profile leaks no
metadata about which services the user has accounts with.
- Backups too. IndexedDB snapshots store the already-encrypted records.
Enabling the vault wipes every pre-existing cleartext copy (local, sync and
all snapshots) after a decrypt-and-compare round trip verifies the encrypted
data reads back identically. Verification happens before anything is deleted.
- Export files carry their own salt and a password chosen at export time,
independent of the vault, so a backup stays openable on a machine that has no
vault configured.
Threat model. This protects data at rest: a stolen profile directory, an
infostealer that exfiltrates browser data, or account records reaching Google's
servers through Chrome sync. It does not protect against malware running as
the user while the vault is unlocked, or a keylogger capturing the password.
Crypto lives in src/utils/crypto.ts and
src/utils/vault.ts; no cryptographic primitive is
hand-rolled — all of it is WebCrypto.
Unlocking with a passkey
Available once password protection is on, and off until you add one. A passkey
becomes a third wrapper around the same master key, alongside the password
and the recovery code.
| Property | Value |
|---|
| Mechanism | WebAuthn prf extension, eval.first over a 256-bit stored salt |
| Key derivation | HKDF-SHA256 over the 32-byte PRF output, info = authenticator-vault-passkey-v1 |
| Relying party | the extension's own origin; no host permissions |
| User verification | required — presence alone must not release the wrapper |
| Stored in metadata | credential id, PRF salt, wrapped master key. Never the master key or the PRF output |
Design notes:
- Additive, never exclusive.
attachPasskey only ever adds a wrapper;
nothing in the codebase removes wrappedByPassword or wrappedByRecovery. A
lost passkey costs convenience, not accounts — a passkey-only vault would be a
new way to destroy every seed.
- Verified before it is written. The wrapper is built, unwrapped again and
compared byte for byte with the key it came from, all in memory. Only a match
reaches storage, so an authenticator that cannot reproduce its own PRF output
never leaves behind a wrapper that opens nothing.
- A password change does not break it. Only the password wrapper is rebuilt;
the master key is unchanged, so the passkey keeps working. Covered by a test,
because the failure would have been silent until the day it mattered.
- It runs in its own window.
src/passkey/ is a full
extension page, opened with chrome.windows.create({type: 'popup'}) — no
permission required. Chrome destroys the action popup on focus loss and the
authenticator prompt takes focus, so the ceremony cannot complete inside the
popup at all; a window keeps it a dialog rather than an opened tab, and falls
back to a tab if the window is refused.
- Uneven platform support is expected. PRF is solid on Android, Windows 11
25H2+, macOS 15+ and iOS 18.4+, and absent on Firefox for Android. The setting
hides itself where the API is missing and reports the case where an
authenticator declines PRF rather than failing obscurely.
- The popup listens instead of polling. The ceremony happens in another
context, so the popup subscribes to
chrome.storage.onChanged: a session
change re-reads the lock state, and a vault_meta change re-reads whether a
passkey is registered. Without this the popup sat on its lock screen with the
vault already unlocked behind it until it was closed and reopened, and the
settings panel kept offering to add a passkey that already existed. After a
successful unlock the ceremony window also tries chrome.action.openPopup()
— best effort, since it needs a user gesture that the biometric prompt may
have outlived and does not exist before Chrome 127 — and then closes itself.
- A one-shot hand-off crosses the context boundary. The ceremony page is a
separate JS context, and with auto-lock on every open the unlocked key is
deliberately never written to
chrome.storage.session — so without a hand-off,
registering a passkey is impossible on that setting and unlocking with one
silently does nothing. Both were reproduced before the fix.
and pass the key once, under a separate session key, with a
two-minute expiry; it is deleted on first read, refused when stale, and cleared
by . That keeps what auto-lock actually promises — the key
does not outlive the popup that used it — while letting a biometric prompt in
another window count as the authentication event for exactly one popup.
Implementation: src/utils/passkey.ts (ceremonies only,
holds no key material) and the passkey functions in
src/utils/vault.ts.
Credential Exchange Format
CXF is the FIDO Alliance's JSON interchange format for credentials. It covers
TOTP secrets as well as passkeys, which makes it the first format this extension
can both write and read that other vendors also speak.
- Export: a third option next to the plain and password-protected files.
- Import: recognised automatically, so there is no format to choose.
- The secret is written as plain RFC 4648 Base32, byte for byte as stored. A
test asserts the exact string, because a re-encoding bug here produces
confidently wrong codes rather than a visible failure.
- Every credential of every item is examined on import. Password managers
put a TOTP credential in the same login item as the password; walking only the
first would drop the 2FA half of the file.
- One bad row never costs the file. Unreadable entries are counted and
reported; the rest import.
CXP, the protocol half of the standard, is deliberately not implemented: it
negotiates provider-to-provider transfer through the operating system, which an
extension cannot do. Implementation: src/utils/cxf.ts.
Sharing codes by link
A link that shows another person a live code for one account, for a limited
time, in any browser and with nothing to install. Implementation:
src/utils/share.ts; the page that opens it lives in the
site repository at authenticator.sh/s.
- The secret never leaves the device. TOTP is deterministic, so the codes
for the next hour can be computed now and handed over on their own. The link
holds that run — one code per period — and nothing that could produce a code
after it. The time limit is not a rule the page enforces; it is the absence
of any further codes.
- An hour is the maximum, and the page refuses longer runs. An hour of
six-digit codes is about 550 characters: readable as a QR code from a screen,
which is the one way to pass a link that leaves no copy in a messenger's
cloud, and short enough for email clients that wrap at 998 characters.
- There is no server. The whole payload travels in the URL fragment, which
browsers never send to a host. Nothing is uploaded when a link is made and
nothing is stored when it is opened, so there is no database of shared codes
to breach and no revocation that would be theatre.
- Optional password. Without one, the sixteen random bytes in the link are
the key (HKDF-SHA256). With one, the key is PBKDF2 of the password salted
with those bytes — the same stretching as the vault — so the link alone and
the password alone are each useless. The two-byte header that says "ask for a
password" is authenticated with the body, so it cannot be flipped in transit.
- The two sides share a fixture, not code. The extension seals links and
the site opens them;
test/fixtures/share-vectors.json pins the exact bytes
for six cases and both repositories assert against it.
Building from Source
Prerequisites
- Node.js 20.x LTS
- npm 10.x
Build
npm ci
npm run build
The resulting dist/ directory is the unpacked extension.
Load in Chrome (development)
- Open
chrome://extensions/
- Enable Developer mode
- Click Load unpacked and select the
dist/ directory
Development
npm run dev
Tests
npm test
npm run verify # typecheck + npm test + check:deps
npm run verify needs internet access: its last step, check:deps, talks to
the real time sources the extension depends on (that is its whole point — see
scripts/check-deps.ts), so offline it fails even when the code is fine. Run
npm run typecheck && npm test for the offline part.
npm run build && npm run check:bundle # check the built package in dist/
npm run test:e2e # the built extension in real Chromium
check:bundle reads the build rather than the source: it walks the service
worker's static imports and fails if any file it reaches contains import()
(Chrome refuses it in a service worker), and it checks that the manifest, the
default locale, the icons and every HTML page the extension opens are in the
package.
test:e2e builds into .e2e-build/ — never dist/ — and loads that unpacked
into Chromium with Playwright: adding an account and reading it back from
chrome.storage.local, the code on screen against one computed independently,
a delete seen from a second window, Undo, and a service worker that starts
without errors. The first run needs the browser: npx playwright install chromium. External network is blocked inside the tests.
End-to-end scenarios for the storage and vault paths — enabling, locking,
password change, recovery-code reset, encrypted export, disabling — run against
real WebCrypto with chrome.storage and IndexedDB mocked. These cover the code
where a bug means permanent loss of a user's 2FA seeds, so they run the real
modules rather than stubs.
The passkey suite covers the wrapper rather than the WebAuthn ceremony, which
cannot run under Node: a stand-in PRF output proves that adding a passkey never
removes the password or recovery wrapper, that a password change and a
recovery-code reset both leave it working, and that neither the master key nor
the PRF output is ever written to metadata.
Verifying the Chrome Web Store Build
To verify that the version published on the Chrome Web Store was built from this source code:
- Download the
.crx for the published version from the Chrome Web Store
- Unzip it to a directory
- Check out this repository at the matching git tag (e.g.
v1.13.2)
- Run
npm ci && npm run build using Node 20 LTS
- Compare the
dist/ directory contents with the unzipped .crx
Differences should only exist in:
- File ordering inside zips
- Whitespace differences in minified output across Node patch versions
For each release we publish SHA256SUMS-v<version>.txt — a SHA-256 for every file in the produced dist/ — in GitHub Releases. It is in sha256sum format, so you can check your own build against it directly:
cd dist && sha256sum -c ../SHA256SUMS-v1.13.2.txt # shasum -a 256 -c on macOS
Architecture
src/
├── background/
│ ├── service-worker.ts # MV3 service worker: install/uninstall URLs, menu, shortcut
│ ├── quick-fill.ts # Right-click flow: pick account, generate, inject
│ └── quick-fill-page.ts # The only code that ever runs in a page (injected on demand)
├── popup/
│ ├── App.tsx # Main UI
│ └── index.tsx
├── scan/
│ └── App.tsx # Camera QR scanner (own tab — see the file header)
├── passkey/
│ └── App.tsx # Passkey ceremony (own tab — the popup dies on focus loss)
├── components/ # React components
├── hooks/
│ ├── useAccounts.ts # Account state + auto-backup
│ ├── useVault.ts # Lock/unlock state
│ └── useTOTP.ts # TOTP refresh loop
├── utils/
│ ├── crypto.ts # WebCrypto primitives (PBKDF2, AES-GCM, HKDF)
│ ├── vault.ts # Vault lifecycle: unlock, auto-lock, recovery, passkey
│ ├── passkey.ts # WebAuthn PRF ceremonies (no key material)
│ ├── storage.ts # Local-primary storage, encryption layer, retry
│ ├── backup-file.ts # Plain and password-protected export formats
│ ├── cxf.ts # Credential Exchange Format read/write
│ ├── auto-backup.ts # IndexedDB backup rotation (7 latest)
│ ├── vault-prompt.ts # When to offer password protection
│ ├── time-sync.ts # Optional clock-drift check
│ ├── totp.ts # TOTP via OTPAuth
│ ├── qr-parser.ts # QR decoding
│ ├── migration-parser.ts # Google Authenticator export parser
│ ├── suggestions.ts # Which account belongs to the site you are on
│ └── screen-capture.ts # captureVisibleTab wrapper (activeTab only)
└── types/
Network Access
The extension never sends your secrets, account names, issuers, codes or the sites you use them on in a form we can read — Pro's cloud backup, if you turn it on, sends your accounts end-to-end encrypted. Two kinds of request happen automatically — the cached clock check and the daily billing check-in, both below — and a third with cloud backup on; everything else happens because you clicked something. In full, the outbound HTTPS calls are:
| URL | When | Purpose |
|---|
https://www.authenticator.sh/welcome?iid=<install id> | First install | Opens welcome page in a new tab. The site passes the install id to our server only for a browser that came from one of our ads, to tell which campaign led to installs that went on to use the extension; it never goes to Meta. The page may ask the extension to open its popup — the one message the extension accepts from any web page (externally_connectable, authenticator.sh only, src/background/site-open.ts); the reply says only whether it opened, and whether its icon is pinned to the toolbar (so the page does not explain the puzzle menu to someone who does not need it) |
https://www.authenticator.sh/uninstall?i=<install id>&s=<stage> | After uninstall (Chrome API) | Opens feedback page, which reports the removal to our server by that id, with how far a new install got towards a first account (opened, pick:ga, fail:camera:camera_denied…), and links an optional answer to it |
https://api.authenticator.sh/v1/sync | Once a day (browser start or popup open, after it has rendered); in a new install's first three days also within minutes of a step towards a first account | Check-in — see What is sent to our server |
https://api.authenticator.sh/v1/checkout, /v1/license/*, /v1/portal | User starts a purchase, enters a key, restores a purchase or manages a subscription | Pro |
https://api.authenticator.sh/v1/backup/* | Cloud backup is on and the list changed (popup open); Settings → Backup & Restore opened with Pro or with cloud backup on (the list of copies); or the user turns it on or off, backs up, restores or starts over | Pro cloud backup — encrypted copies, see Cloud backup |
https://checkout.stripe.com/…, https://billing.stripe.com/… | User starts a purchase or manages a subscription | Stripe Checkout and customer portal, in a new tab |
https://chromewebstore.google.com/.../reviews |
Camera scanning uses getUserMedia on an extension page opened in a tab. That
needs no manifest permission — it goes through the browser's standard camera
prompt, granted per extension origin and revocable in site settings. It is
never requested until the user opens the scanner.
The clock-drift requests are unauthenticated GETs that carry no user data and
are cached. Any two of the three agreeing is enough, so one host going offline
does not disable the check — and when none of them can be reached, Settings
says so rather than reporting a clock it never measured. No fonts, scripts, or styles are loaded from remote
hosts — everything needed to render the popup is bundled.
Free and Pro
Installations that existed before billing (1.14.0) keep unlimited accounts.
New installations may have a limit on how many accounts they hold for free —
our server decides whether there is one and how high it is; Pro removes
it. The limit only ever stops adding an account: every account you have
keeps working, exporting, backing up, restoring and syncing with or without
Pro, and nothing is ever hidden or locked.
- The limit is checked on your machine from the last policy our server
signed, so it works offline: a limit already received still applies without
a connection. Until the extension has reached our server once, nothing is
limited — and nothing is again once it has not reached it for 14 days, until
it does.
- An account the limit stops on its way to Checkout is kept in memory (see
chrome.storage.session below) and added by itself once Pro turns on; it is
dropped after a day, when the browser closes, or when you choose not to add it.
- Pro is a license signed by our server (ES256) and checked with WebCrypto
against the public key in
src/billing/keys.ts. A subscription's signed
license lasts offline for up to 60 days at a time and is renewed silently
whenever the extension is online; it never runs past the paid period plus
two weeks (plus one day if renewal was cancelled). A lifetime license lasts
half a year at a time, renewed the same way.
- When Pro is offered to an installation, it appears in Settings → Pro.
Buying happens on Stripe Checkout in a new tab; Stripe (through Link) is the
merchant of record. Pro turns on by itself in the browser you bought it in,
which is then sent the license key; while Chrome sync is on, the key goes to
Chrome Sync and your other Chrome profiles turn Pro on by themselves. On
another computer, enter the license key (
2FA-XXXXX-…) from the success
page or the email under Settings → Pro.
- The code is open source, so the limit is there for honest users — it is not
DRM, and a fork can remove it.
Cloud backup (Pro, off until you turn it on)
Pro can keep an end-to-end encrypted copy of your accounts on our server,
so losing the computer does not mean losing the codes. It is off until you
turn it on in Settings → Backup & Restore, and it is the only feature that
sends your accounts to us — encrypted with a key we never see (the daily
check-in sends only their number).
- Turning it on shows a backup recovery code (
XXXXX-XXXXX-XXXXX-XXXXX,
about 101 bits from the browser's random generator) and asks you to type it
back before anything is stored; closing the popup meanwhile keeps the same
code. The copies are encrypted with AES-256-GCM under a key derived from that
code with HKDF-SHA256 (src/billing/cloud-backup.ts). The code is kept in
this browser and, while Chrome sync is on, in your Google account so your
other Chrome profiles can open the same copies. It is never sent to us: we
cannot open the copies, and cannot recover them if the code is lost.
- With password protection on, the stored code is itself encrypted under the
vault's key — sealed the moment protection is turned on, opened again when
it is turned off — so the copies cannot be fetched and opened from this disk
without your password.
- One code per license. The server keeps the current code's
kid (a short
hash that tells a device which code a copy needs) and a hash of auth, a
second value derived from the code that proves a device holds it. It refuses
a copy under any other code and after cloud backup was turned off, and a
browser told so forgets its code and asks for the current one.
- A copy is sent when you turn it on, when you press Back up now, and
otherwise when the extension opens and what it holds — including records it
cannot read, such as another vault's — differs from the last copy that
browser sent. Typing the code on a new browser first merges the newest copy
into it (adding only what is missing), and sends a copy only if that browser
held accounts the copy lacked — the two lists together — so a new browser's
partial list never becomes the newest copy. Each time a
copy arrives the server keeps the 20 newest, the newest of each hour of the
last day, the newest of each day for 30 days, and the newest from each of
the 10 most recently active browsers, and deletes the rest.
- Sync between devices (from 1.16.0). Each browser also reads the newest
copy of every other browser on the license — when the list opens, when you
come back to its window, and every few minutes while it stays open, never
more than once a minute — and folds in what changed
(
src/utils/cloud-merge.ts): the newer edit of an account wins, a deletion
removes an account only if it was not edited after it, and an account
missing from another browser's copy is never removed for that. Deletions
travel inside the encrypted copy, as hashes of the deleted keys with their
time. To tell the browsers apart the server labels each copy in that list
with a tag (a hash of the license and the installation that sent it), and so
it sees when a browser with cloud backup on asks for the list — not what
any copy holds.
- Restoring by hand only adds accounts that are missing, like the automatic copies. On
another computer: activate the license key, then enter the backup recovery
code. After Pro has ended: finds the copies with the key; the backup recovery code opens them.
What is sent to our server
Once a day — and, in a new install's first three days, within minutes of a
step towards a first account (at most every five minutes, src/billing/onboarding.ts) —
the extension sends https://api.authenticator.sh/v1/sync exactly
these fields (src/billing/sync.ts, buildSyncRequest; a test holds it to the
list):
| Field | What it is |
|---|
iid | A random id created by this installation. Not linked to your Google account, email or browser — unless you buy Pro: then the purchase record links the installation you bought from, and any installation where your license key is active, to the email you paid with |
ver, ui_lang, browser_lang | Extension version, interface language, browser language |
installed_at, legacy, legacy_src | When this installation appeared, and whether it predates billing |
accounts | How many accounts you have — a number, never which ones |
groups | How many groups those accounts are in — a number, never their names (from 1.15.2) |
vault, sync, open_mode, view_mode, style, dark, os | Whether password protection and sync are on, how the extension opens, how the account list is shown (normal, compact, hidden), which of its two styles it is drawn in, light or dark, and the operating system as Chrome names it (win, mac, linux, cros…) |
pid, lid | Which policy and license this installation currently holds |
has_key, key_hint | Whether this installation holds a license key, and the last four characters of it. The installation Pro was bought on is sent its key in the response (key) until those four characters match it — so a key bought later replaces an older one; one where a key was typed in already has it and is never sent one |
opens | How many times the extension was opened on each day since the last check-in (at most the last 14 days) — a count per day, nothing about what was looked at |
events | Up to 50 queued events from a closed list (src/billing/events.ts). Billing: the limit was reached, the paywall was shown or closed, a plan was chosen, a checkout or a key was tried, a banner or a notification behind the bell our server set was shown, clicked or closed (its id, action and place), the bell was opened (how many notifications it held and how many were new). The way to a first account: first open, whether the welcome page asked the extension to open and it did, the "add your first account" screen shown and the way picked on it, each add screen reached, each error shown or add left (as a kind — , — never what was scanned or typed), accounts added and by which way, the first code copied or filled in. Never an account's name, issuer, secret or site |
The server sees the request's country (from its edge, the IP address is not
stored). If you buy Pro, Stripe gives us your email address, to send and
restore your license key, and keeps the install id you bought from in the
purchase's metadata. Retention and your rights are in the
privacy policy.
Where your data lives
| Store | Contents | Default |
|---|
chrome.storage.local | Accounts (encrypted when password protection is on), settings, and — only while password protection is off — the per-site usage history | Always used; primary |
chrome.storage.session | The unlocked master key, the selected group filter and the per-site usage history; and an account the free limit stopped on the way to Checkout, until Pro turns on (sealed with the vault's key when password protection is on) — memory only, cleared when the browser closes | Only while unlocked; a stopped account for a day at most |
chrome.storage.sync | A copy of the accounts and the vault metadata, replicated by Chrome through the user's own Google account | On, switchable off |
| IndexedDB | Seven rolling snapshots, in the same form as the primary store | Always used |
chrome.storage.local (billing*) | The install id, the last signed policy and license, the license key this installation holds — typed in, or received after buying on it — and queued billing events and daily open counts — no account data | Always used |
chrome.storage.sync (billingLegacy, billingLicenseKey) | Whether this person predates billing, and the license key this installation holds — so their other Chrome profiles pick both up and turn Pro on by themselves | Only while sync is on; removed with the rest when sync is switched off, and put back when it is switched on again |
chrome.storage.local + chrome.storage.sync (cloudBackupCode) | The cloud backup's recovery code — encrypted under the vault's key when password protection is on | Only after turning cloud backup on; the sync copy only while sync is on, removed with the rest when sync is switched off |
Our server (/v1/backup/*) | Cloud backup copies, encrypted in the browser with a key we never receive; kept as described in Cloud backup | Only after turning cloud backup on (Pro) |
Two consequences worth stating plainly:
- With password protection off, accounts sit in sync in the clear, which
means Chrome replicates them to Google. That is the user's own Google account
and we never see them, but it is not "on the device only". Turning password
protection on encrypts them before they are ever handed to sync; turning sync
off in Settings stops the replication and removes what is already there.
- The per-site usage history is not covered by the vault while it is being
collected. Enabling password protection deletes it, and it can be switched off
independently.
We never receive your secrets, account names or codes in a form we can read: cloud backup, if you turn it on, sends them encrypted with a code we never see. What our billing server does receive is listed in What is sent to our server.
Security
See SECURITY.md for the responsible disclosure policy.
Report security issues to [email protected] — please do not open a public issue for security bugs.
Contributing
Bug reports and pull requests are welcome. Please read CONTRIBUTING.md before submitting, and the Code of Conduct for how we expect people to treat each other here.
Docs
Technology
- React 18, TypeScript, Tailwind CSS
- Vite (build)
- OTPAuth (TOTP/HOTP)
- jsQR (QR decoding, lazy-loaded)
- Lucide React (icons)
License
MIT
