Privacy Policy

• Your secrets, encrypted. Passwords (with the notes and password history saved alongside them), passkey private keys, the text of your notes and your authenticator (2FA) secrets are encrypted on your device before they are saved or synced. The Coauth servers hold them only as ciphertext and never hold a key that can open them. • Readable details. To sync your vault and offer the right login on the right site, the server stores these in readable form: each login's site, the login page address, its username, nickname and folder; the site and account name of each passkey; the service and account name of each authenticator entry; note titles; and team names and membership. • Identity. When you create an account, I receive your email address and a user ID (via the authentication provider, Supabase) to create your account and sync your vault. You can sign in with Google, or with a one-time code sent to your email address. If you use Google I never receive your Google password. If you use an email code, no password is stored at all. • Team data. Team names, membership, roles, and an activity log of team actions, needed to make sharing work. • Invites. The email address you invited and a one-way hash of the invite link's token, never the token itself. Alongside it Coauth stores a copy of the team key encrypted with a key derived from that token, so the person you invited can open it and I cannot. An invite expires 48 hours after it is sent. Because the link carries that encrypted key, treat an invite link like a password: do not forward it. • Billing, if you upgrade. Your plan, the subscription's status and renewal date, and the customer ID the payment processor gives you (see Payments below).

To work as a password manager, Coauth's content script reads the username and password fields of a login form, only to (a) offer to save them after you submit (you click Save) and (b) autofill them when you pick a Coauth suggestion. It also renders Coauth's overlay during a passkey ceremony. It does not read other page content, and it transmits nothing without your action.

By default Coauth stays unlocked on your computer so autofill and passkeys keep working: the key that opens your vault is kept on the device's disk until the vault has been idle for 30 days. Anyone who can read your browser profile on that computer during that time could read that key. To avoid this, turn on "Lock when the browser closes" in Settings. The key is then kept in memory only, and you unlock again after each browser restart.

The breach check runs only when you start it. For each password, Coauth computes a SHA-1 hash on your device and sends only the first 5 characters of that hash, through Coauth's own server, to the range service of Have I Been Pwned. The service answers with every known breached hash that starts with those 5 characters, and Coauth looks for a match on your device. Your password and its full hash never leave your device.

Pro is billed through Dodo Payments, which processes the payment and handles your card details. Coauth never sees or stores your card number. Dodo tells Coauth whether your subscription is active and when it renews, so Pro can be switched on for your account. Dodo's own privacy policy covers what it collects to take a payment.

Coauth sends three kinds of email through Resend: sign-in codes, team invites, and onboarding tips and reminders. Every tips email has an unsubscribe link. Sign-in codes and team invites keep coming after you unsubscribe, because Coauth needs them to work.

To understand where new users get stuck during setup, Coauth records a few anonymous product events (for example: the popup was opened, sign-in was started, passkey setup failed). Each event carries a random installation ID generated on your device, the event name, the extension version and, for some events, a short non-secret detail, such as which sign-in method was used, what kind of item was shared, or an error message with personal details removed. It is never linked to your Google identity, email, vault, passwords, passkeys, or the sites you visit, and it never includes any secret. I use it only to fix drop-off in onboarding, and the data is write-only from the app: an individual user's events cannot be read back out. The page that opens after you uninstall asks why you left. If you answer, the reason you pick and anything you type are stored with the same installation ID.

The Coauth pages on buildifyapp.in use Google Analytics, through Google Tag Manager, to count visits and see which pages people read. The extension itself contains no Google Analytics. Invite links, the unsubscribe page and the page you return to after checkout do not load it, because their web addresses carry private tokens or your email address.

• I do not collect your browsing history or read pages beyond login fields. • I do not sell or rent your data to anyone. • I do not use your data for advertising, profiling, creditworthiness, or lending.

Coauth is zero-knowledge: the Coauth servers never hold a key that can decrypt your vault. Your vault is locked with a key derived on your device from any of three factors: the vault password you choose at setup (the default since version 1.2.5), a device passkey such as Windows Hello or Touch ID if you add one (WebAuthn PRF), and a recovery key that only you hold. Each factor unlocks the same vault, and none of them is ever sent to me. All secret material is encrypted with audited cryptography (libsodium) before it is stored locally or synced, so your secrets reach the Coauth servers only as ciphertext. Team-shared items use a per-team key generated on a member's device and sealed individually to each member's public key. The plaintext team key never touches the server. A breach of the backend would expose the readable details listed above, plus encrypted data that cannot be opened without your keys. The next section covers the one way a vault password changes that.

A passkey and a recovery key cannot be guessed. A password you can remember can be. The encrypted form of your password factor is stored in the vault data that syncs, so if the database were ever breached, an attacker could take that ciphertext away and try to guess your vault password offline, at their own pace, with no rate limit I can impose. That is not true of the passkey or recovery factors, and it is the one way in which choosing a password is weaker. Two things reduce it, and neither is optional: • Your password goes through Argon2id, a deliberately slow and memory-hard function, before it ever becomes a key. Each guess costs an attacker real time and 64 MB of memory rather than being free. The cost parameters are stored per password, so they can be raised later without locking anyone out. • Coauth refuses a weak vault password rather than warning you about it, and the check runs where the key is derived, so the interface cannot skip it. This is the same position every password manager that offers a master password is in. If you would rather not accept it, choose Windows Hello or Touch ID instead of a password when you set up, keep your recovery key, and do not add a password: the choice is yours, and a vault with no password factor has nothing guessable in it.

Encrypted vault data, team data, and account records are stored with Supabase (Postgres), region ap-south-1. Every night a scheduled job copies the encrypted database to separate storage outside Supabase, as a backup. Authentication is handled by Supabase Auth, either through Google or through a one-time code emailed to your address. Emails are delivered by Resend, and payments are processed by Dodo Payments.

• webAuthenticationProxy: to act as a passkey authenticator so passkeys can be created, used, and shared. • identity: used for the optional Google sign-in, to create your account and sync your vault. Signing in with an emailed code does not use this permission. • storage: to store your encrypted vault and settings. • activeTab: to show which of your logins and passkeys match the site you are currently on. • Host access to the backend: to sync your encrypted data. • Content script on all websites: to save and autofill logins on the sites you use, and show the passkey overlay. This is what Chrome describes as "read and change data on all websites" when you install. Coauth needs it to fill and save passwords on the sites you log into; it reads only login fields.

I do not sell or rent your data. It goes only to the services that run Coauth, each for its own job: • Supabase: the database, sign-in and the server functions Coauth uses. • A separate storage service: the nightly encrypted backup. • Resend: delivering emails. • Dodo Payments: billing, if you upgrade. • Have I Been Pwned: the first 5 characters of password hashes, when you run a breach check. • Google Analytics: visits to the Coauth pages of this website, not the extension. Team-shared items go only to the members of the teams you add them to, encrypted.

• Sign out to lock the vault and stop Coauth from handling passkeys. • Turn on "Lock when the browser closes" in Settings to keep the vault key off the disk. • Remove a personal passkey, or unshare a team passkey, at any time from the popup. • Unsubscribe from tips and reminders with the link in any of those emails. • Delete your account and data: email me and I will delete your account records and vault data.

Your account and vault data are kept until you delete your account. Team data is removed when the team is deleted. Audit-log entries are retained for the life of the team.

Coauth is not directed to children under 13 and I do not knowingly collect their data.

If I make material changes I will update the "Last updated" date at the top of this page. Material changes will be noted in the extension.

Questions or data-deletion requests? Email kalpesh@buildifyapp.in. I respond to every real message.