DevAutOps Vault — Privacy Policy

DevAutOps Vault is a credential manager, published by DevAutOps. Questions about this policy go to support@devautops.com.

The short version

Your credentials are encrypted on your device before they are written anywhere.
DevAutOps operates no server that receives your vault. Synchronization, when you enable it, goes to the DevAutOps deployment you or your organization configure — never to us.
That deployment stores your data in two different ways, and the difference matters. Read How synchronization works before deciding what to save.
There is no analytics, no telemetry, no advertising, and no tracking of any kind in this extension. It contains no third-party SDKs.
Your data is never sold, and is never used for anything other than delivering the features described below.

What the extension handles

Every category of data the extension touches, where it comes from, and where it goes.
Data	Where it comes from	Where it goes
Site logins	Website URL, username or email, password, organization, notes, custom fields and item history — you save them, or confirm the “Remember this login?” prompt after signing in to a site.	Encrypted with AES-256-GCM and stored in the browser’s local extension storage on this device, then synchronized as described under How synchronization works.
Master password	Typed by you to unlock the vault.	Never stored and never transmitted. It is stretched in the browser with PBKDF2-SHA256 — 600,000 iterations for the vault key, and 310,000 on the older account-sign-in path still supported for existing accounts. Only the derived authentication verifier — never the password — reaches your configured DevAutOps deployment.
Vault encryption key	Derived from your master password.	Held in the browser’s session-only WebExtension storage (`storage.session`), and discarded when the browser closes, when the vault auto-locks, or when the device is locked.
Organization Secrets, mirrored on this device	Pulled from the DevAutOps deployment you configure, on a background schedule, so a secret saved on another device appears on this one.	Cached in local extension storage, encrypted with AES-256-GCM under a device key kept beside it — not under your master password. The pull runs while the vault is locked, so it cannot use a key that only exists while the vault is unlocked. This mirror is no more secret than the deployment response that produced it: treat it as readable by anyone with access to this browser profile. Each sync replaces it in full.
Cookies on sites you visit	Read via the browser cookie API.	Never leave the device, except for DevAutOps session cookies on the deployment you configure, which are exchanged once for the extension’s own session token. Cookie names are used to detect that you have an active session; cookie values of unrelated sites are not read for any other purpose.
Page form fields	Read by the content script on HTTPS pages.	Used in the page only, to find login fields and offer to fill or save. Page content is never transmitted anywhere.
Password breach check	The password you are checking.	Only the first five characters of its SHA-1 hash are sent to `api.pwnedpasswords.com` (Have I Been Pwned’s k-anonymity range API). The password itself never leaves your device, and the request carries no account identifier. On by default; switch it off under Settings → Security.
Email breach check	Email addresses saved in your vault.	Off by default. When you turn it on, addresses go to your own configured DevAutOps deployment, which queries Have I Been Pwned on your behalf.

Site logins

Where it comes from: Website URL, username or email, password, organization, notes, custom fields and item history — you save them, or confirm the “Remember this login?” prompt after signing in to a site.
Where it goes: Encrypted with AES-256-GCM and stored in the browser’s local extension storage on this device, then synchronized as described under How synchronization works.

Master password

Where it comes from: Typed by you to unlock the vault.
Where it goes: Never stored and never transmitted. It is stretched in the browser with PBKDF2-SHA256 — 600,000 iterations for the vault key, and 310,000 on the older account-sign-in path still supported for existing accounts. Only the derived authentication verifier — never the password — reaches your configured DevAutOps deployment.

Vault encryption key

Where it comes from: Derived from your master password.
Where it goes: Held in the browser’s session-only WebExtension storage (storage.session), and discarded when the browser closes, when the vault auto-locks, or when the device is locked.

Organization Secrets, mirrored on this device

Where it comes from: Pulled from the DevAutOps deployment you configure, on a background schedule, so a secret saved on another device appears on this one.
Where it goes: Cached in local extension storage, encrypted with AES-256-GCM under a device key kept beside it — not under your master password. The pull runs while the vault is locked, so it cannot use a key that only exists while the vault is unlocked. This mirror is no more secret than the deployment response that produced it: treat it as readable by anyone with access to this browser profile. Each sync replaces it in full.

Cookies on sites you visit

Where it comes from: Read via the browser cookie API.
Where it goes: Never leave the device, except for DevAutOps session cookies on the deployment you configure, which are exchanged once for the extension’s own session token. Cookie names are used to detect that you have an active session; cookie values of unrelated sites are not read for any other purpose.

Page form fields

Where it comes from: Read by the content script on HTTPS pages.
Where it goes: Used in the page only, to find login fields and offer to fill or save. Page content is never transmitted anywhere.

Password breach check

Where it comes from: The password you are checking.
Where it goes: Only the first five characters of its SHA-1 hash are sent to api.pwnedpasswords.com (Have I Been Pwned’s k-anonymity range API). The password itself never leaves your device, and the request carries no account identifier. On by default; switch it off under Settings → Security.

Email breach check

Where it comes from: Email addresses saved in your vault.
Where it goes: Off by default. When you turn it on, addresses go to your own configured DevAutOps deployment, which queries Have I Been Pwned on your behalf.

How synchronization works

When you sign in to a DevAutOps deployment, a saved login is sent to it in up to two ways, for two different purposes.

End-to-end encrypted

Your private vault copy

Created only if you have set a master password. The record is encrypted on your device with a key derived from it and sent as an opaque blob, filed under a hash of the website address rather than the address itself. The deployment stores and returns that blob and can never read it: it holds neither your master password nor the key. An account with no master password has no such key, so this copy is not created at all.

Encrypted at rest

Your organization’s Secrets copy

Always created. The login is filed in the Secrets area, so it appears on the DevAutOps dashboard next to secrets you add there, so you can share it with colleagues who need it, and so it reaches the other devices you sign in to with the same account. Values there are encrypted at rest with AES-256-GCM under a key held by the deployment, which means the deployment — and administrators who control its encryption key — can decrypt them.

That second tier is unavoidable for a shared secret: software cannot show a value on a web page, or hand it to a teammate, without being able to read it.

In short: the end-to-end encrypted copy is zero-knowledge; anything shareable is not, and cannot be. Because every saved login also gets a Secrets copy, assume any credential you save is readable by whoever controls that deployment’s encryption key. If you have a credential that your organization’s administrators must never be able to read, do not save it to a deployment you do not control.

What the extension does not do

It does not collect or transmit browsing history, page contents, analytics events, device fingerprints, location, or personal information beyond what is listed above.
It does not read or modify pages served over plain HTTP; autofill is blocked there.
It does not send your data to DevAutOps. There is no DevAutOps-operated endpoint in the code.
It does not claim your organization’s shared Secrets are hidden from your organization. They are not — see How synchronization works.
It does not sell or transfer your data to third parties, and does not use it for creditworthiness or lending purposes.

Permissions and why they are needed

storage — keeps the encrypted vault and your settings on the device.
host_permissions: https://*/* and the content script — a password manager cannot know in advance which sites you will save a login for, so it must be able to recognise login forms on any HTTPS site. Access is limited to HTTPS; HTTP pages are excluded. You can further restrict this in Chrome or Safari under the extension’s website access settings.
activeTab / scripting — injects the autofill helper into the tab you are acting on, and keeps the toolbar flow working when you set site access to “on click”.
tabs — matches the current tab’s origin against saved items so only the right login is offered.
cookies — detects whether you already have a session on a site, and performs the one-time DevAutOps session exchange described above.
alarms / idle — run the periodic security scan and auto-lock the vault when you step away.
notifications — alerts you when a saved password appears in a new breach.

Storage, retention and deletion

Vault data lives on your device for as long as the extension is installed. Removing an item deletes it (Trash holds it until you empty it). Uninstalling the extension removes all local extension storage.

If you enabled synchronization, copies remain in your organization’s DevAutOps deployment until deleted there. Your private vault blobs stay unreadable to it, because it never holds your master password. Copies in the organization’s Secrets area are readable by that deployment and are removed when you delete the secret there.

The local mirror of your organization’s Secrets described above is replaced in full by each sync and removed when you uninstall the extension. Signing out of a deployment does not by itself erase it.

Enterprise deployments

Administrators can pin the extension to one DevAutOps deployment and enforce settings via managed policy. Policy values are read from the browser’s managed storage and are not transmitted anywhere. Deployment and policy examples ship with the extension source, under docs/managed-deployment.md.

Changes

Material changes to this policy will be reflected in the “Last updated” date at the top of this page, and in the extension’s store listing, before they take effect.