The shortest privacy policy you'll read this year.

01What we don't collect

• No accounts, no email, no signup of any kind.
• No analytics, telemetry, or crash reporting - ever.
• No advertising IDs and no tracking.

02How your data is protected

• Field-level encryption. Every credential field - title, username, password, URL, notes, custom fields, TOTP secret - is encrypted separately with AES-256-GCM. Each field's ciphertext is bound to its row and column, so an attacker can't swap encrypted blobs between accounts.
• Memory-hard password verification. Your master password is checked using Argon2id (64 MiB memory, 3 passes) - the OWASP-recommended algorithm. Even with the encrypted blobs in hand, brute-forcing is unrealistic on consumer hardware.
• Verifier kept off-disk-readable. The password verifier and PIN hash live in EncryptedSharedPreferences, encrypted at rest by an Android Keystore-bound key. Without live access to your phone's Keystore, an attacker can't read the verifier - meaning offline brute-forcing is not possible.
• Hardware-backed wrapping. The vault key is wrapped by a key inside the Android Keystore (TEE / StrongBox on supported devices). On Android 9+ unwrapping additionally requires the device to be unlocked.
• Subkey separation. Field encryption uses HKDF-derived subkeys, not the raw vault key - so different parts of the data are encrypted under different keys derived for that purpose only.
• Memory hygiene. The unwrapped vault key only exists in memory while the vault is unlocked, and is dropped the moment auto-lock fires or you lock manually.
• Existing installs migrate automatically. Older vaults using the previous PBKDF2 verifier silently upgrade to Argon2id on the first unlock after the app update.

03Permissions we use

• Biometric - to verify your fingerprint or face for app unlock. The biometric data itself never reaches the app; we only receive a yes/no result from Android.
• Camera - only for QR-code scanning when you add a new 2FA secret, and OCR credential capture. No photos are taken or stored.
• Storage - used only on Android 12 and below for reading and writing backup files. Modern Android uses the system file picker, which doesn't require this permission.

04Permissions we don't request

• No Internet permission - the app cannot make any network request, period. You can verify this in Android Settings → Apps → 1Key → Mobile data & Wi-Fi: data usage is exactly zero, ever.
• No location, contacts, microphone, SMS, or any other personal-data permission.

05Brute-force protection

Wrong master-password and wrong-PIN attempts are tracked in persistent storage (so killing the app cannot reset the counter) and trigger escalating cooldowns:

After 3 wrong PINs, the easier PIN unlock is disabled until you successfully enter the master password.

06Threat model - what 1Key defends against, and what it doesn't

A password manager is only as useful as the threats it is honest about. The sections above describe the defences 1Key actually has. This section is the other side: things 1Key cannot stop, that you should know before trusting the app with sensitive credentials.

What 1Key defends against

• Offline attacks on a stolen or imaged device. The vault key never lives on disk in unwrapped form. The master-password verifier sits in EncryptedSharedPreferences and is unreadable without live Keystore access. Even a complete disk image, without the live Keystore, cannot be brute-forced offline.
• Brute-force password guessing. Argon2id (m=64 MiB, t=3, p=1) on every password attempt, tiered cooldowns (30 s / 5 min / 1 h) that persist across process kills, and PIN escalation to master password after three wrong PINs.
• Database tampering. Per-field AES-256-GCM with row + column AAD detects any attempt to swap encrypted blobs between accounts.
• Backup-file tampering. The .1key envelope binds the export timestamp and vault-version counter into the GCM authentication tag - swapping bodies, replaying older backups, or modifying headers all fail authentication.
• Network exfiltration. No INTERNET permission in the manifest. The OS enforces this; the app literally cannot make a network request.
• Casual shoulder-surfing of usage patterns. Screenshots, screen recordings, and the Recent Apps preview are blocked by default via FLAG_SECURE. Clipboard copies of secrets auto-clear after 30 seconds.

What 1Key does NOT defend against

These are not bugs - they are limits we want you to know about up front.

• A fully compromised device. If the OS itself is owned (root malware, a privilege-escalation exploit running with the same uid as 1Key, a debugger attached at the right moment), nothing in user-space can protect the in-memory vault key while the vault is unlocked. The app's sandbox is a guarantee from Android, not from us.
• Loss of your master password. There is no reset, no recovery code, no support email. If you forget it, the vault is gone - and so are your encrypted backups, because they are encrypted with the same password. This is intentional: the only path to recovery would be us holding a copy of your password (which we refuse to do), or a multi-secret escrow system (which would need a server we have nowhere to run). Pick a password you can remember and store it somewhere physical if you need to.
• Theft of an already-unlocked device. If someone grabs your phone while the vault is unlocked, before auto-lock fires, the unlocked vault is readable. There is no remote wipe, no kill switch we can fire from elsewhere - we have nowhere to fire it from. Lower the inactivity-lock timeout if this matters to you.
• Biometric spoofing on an unlocked device. Android's class-2 biometric sensors (older fingerprint readers, weaker face unlock) can be fooled by good-quality fakes. If your device's biometric is class-2 and an attacker has high-resolution prints or a 3D model, they may bypass biometric unlock. The mitigation is to use a strong master password and treat biometric as convenience, not as a second factor.
• Keystore compromise on pre-Android 9 devices. On API < 28, the legacy Keystore key wrapping the vault key does not require the device to be unlocked at use time. If someone images the device storage and can later interact with the Keystore (rooted device, certain TEE exploits), the vault key can be unwrapped. On API >= 28 this is mitigated by setUnlockedDeviceRequired(true).
• A malicious user who knows your master password. Once the password is in the wrong hands, the vault is open. We cannot tell who is typing.

If any of these matter for your specific threat model, a local-only password manager is not your best fit. Use a hardened OS build (GrapheneOS), pair it with a hardware token (YubiKey for the things that support it), and accept that some convenience trade-offs are required.

07Clipboard & screen capture

• Sensitive copies (passwords, 2FA codes) are automatically cleared from the clipboard after 30 seconds.
• On Android 13 and above, those copies are marked sensitive so the system's paste-preview toast doesn't reveal the value.
• Screenshots and screen recordings of the app are blocked by default - including the Recent Apps preview. You can change this in Security settings.
• Revealed passwords cannot be selected from the on-screen text via the long-press menu, so they can only leave the app via the in-app copy button (which routes through the auto-clear path).

08Backups & recycle bin

• Encrypted .1key backups are protected by your master password using Argon2id. The export timestamp and vault-version counter are also authenticated, so a backup file can't be tampered with or replayed across vaults without detection.
• Plain JSON or CSV exports are unencrypted text. Treat those files as sensitive: anyone who finds one can read every password inside. 1Key warns clearly and requires master-password confirmation before producing one.
• Items in the recycle bin remain encrypted with the same protections as active items. They're auto-purged after 30 days by default; you can change the retention (1 week, 30 days, 6 months, 1 year, or never) or disable auto-purge entirely in Settings.

09Data deletion

• Uninstalling the app removes all of your data. Android wipes the app's private storage, including your encrypted vault. There is no remote copy of anything.
• Use "Delete Vault" in Settings to wipe all credentials while keeping the app installed. This requires your master password to confirm.

10Background activity

The app does not run when you are not using it. There are no background services, scheduled jobs, or wake-ups. When you close or background the app, the auto-lock timer fires (immediately by default) and the encryption key is dropped from memory.

11Regulatory

GDPR, CCPA, and COPPA do not apply to this app because no personal data is collected, processed, or transmitted at any point.