OS-level autofill. No cloud account required.
ChromVoid plugs into the native autofill surface on each platform. Passwords flow to apps and browsers, but access control stays in the local Core. Nothing leaves the device.
Back to main siteThe native OS surface stays a thin layer above the local Core.
Familiar autofill behavior — but the trust boundary ends at your device.
One security model across platforms
Android and Apple each use their native autofill surface. The access policy stays in ChromVoid Core regardless of platform.
Autofill from an open vault
Open the vault, and the OS pulls credentials directly from ChromVoid. No second copy in a cloud-managed provider.
Policy-gated credential matching
Candidates are matched by domain or app context. If the access policy says no, the secret is not delivered — even if metadata is visible.
A secret leaves the vault only after the full local check chain passes.
Candidates may look like familiar autofill, but the real secret handoff still depends on a deterministic local contract instead of a hidden background cache.
Local Core
The request is accepted only from the local OS adapter on the same device.
Core reachable
The provider surface verifies that Core is reachable before the chain can continue.
Vault open
If the vault is locked, ChromVoid does not unlock it in the background on the OS behalf.
Provider enabled
The provider can be disabled explicitly, which closes the secret-delivery path completely.
Context allowed
The app or domain context must pass policy evaluation inside the provider session.
The secret travels only through a short-lived provider session.
After `credential_provider:getSecret`, there is no standing cache that survives outside the open-vault lifecycle.
Strictly local-only transport
The provider does not open a remote channel. No WebRTC, no WSS, no relay. Secrets stay on the device.
Five-gate check chain
A secret is delivered only when all gates pass: `local_core && core_alive && vault_open && provider_enabled && allowlist_ok`.
No persistent cache
Secrets pass through a short-lived provider session. There is no standing cache that outlives the vault lifecycle.
How it works
The OS triggers the provider surface first, then ChromVoid verifies the local Core state and opens a short-lived provider session without background unlock.
Enable provider, local Core only
The provider path is strictly local. No WebRTC, no WSS, no USB transport, no remote gateway.
Unlock vault before autofill
If the vault is locked, the provider fails closed. ChromVoid does not unlock in the background on behalf of the OS.
Metadata first, secret on policy pass
The candidate list exposes only metadata. The actual secret requires a valid provider session and a passing policy check.
Limits and prerequisites
This feature does less than a cloud provider on purpose — the trust boundary is narrower.
Limits and prerequisites
- No remote-provider mode. Autofill requires a local Core on the same device.
- The provider does not unlock the vault in the background. There is no persistent secret cache.
- Exact autofill UX differs between Android and Apple because each platform controls its own provider surface.
Autofill without expanding your trust boundary
Keep the vault local, unlock it deliberately. The OS asks ChromVoid for credentials only when your policy allows it.