Legal document
ChromVoid Security Policy
Last updated: May 13, 2026
This Security Policy explains how ChromVoid LLC ("ChromVoid," "we," "us," or "our") handles security reports, vulnerability disclosure, and the security boundaries of ChromVoid apps, browser extensions, websites, relay services, licensing, checkout, wake, analytics, support, and related services.
This policy is intended for publication at:
https://chromvoid.com/security-policy/
This policy is not a substitute for the ChromVoid Privacy Policy. App Store and Google Play privacy disclosures should continue to use the Privacy Policy and the relevant store privacy forms as the source of truth for personal-data handling.
If we publish a translated version of this policy, the English version is the source of truth unless we explicitly say otherwise.
1. Overview
ChromVoid is designed as a local-first encrypted vault for passwords, files, notes, passkeys, OTP data, SSH keys, wallet secrets, and other user-managed secrets.
ChromVoid license accounts are used for license recovery, entitlement sync, and cross-platform Pro activation. They are not a trust root for vault data. Vault encryption and decryption are designed to happen on your own devices, and ChromVoid services are not intended to receive vault contents, master passwords, vault passwords, decrypted files, passkeys, private keys, seed phrases, OTP seeds, or local autofill secrets.
Security reports should be sent to:
If GitHub Security Advisories are enabled for a public ChromVoid repository, you may also use that channel for coordinated disclosure. Email remains the canonical contact.
2. Security Model
Local-first vault processing
ChromVoid's default security model keeps vault operations on the endpoint:
- Vault contents are encrypted before storage.
- Vault encryption and decryption happen locally.
- ChromVoid LLC cannot decrypt a local vault for you.
- Lost vault passwords, master passwords, keys, recovery material, or local backups may permanently prevent recovery.
Cryptography
ChromVoid's documented cryptographic baseline includes:
- ChaCha20-Poly1305 authenticated encryption for vault storage.
- Argon2id for password-based key derivation.
- A portable
storage_pepperdesign for improved resistance to offline attacks. - Context-bound authenticated data for encrypted storage chunks.
- Noise secure channels for remote/device-to-device communication paths.
These mechanisms reduce risk, but they do not make ChromVoid unbreakable. Security depends on correct implementation, platform integrity, strong user credentials, safe update practices, and the user's operational environment.
Transport and relay boundaries
Remote, relay, sync, peer-to-peer, wake, and browser-extension flows are designed so that transport infrastructure does not need plaintext vault contents or user secrets.
Relay infrastructure may still observe limited technical metadata needed to operate the service, such as connection timing, routing identifiers, message sizes, IP-derived rate-limit keys, and service health signals. Relay and remote paths should be treated as metadata-exposed but payload-confidential when endpoint encryption is operating correctly.
App and platform boundaries
ChromVoid uses platform security controls where appropriate, including Tauri capability boundaries, Content Security Policy restrictions, operating-system credential or keystore facilities, biometric gate results provided by the operating system, and app-store or operating-system sandboxing.
Platform controls reduce the impact of many classes of bugs, but they cannot fully protect a vault if the device, operating system, browser profile, keyboard, screen, clipboard, firmware, or ChromVoid process is compromised while secrets are accessible.
Service boundaries
Optional services such as checkout, licensing, relay, wake, waitlist, analytics, and support may process limited service data. They are not intended to process decrypted vault contents. See the ChromVoid Privacy Policy for the personal-data handling details.
License account services process account sessions, recovery-code hashes, license-account bindings, and entitlement metadata. A recovery code is an account credential for license recovery and entitlement sync. It is not a vault password, does not decrypt local vault storage, and does not give ChromVoid the ability to recover local vault contents.
3. Supported Products
This policy covers security reports for:
- ChromVoid desktop and mobile apps.
- ChromVoid browser extensions.
- ChromVoid websites and public documentation.
- ChromVoid relay, wake, remote-connectivity, and sync-adjacent services.
- ChromVoid checkout, licensing, license activation, and entitlement services.
- ChromVoid waitlist, analytics, support, and operational service surfaces.
Security updates are prioritized for currently maintained public releases, active preview channels, and production services operated by ChromVoid. Older builds, unsupported platforms, obsolete operating-system versions, and third-party platform behavior may not receive the same level of support.
4. Reporting a Vulnerability
Send security reports to:
Please include as much of the following as you can safely provide:
- Affected product, platform, version, build, browser, operating system, or service URL.
- Vulnerability class and suspected impact.
- Clear reproduction steps.
- Proof of concept, screenshots, logs, or traces with secrets removed.
- Whether the issue affects vault confidentiality, vault integrity, authentication, license integrity, payment flow integrity, relay confidentiality, service availability, or user privacy.
- Whether you accessed, modified, deleted, or exfiltrated any data, even accidentally.
- Your preferred contact address for follow-up.
Do not send vault passwords, master passwords, private keys, seed phrases, OTP seeds, passkeys, decrypted vault contents, payment secrets, or other live secrets in a security report.
If you accidentally access data that is not yours, stop testing, do not copy or share it, and report the incident immediately.
5. Coordinated Disclosure
We ask security researchers to follow coordinated disclosure:
- Do not publish exploit details or proof-of-concept code before we have investigated and remediated the issue, unless we have agreed otherwise.
- We aim to acknowledge new reports within 3 business days.
- We aim to provide an initial triage response within 7 business days.
- We may ask for additional details, reproduction help, or validation of a proposed fix.
- We will provide status updates when there is meaningful progress or when the expected timeline changes.
- Public disclosure should happen after a fix is released, a mitigation is available, or a disclosure timeline is mutually agreed.
Some issues may require more time because of platform review, app-store release timing, cryptographic migration, third-party dependencies, legal obligations, or user-safety concerns.
6. Research Rules
You may test ChromVoid systems you own, accounts you control, local vaults you created, and public endpoints in ways that are necessary to validate a security issue and do not harm others.
Do not:
- Run denial-of-service, stress, load, resource-exhaustion, or destructive tests.
- Access, copy, change, delete, or exfiltrate data that is not yours.
- Attempt social engineering, phishing, spam, or impersonation.
- Target ChromVoid employees, contractors, users, payment providers, app stores, email providers, hosting providers, or other third parties.
- Bypass licensing, payment, entitlement, or rate-limit controls except to the minimum extent necessary to demonstrate a legitimate vulnerability on assets you control.
- Upload malware, ransomware, credential stealers, persistence tooling, or destructive payloads.
- Publish exploit details before coordinated disclosure is complete.
- Continue testing after we ask you to stop because of operational, legal, or user-safety risk.
This policy does not authorize unlawful activity, access to third-party systems, access to other users' data, or violation of app-store, platform, provider, or network rules.
7. Out-of-Scope Reports
The following are usually not treated as security vulnerabilities unless they demonstrate a concrete exploit path or material user impact:
- Requests to recover a lost vault password, master password, key, recovery material, or deleted local data.
- Reports based only on outdated dependency names without a reachable vulnerable code path.
- Generic scanner output without reproduction details or exploitability analysis.
- Missing security headers on non-sensitive static marketing pages, unless tied to a practical exploit.
- Clickjacking, self-XSS, clipboard, screenshot, or local-device risks that require the user to run attacker-controlled code on their own compromised device without additional impact.
- Physical access attacks, rooted or jailbroken devices, compromised operating systems, compromised browsers, keyloggers, screen recorders, malicious accessibility services, or firmware compromise outside ChromVoid's control.
- Weak user-chosen passwords or poor backup practices without a ChromVoid implementation flaw.
- Third-party platform, app-store, browser, payment-provider, push-provider, email-provider, hosting-provider, or operating-system issues that are not caused or materially amplified by ChromVoid.
We still welcome concise reports if you are unsure whether an issue is in scope.
8. Security Limitations
ChromVoid reduces certain risks, but no system is perfectly secure.
ChromVoid does not promise that it is unbreakable, impossible to compromise, impossible to analyze, or guaranteed to protect every user in every threat model.
ChromVoid does not fully protect against:
- Malware, keyloggers, screen capture, malicious browser extensions, compromised accessibility services, or compromised input paths.
- A device, operating system, browser profile, clipboard, firmware, or ChromVoid process compromised while a vault is unlocked.
- Weak, reused, phished, disclosed, or forgotten passwords.
- Lost recovery material, missing backups, corrupted local storage, or mistaken deletion.
- Coercion, legal compulsion, repeated forensic snapshots, or forced disclosure scenarios beyond the documented threat model and the user's operational discipline.
- All metadata leakage, traffic analysis, timing analysis, file-system artifacts, or service routing metadata.
- Vulnerabilities or policy changes in third-party services, app stores, platforms, operating systems, browsers, or providers.
Users are responsible for choosing whether ChromVoid fits their own risk profile, keeping devices updated, using strong credentials, protecting backups, and avoiding unsafe support or sharing practices.
9. Privacy and Support Boundary
Security vulnerability reports should go to:
Privacy requests, deletion requests, and questions about personal-data handling should use the contact route in the ChromVoid Privacy Policy:
General support channels should not be used to send secrets. Do not send vault contents, passwords, private keys, seed phrases, passkeys, OTP seeds, recovery material, or decrypted files to ChromVoid support.
10. Rewards and Recognition
ChromVoid does not currently operate a public bug bounty program and does not promise payment, rewards, swag, employment, or public credit for reports.
We may choose to thank researchers publicly when it is safe, lawful, and mutually agreed, but disclosure credit is not guaranteed.
11. Changes to This Policy
We may update this Security Policy when ChromVoid changes or when security, legal, operational, platform, service, payment, licensing, disclosure, or threat-model requirements change.
We will update the "Last updated" date when we make material changes.
12. Contact
Security reports:
Privacy requests:
Primary public domain: