Skip to main content
getbased is built on one principle: your health data belongs to you and no one else. By default, your lab results, DNA data, wearable history, and AI conversations stay in your browser’s local storage and IndexedDB. There is no account and no sign-up. Data leaves your browser only when you choose a feature that needs it: sending prepared report content or health context to an AI provider, enabling encrypted cross-device sync, creating a password-protected profile share link, or enabling Agent Access for a local MCP agent. Depending on the encrypted mode, a hosted service may receive an encrypted field or body while still seeing operational metadata.

​
Where your data lives

During normal local use, profile data such as lab entries, context cards, notes, supplements, genetics, wearable summaries, model-test history, sent chat threads, custom personas, and unsent per-thread drafts is stored in two browser-native storage areas:
  • localStorage for profile data, settings, and app state
  • IndexedDB for wearable time-series rows, knowledge base vectors, and backup snapshots
Clearing your browser data will erase your local getbased data, so use the export and backup features to keep copies you control. Sent conversations and custom personas are included in those backup paths; unsent drafts are deliberately device-local and excluded. Opt-in network features such as AI providers, sync, profile sharing, and Agent Access are covered below.

​
Encryption at rest

By default, data is stored unencrypted in your browser’s local storage. Other websites cannot read it, but someone with access to your device, browser profile, or malicious extensions may be able to. For an extra layer of protection, you can enable AES-256-GCM encryption at rest from Settings → Data → Security. When active, your data is encrypted with a key derived from your passphrase via PBKDF2 before being written to storage. See Encrypt your data for setup instructions and passphrase requirements.

​
PII stripped before AI sees your labs

When you import a text-based lab PDF, getbased runs an obfuscation pass before the extracted text reaches the active AI provider:
  1. Regex scan (always on) — detects and replaces known PII patterns: name, address, date of birth, SSN/patient ID, email, phone, and common US lab identifiers (Specimen ID, Accession No, MRN).
  2. Local AI obfuscation (opt-in) — a compatible text model reads the full PDF text and replaces personal information contextually, catching edge cases the regex misses. Enable it in Settings → Privacy → Configure Local AI. This step stays on the same device only when you configure a loopback endpoint and a truly local model.
What the active AI provider receives: the text after the obfuscation pass, normally marker names, values, units, and collection dates. Review the obfuscated text when prompted because automated detection can miss unusual identifiers. Scanned PDFs, photos, and screenshots use image mode. Page images are sent to the active provider and can still show names, addresses, barcodes, or other identifiers because text obfuscation cannot edit pixels. getbased warns you before switching a PDF to image mode.
Even with PII obfuscation active, the prepared text is sent to your configured AI provider. If you want the import to stay on one device, use loopback endpoints such as localhost, 127.0.0.1, or [::1] with downloaded models for both the PII step and the main AI provider, and avoid image mode unless you have redacted the image yourself.

​
AI provider options and what they see

getbased supports multiple AI backends. The privacy implications differ by provider:

​
PPQ and Routstr Private TEE modes

When you select a private model, getbased verifies an AMD SEV-SNP attestation in your browser before sending the request. The verification checks the AMD hardware certificate chain, rejects debug-enabled enclaves, confirms the running code measurement matches a tagged Sigstore-signed release, and binds the encryption public key to that verified enclave. After verification, getbased uses HPKE and the Encrypted HTTP Body Protocol (EHBP) to encrypt the prompt, conversation messages, system context, and response body between your browser and the enclave. The PPQ or Routstr proxy forwards ciphertext and cannot decrypt those bodies. This does not mean that your device holds the only key. Your browser keeps ephemeral request key material, while the attested enclave holds the corresponding server-side private key. The security guarantee is that the proxy does not receive the body-decryption key and that getbased encrypts only to a key bound to the verified enclave. The proxy still sees the authentication credential and routing headers it needs to process the request. For Routstr, this includes your session credential, selected model, timing and approximate size, network metadata, and billing information. Web search is disabled in both private modes; Routstr also disables image attachments. A 🔒✓ indicator appears in the chat header after attestation succeeds. Hover over it to see the enclave hostname, code fingerprint, and verification status. If attestation fails or a successful response is not EHBP-encrypted, getbased stops the request rather than falling back to a standard plaintext model.
Attestation proves that an encryption key belongs to a hardware-protected enclave running code that matches a signed release. It does not prove that the signed code has no defects, and it cannot protect plaintext from a compromised browser, extension, operating system, or app delivery path before encryption.
For the complete verification chain, key lifecycle, failure behavior, and trust assumptions, see TEE attestation and encrypted AI transport.

​
Venice Encrypted TEE Mode

When you enable this mode, getbased encrypts each message’s content field in the browser using ECDH (secp256k1), HKDF-SHA256, and AES-256-GCM. It expects encrypted model-output chunks and stops the request if a successful content chunk arrives as plaintext. Empty or whitespace-only formatting chunks are allowed. The surrounding request is not opaque. Venice still receives the API credential, selected model, message roles, token and streaming settings, request structure, timing, approximate sizes, billing information, IP address, and other network metadata. Before starting an encrypted session, getbased requires two independent hardware checks:
  • TEE check: The browser verifies the Intel TDX quote with DCAP, including its signature, certificate chain, revocation information, and TCB status. It also checks session freshness, the requested model, encryption-key binding, and that debug mode is disabled.
  • GPU check: NVIDIA’s Remote Attestation Service (NRAS) evaluates the supplied GPU evidence. The browser then verifies every signed NRAS result against NVIDIA’s published keys and checks the shared session nonce, secure boot, disabled debug mode, and NVIDIA’s measurement verdict.
If either required check is absent or fails, the encrypted session does not start. The header then shows 🔒 TEE + GPU after both checks pass. Hover, focus, or tap the badge to see the individual results and current limits. A plain 🔒 means encrypted mode is selected but the current session has not yet supplied verification details; 🔒 failed means setup was stopped. The two checks do not prove that the TDX environment and GPU are running together. getbased also does not currently enforce an approved Venice code-measurement allowlist or independently verify the source of every response. The per-chunk response key is therefore not independently bound to the attested signing key. NVIDIA does not accept the GPU-check request directly from a browser, so the deployment’s same-origin proxy relays the GPU evidence to NRAS. Message content is not included. The signed NRAS results are still verified in your browser, and NVIDIA learns that an attestation was checked. See TEE attestation and encrypted AI transport for the full protocol boundary and remaining assumptions.

​
Local AI endpoint location

Connect any OpenAI-compatible server in Settings → AI → Local AI. The label describes a direct compatible connection; it does not prove where inference runs. getbased classifies the configured setup as this device, LAN server, remote server, or cloud. Ollama :cloud models are always treated as cloud-hosted even when the Ollama client runs on your computer. A remote connection over plain HTTP does not protect health data or API credentials unless an underlying VPN or encrypted tunnel does. For a fully on-device path, use a loopback URL and a model downloaded to that machine. See Connect an AI provider for setup and browser transport restrictions.

​
Voice processing

Voice is configured separately from the AI provider that generates chat answers. The privacy boundary depends on the service selected in Settings → Voice: Raw microphone recordings are not added to profile storage, backups, sync, or chat history. Dictation inserts a transcript into the composer for review. The transcript reaches the main AI provider only when you choose to send the message, at which point normal chat context rules apply. On-device model files and fetched voice lists are rebuildable browser caches and do not sync or enter backups. Voice credentials are encrypted at rest only when Settings → Data → Security encryption is enabled and unlocked; otherwise they are plaintext in browser storage. xAI and ElevenLabs voice settings and keys can be included in end-to-end encrypted cross-device sync. Compatible-server connection details and its optional key are device-scoped and do not sync. Full database and folder backups include all configured Voice settings and credentials in their stored form. That means backups preserve encrypted values when local encryption is enabled but contain plaintext credentials when it is disabled. See Use voice in AI chat for setup and provider behavior.

​
Model-test history

Model tests record the provider, model, accuracy or review-quality signals, timings, token usage, and available local runtime details. They do not store the bundled sample report as health data. Test history stays on the device that produced it. getbased skips sync when saving it, removes it from outbound sync payloads, and preserves the local copy when remote profile data is merged. Full database and folder backups can still include the local records. See Test and compare AI models.

​
Cross-device sync

Cross-device sync is entirely opt-in. When you enable it, an Evolu CRDT engine encrypts your data with a key derived from a 24-word mnemonic before it reaches the relay server. The relay only ever stores encrypted blobs. Model-test history, raw wearable daily rows, and wearable OAuth tokens remain device-local. See Sync across devices for setup details.

​
Profile sharing

Profile sharing is opt-in. When you create a share link, getbased locks a copy of the selected profile in your browser with the password you choose or generate, then uploads only that locked copy. The password is not added to the link and is not stored by getbased. Anyone who has both the link and the password can import the shared profile until the link expires or you stop sharing it. See Profile sharing for the full workflow and limitations.

​
Agent Access

Agent Access is opt-in and separate from cross-device sync. When enabled, your browser encrypts a compact agent context with GETBASED_AGENT_CONTEXT_KEY, then pushes only the encrypted envelope to the context gateway. GETBASED_TOKEN authorizes relay reads, but it is not the decryption key. Your local MCP client fetches the ciphertext and decrypts it locally. See Connect getbased to external AI assistants for setup and revocation. On first launch, getbased shows a Terms & Privacy gate before the normal tour, changelog, backup nudges, or other startup prompts. The acceptance record is stored locally in your browser with the Terms and Privacy version dates. If either document version changes, getbased asks you to accept the updated versions again on that browser. The hosted app may collect anonymous cookieless usage stats for product health. The first-run notice and Settings → Privacy → Anonymous Usage Stats explain the boundary: no IP address, no health data, no profile contents, no AI messages. You can disable usage stats at any time.

​
No account or identity tracking

getbased has no user accounts, no login, and no cookies tied to your identity. The app is open source — you can verify every claim on GitHub.

​
Data portability

You own your data and can take it with you at any time:
  • JSON export — download a full plaintext copy from Settings → Data → Export. See Export and import.
  • Profile sharing — create a temporary password-protected link for one profile. See Profile sharing.
  • Agent Access — share an encrypted summary with your own MCP-compatible agent. See Agent Access.
  • Folder backup — auto-save daily snapshots to any local folder, Proton Drive, or Dropbox. See Backup.
  • Cross-device sync — move data to a new device without exporting a file. See Sync across devices.

​
Tor access

getbased is accessible over Tor at its .onion address. When you access the app via Tor, the sync relay automatically switches to its .onion WebSocket address so all traffic stays within the Tor network.