Skip to main content
getbased keeps profile and health data in your browser. Without a passphrase, most profile data is readable inside your browser profile. Credentials, the local meal cache, WHOOP data, and Google Health raw rows receive separate always-on device protection in this default state. If credential protection is unavailable, getbased removes legacy plaintext credentials and keeps new ones in memory instead of writing them unprotected. For broader protection, enable a passphrase. getbased derives an encryption key with PBKDF2-SHA256 using 600,000 iterations and encrypts sensitive data with AES-256-GCM before writing it to browser storage.

​
What passphrase encryption covers

When passphrase protection is enabled, it covers:
  • Imported lab data, profile details, reviewed meals and thumbnails, nutrition targets, notes, supplements, cycle data, context cards, and genetics
  • Sent conversations, thread indexes, unsent per-conversation drafts, custom personas, and persona deletion records
  • AI, voice, local-server, knowledge-base, Cashu, weather-source, and extension credentials
  • Meal, wearable, cycle, and Cashu records stored in IndexedDB
Settings that contain no health data, such as theme and display preferences, remain readable so the app can start before you unlock it. Some device-scoped records have stricter handling:
  • Wearable OAuth tokens are always kept in a per-profile, device-local encrypted vault. They are excluded from sync and backups, so reconnect each provider in every browser.
  • Cached meal payloads are always device-key encrypted. The profile’s reviewed thumbnail-only copy can additionally receive passphrase protection and encrypted Sync protection.
  • Raw WHOOP and Google Health rows are always device-key encrypted and excluded from raw-data backups. WHOOP-specific connection metadata and derived profile values use a separate device-encrypted sidecar. Other raw wearable rows use passphrase encryption when it is enabled.
There is no passphrase recovery. If you forget it, getbased cannot decrypt the protected data on that browser. Store the passphrase safely and keep backups you understand before enabling encryption.

​
Enable encryption

1

Open security settings

Go to Settings → Data → Security, or click the Protect your data pill on the dashboard and select Encrypt data.
2

Set a passphrase

Enter a passphrase that meets all four requirements:
  • At least 8 characters
  • At least one lowercase letter
  • At least one uppercase letter
  • At least one special character (!@#$%^&* and similar)
A strength meter with a color-coded bar and checklist shows your progress as you type. The Encrypt button stays disabled until all four rules pass.
3

Confirm

Click Encrypt. getbased encrypts your existing sensitive data and saves it. You will be prompted for the passphrase when a tab needs to unlock that data.
After your first PDF import, getbased shows a one-time prompt suggesting you enable encryption. You can dismiss it and enable encryption later from Settings; it is a reminder, not a requirement.

​
Passphrase requirements

​
No recovery path

There is intentionally no reset or recovery mechanism. The passphrase is never stored; only the key derived from it is kept in memory while a tab is unlocked. If you lose the passphrase, you can clear the browser data and start fresh, but that permanently deletes data that exists only there. Local passphrase protection is configured per browser. Cross-device sync does not distribute the passphrase or an unlocked local key to another device.

​
Tabs unlock independently

Each tab holds its own in-memory key. getbased uses BroadcastChannel only to announce that stored data changed; it does not broadcast the encryption key. Unlock each tab that needs access. Closing a tab clears that tab’s in-memory key.

​
Backups and credentials

A plaintext JSON profile export contains the profile data you chose to export, so protect the downloaded file yourself. Full database and folder backups behave differently for credentials:
  • With passphrase protection off, browser-device credential envelopes are not portable and credentials are omitted from the backup.
  • With passphrase protection on, supported credentials can be included as passphrase-encrypted values and require the same passphrase after restore.
  • Wearable OAuth tokens remain device-local and are not backed up.
  • Full-size meal photos are never saved; reviewed meal thumbnails follow the profile/database backup path.
See Backup and Export and import before relying on a copy for recovery.

​
Relationship to sync encryption

Local encryption and cross-device sync are independent:
  • Local encryption uses your passphrase to protect sensitive browser storage on that device.
  • Sync encryption uses your Evolu mnemonic identity to protect synced records before they reach the relay.
You can enable either or both. The sync relay receives encrypted records, but enabling sync does not unlock another browser or replace local backups.
For stronger resilience, enable local encryption, keep the sync mnemonic and local passphrase in a password manager, and maintain regular offline backups.