How getbased protects your health data

getbased is built on one principle: your health data belongs to you and no one else. By default, your lab results, DNA data, reviewed meal records, 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, reviewed meals and thumbnails, 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 the device-encrypted meal cache, 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, profile and health data is readable inside your browser profile. Other websites cannot normally read it, but someone with access to your device, browser profile, or a malicious extension may be able to. Credentials have an additional default safeguard: supported AI, voice, wearable, and service credentials are wrapped with a browser-specific, non-exportable key rather than deliberately stored as plaintext. If that protection is unavailable, getbased keeps new credentials in memory instead of persisting them unprotected. For broader protection, enable AES-256-GCM encryption at rest from Settings → Data → Security. getbased derives the key from your passphrase with PBKDF2-SHA256 using 600,000 iterations. Each tab unlocks independently; the key is not broadcast to other tabs. 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.

​

Original chat images

For original chat attachments, the current path preserves the file bytes, including any EXIF metadata. Remove metadata and redact visible identifiers yourself before sending. This is distinct from PDF text obfuscation and from separately prepared image-import paths. Chat history retains thumbnails rather than full-resolution originals.

​

Meal photos and nutrition estimates

Meal-photo and nutrition-label analysis has a separate image boundary:

• selected full-size images remain in memory until you choose analysis;
• getbased sends them to the image-capable route shown in the meal editor: directly to an API/local-model endpoint, or through Companion for a supported local CLI;
• cloud recipients require recipient-specific approval before the first meal request;
• full-size images are not saved by getbased, added to Sync, or included in exports; and
• a reviewed meal may store a small 240 px thumbnail plus bounded image metadata.

The selected provider can process and retain the images and prompt under its own terms. Images can contain faces, location clues, receipts, labels, or other identifying details, so review what is visible before sending them. Reviewed meal records and thumbnails are device-key encrypted in the local meal cache even without a profile passphrase. When Sync is enabled, the reviewed record and thumbnail join the end-to-end-encrypted profile payload. Compact nutrition context contains coverage-aware aggregates, not individual meal names, ingredients, notes, photos, or response check-ins. See Meals & Nutrition.

​

AI provider options and what they see

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

​

Consent before cloud processing

Before the first request to OpenRouter, PPQ, Routstr, Venice, xAI, ElevenLabs, or a remote Custom API origin, getbased displays a recipient-specific consent prompt. Nothing is sent until you approve, and declining sends nothing. Private or loopback Custom API origins do not require cloud-processing consent. An approval covers later cloud AI and cloud voice actions you choose to initiate with that recipient. Review the approved recipients or withdraw all cloud-processing approvals in Settings → Privacy. After withdrawal, the next cloud request requires approval again.

​

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. 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 official app sends only the GPU evidence through getbased’s dedicated compatibility relay; a self-host sends it through its own same-origin compatibility endpoint. 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 a separate operation from generating a chat answer. Same as chat can reuse a supported OpenRouter, PPQ, or Venice connection; otherwise it falls back to the on-device models. The privacy boundary depends on the resolved service 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 use browser-device encryption when passphrase protection is off and passphrase encryption when it is on. All cloud voice recipients require the same recipient-scoped processing approval used for cloud AI. A private/TEE chat selection does not extend its attestation or encrypted-message protocol to these ordinary audio endpoints. Sync-scoped voice preferences and supported OpenRouter, PPQ, Venice, xAI, and ElevenLabs keys can be included in end-to-end encrypted cross-device sync and are rewrapped under the receiving browser’s local credential protection. Compatible-server connection details and its optional key are device-scoped and do not sync. Full database and folder backups follow a narrower rule: they omit device-key-wrapped credentials when passphrase protection is off; when it is on, supported credentials remain passphrase-encrypted. 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. Reviewed meal data and small thumbnails can sync; full-size meal photos cannot. 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. The official app uploads directly to the dedicated getbased share service, not the static app host. The share service can observe ordinary connection metadata and stores a keyed abuse-control identifier with expiry and deletion metadata. It stores the opaque encrypted envelope, not the profile plaintext. The service has no retained database backup, so an outage or data loss can invalidate an active link; the source profile remains in the sender’s browser. 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

​

CLI providers are a separate connection

Settings → AI → CLI agents sends your message and enabled health context through a loopback Companion to your chosen agent. The model may still be cloud-hosted. Local execution receives bounded getbased read/navigation/proposal tools, with profile/source checks and explicit Apply before health-data writes. A personal gateway receives the enabled chat snapshot but not the local tool credential; its own memory, tools, and retention policy remain under your gateway configuration. Hosted discovery credentials authorize chat only, not installing, pausing, updating, or uninstalling programs. Your agent’s login stays under its own local configuration. Uploaded images use private temporary Companion storage and are cleaned up after a turn/cancellation; that does not promise deletion from the upstream agent/provider. Automatic voice stays on-device for CLI chat unless you explicitly choose another voice service. See CLI agents.

​

Relay sharing

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.

​

Terms, Privacy, and analytics consent

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.