Keep secrets insidea boundary you control.
ChromVoid keeps the interface outside and your passwords, files, OTP codes, notes, and separate vaults inside a private local boundary. Create as many vaults as your workflow needs.
Verified boundary signals
Architecture, limits, and attack assumptions are documented.
Choose Local mode or Mobile host.
The extension talks to localhost instead of becoming a browser vault.
USB, WebRTC, and WSS follow the same encrypted stance.
Deniability depends on device state, storage medium, and OPSEC.
Why This Exists
Modern digital convenience makes sensitive data easy to access — and easy to expose.
Most tools optimize for sync, speed, and convenience. Sensitive data then spreads across cloud services, app memory, previews, autofill, and system surfaces.
Passwords, notes, files, and codes often live inside the same exposed app surface.
Data can leak into previews, clipboard history, temp storage, autofill, and sync layers.
Most systems are optimized to open quickly — not to contain risk precisely.
Sensitive data is rarely split into separate vault spaces with different exposure levels.
Sensitive data spreads beyond the place you think it lives.
Apps, sync layers, previews, and autofill expand the exposure surface.
Most tools do not let you create real internal boundaries between different secrets.
One vault surface for daily
secrets and high-risk workflows.
Start with the familiar work: passwords, OTP, notes, and files. Then add stronger boundaries where they matter — phone-held secrets, decoy vaults, localhost-only browser access, and workflow-specific approvals.
chromvoid/vault- Connect via SSH
- Verify host key
- Elevate with sudo
- Check system status
Stronger boundaries when your threat model demands them.
Plausible vault for regular accounts and low-risk data.
Different passwords unlock different secret surfaces.
Store logins and one-time codes without cloud vault storage in the middle.
Keep sensitive documents in an encrypted vault instead of loose files.
Fill or copy secrets through a localhost extension that does not store a vault.
Use mobile host, decoy vaults, and approval flows when your threat model needs more.
One flow, from source of truth
to temporary access.
Pick where the vault lives. Surfaces connect to it as clients. Access is handed out in short-lived grants — never copied, never permanent.
What is visible is controlled.
What is hidden should not advertise itself.
Deniability is about what cannot be proven, not about hiding everything. ChromVoid supports a decoy-vault and hidden-vault model, with limits documented publicly.
One Core, explicit boundaries, encrypted transport.
ChromVoid separates UX surfaces from the place where secrets and policy live. The browser is a shell, desktop can be a thin client, and transport channels are treated as untrusted by default.
Use the same vault boundary across daily and high-risk work.
Each workflow keeps the same stance: a surface performs work, a boundary limits what it can learn, and the outcome stays useful — without moving trust into the outer tool.
You do not pay for encryption.You pay for scale and convenience.
The basic vault path is free. Pro is for extended modes when those workflows are ready. Core security mechanisms are not sold as an upgrade.
For personal use, local vaults, and the first alpha workflows.
Check the availability matrix below for current platform status.
For extended modes and higher-scale workflows. Modules activate as rollout allows.
Extended modules activate when rollout and runtime capability allow.
Encryption, KDF, and the basic security architecture are included in the basic vault path. You pay for scale and convenience.
Check which build is ready for your platform.
Builds are published as platforms become ready. The matrix below shows current alpha status — check it before planning a deployment.
Builds available for testing.
Alpha in active development.
Planned for upcoming alpha releases.
Early access builds coming soon.
Short answers before you install.
Short answers here. Full proof pages where it matters.
1.What is ChromVoid?
ChromVoid is a local-first secret vault for passwords, OTP, notes, files, and security workflows. It reduces cloud trust and supports stronger boundaries when needed.
2.How is it different from a normal password manager?
Trust lives in a local or phone-held source of truth. Cloud accounts, browser profiles, and transport paths are treated as clients or surfaces.
3.What does deniability mean here?
A decoy vault can exist beside hidden vaults. The exact guarantees depend on the public threat model.
4.Can I use it without extra hardware?
Yes. The basic vault path works on one device. Hardware tokens are optional stricter boundary tools.
5.Is this overkill for normal users?
No. Basic mode behaves like a calm local vault; stricter modes only activate when configured.
6.Does the browser extension store passwords?
No. It talks to the local Desktop Gateway and receives short-lived grants.
7.What if my storage files are copied?
Vault files are encrypted at rest. Master-password strength and key material still matter.
8.What if my device is compromised while open?
No vault fully protects a compromised live device. ChromVoid reduces specific risks; it does not replace OPSEC.
9.Are alpha builds available now?
Some platforms have alpha builds; others are in progress or planned. Check the availability matrix on the home page.
10.What is LDL?
LDL is the Lifetime Device License for Pro modules on up to three Core devices when rollout allows.
11.Where can I verify the security model?
Start with the public Threat Model, architecture diagrams, and GitHub repository.
Check whether ChromVoid alpha
is ready for your platform.
If your secrets should stay out of hosted vault storage, start with the current alpha status and inspect the public security model before installing.
No basic-security upsell.Deniability depends on the threat model.Current limitations are documented publicly.