Local-First Security Architecture & Threat Model

Most password managers are cloud-first: your vault lives on a server, and you pull it down on demand. RabbitKey inverts this. Your vault lives on your device. Everything else — sync, backup, recovery — is layered on top of that foundation. What follows is what that means for security, and what the actual threat model looks like.

Where Your Data Lives

The vault — the encrypted file containing your credentials — is stored locally on your device. There is:

  • No RabbitKey account
  • No RabbitKey server that holds your data
  • No analytics or telemetry collection
  • No cloud dependency for the app to function

If you choose to sync, you connect RabbitKey to your own cloud storage (iCloud Drive, Google Drive, or WebDAV). Only the encrypted vault file is uploaded. RabbitKey's servers are not in the data path — because there are no RabbitKey servers. For how sync preserves this property, see How Zero-Knowledge Sync Works.

This is not a policy statement. It is an architectural fact. RabbitKey cannot see your data because RabbitKey has no infrastructure through which your data passes.

The Threat Model

What an Attacker Can Reach

Depending on the attack surface, an attacker might obtain:

  • The encrypted vault file — from your device storage, a backup, or your cloud provider. This is ciphertext encrypted with XChaCha20-Poly1305 under a master key that is itself wrapped by your password-derived key. Without your master password, Recovery Kit, or biometric unlock, it is computationally infeasible to decrypt. See How RabbitKey Encrypts Your Vault for the crypto details.
  • Your cloud storage — if your iCloud or Google Drive account is compromised, the attacker gets the encrypted vault file. Same result: ciphertext only.
  • Your unlocked device — physical access to an unlocked device, or malware with the same level of access, can reach the vault in memory. This is true of any local-first app. Device security (strong device passcode, auto-lock, biometrics) is the relevant control here.

What an Attacker Cannot Reach via RabbitKey

  • Plaintext credentials — never transmitted, never stored unencrypted
  • Your master password — never leaves the device
  • Metadata about what is in your vault — there is no server-side index, no usage logs, no syncing of entry titles or counts to any RabbitKey service (because no such service exists)

Supply-Chain and Account Compromise

Because there is no RabbitKey account, there is no RabbitKey account to compromise. An attacker who breaches a hypothetical RabbitKey backend gains nothing — the only sensitive data is on your device, encrypted with keys only you hold.

Why "We Can't See Your Data" Is Structural

Many services claim they "can't see" user data by policy or contract. The claim is only as strong as the policy and the company's ability to honor it under legal compulsion or breach.

RabbitKey's claim is different: the architecture provides no pathway for plaintext data to reach any RabbitKey infrastructure. The statement "RabbitKey cannot read your vault" is equivalent to "the ciphertext we never receive cannot be decrypted without a key we never hold." It does not depend on trust in the company — it depends on trust in the cryptography and in the open implementation.

The Tradeoff: Recovery

Local-first with strong encryption has a cost: if you lose your master password and have no other way to prove ownership, your vault cannot be recovered through normal means — not by you, not by RabbitKey.

RabbitKey gives you two escape hatches, both of which you set up in advance. The Recovery Kit is a 69-character code that encodes your master key directly; possessing it allows vault restoration without the master password, and you must generate and store it yourself. Biometric unlock lets you reopen the vault with Face ID or Touch ID — but it is bound to the device where you configured it and does not transfer to a new device, so it is an everyday-access convenience, not a portable recovery method.

Full details are in Your Recovery Kit, Explained. The short version: if you have neither your master password, nor a Recovery Kit, nor biometric unlock configured, the vault is unrecoverable. This is not a bug — it is the correct consequence of the cryptographic design.

Platform Notes

RabbitKey is available now on iOS. Android, macOS, and Windows versions are in development. The local-first architecture applies on all platforms: the vault stays on the device regardless of which OS hosts it.

Summary

Property Value
Vault storage On-device only
Accounts required None
Data sent to RabbitKey None
Analytics / telemetry None
Sync providers User's own iCloud / Google Drive / WebDAV
Plaintext ever leaves device Never
Recovery if master password lost Recovery Kit or biometric unlock; otherwise vault is unrecoverable