Privacy Policy

How getbased handles your data.

Effective 22 August 2026

1. Who runs getbased

The hosted getbased website and application are operated by getbased s.r.o., identification number (IČO) 298 97 777, with registered office at Drahanovice 315, 783 44 Drahanovice, Czech Republic, registered in the Commercial Register maintained by the Regional Court in Ostrava, file C 104867. The source code remains available under the GNU Affero General Public License v3 (AGPL-3.0).

For the purposes of the EU General Data Protection Regulation (GDPR), getbased s.r.o. is the Data Controller for processing it determines on the hosted website and application. A cloud AI, voice, wearable, relay, or custom provider you choose may be a separate controller or processor under its own terms. When you self-host getbased, you determine the controller and processors for that deployment.

2. What we don't collect

Before listing what might transit, here's what we never do:

• No user account, no login, no email required to use getbased
• No tracking cookies, no advertising pixels, no behavioural ad targeting
• No cross-site or cross-device fingerprinting
• No sale, licensing, or commercial sharing of your health data
• No central server-side storage by getbased of plaintext health information, lab results, DNA data, chat history, wearable rows, or profile metadata. Optional sync and sharing features may store end-to-end-encrypted or password-encrypted ciphertext that getbased cannot read.
• The public landing page does not load the Umami tracker unless you select Allow analytics. Refusing does not restrict the website. The hosted app's separate cookieless Umami analytics are enabled by default with a first-run transparency banner and an immediate opt-out in Settings → Privacy. Website analytics include landing-page views; app analytics include pageviews and limited product events. URL query strings and fragments are excluded, as are health records, viewed values, chat contents, uploaded files, profile context, API keys, and wearable tokens. The analytics service uses the request IP and user agent transiently for coarse location and a daily session identifier; the raw IP is not stored in analytics.

3. What stays on your device

Virtually everything you put into getbased is stored locally in your browser:

• Profile data (sex, date of birth, location, context cards) — browser localStorage
• Lab results imported from PDFs or entered manually — browser localStorage
• DNA match data — only the matched SNPs from the curated list (not your full genome); browser localStorage
• Wearable daily data (sleep, HRV, resting HR, readiness when connected) — browser IndexedDB, per-profile, never syncs
• Chat history — browser localStorage, organised into threads
• Backups — browser IndexedDB (5 most recent) and optionally a folder you choose on your own disk (up to 30 daily snapshots)
• API keys / authorization tokens for services you configure — stored locally; wearable OAuth tokens are always encrypted at rest with AES-256-GCM using a non-extractable device key, while other configured secrets are encrypted when you enable the passphrase option. If you enable cross-device sync, eligible non-wearable provider settings and keys may be included only inside the end-to-end-encrypted sync payload; wearable tokens remain excluded

Health, genetic, biometric, voice, and wearable data may qualify as special-category or otherwise sensitive personal data. getbased's default design keeps core data on your device; external processing happens only when you intentionally use a feature that sends data to a third-party provider, sync relay, encrypted sharing endpoint, or support/security contact. Cloud AI and voice require the separate express approval described below.

None of these are sent to getbased's website by default. If you clear your browser storage, uninstall the app, or use the "Clear all data" action in Settings → Data, the data is gone from your device.

4. Third-party services you choose

getbased calls third-party services only when you configure or use the relevant feature. Each has its own privacy policy that governs data handling on its side. Where a provider acts as an infrastructure processor, getbased relies on that provider's data-processing terms and security measures; where you choose an external AI, wearable, relay, or custom endpoint, that provider may act as an independent controller or processor under its own terms.

4.1 AI providers (all optional)

If you use cloud AI, your prompt, attachments you choose to send, and the enabled profile context are sent to the provider you selected. Context may include health, genetic, biometric, wearable, lifestyle, medication, or other sensitive data. The free hosted app uses credentials or funding you obtain directly from the provider; getbased does not supply a managed AI key or resell the inference.

• PPQ — ppq.ai/privacy
• Routstr — routstr.com; the selected node may receive the request
• OpenRouter — openrouter.ai/privacy
• Venice — venice.ai/privacy; when a supported E2EE model and mode are selected, the app verifies the enclave and encrypts prompt content for it
• Local AI (Ollama, LM Studio, Jan) — uses the local or private-network endpoint you configure and is not subject to the cloud approval gate
• Custom API — an OpenAI-compatible endpoint you provide; requests and credentials go directly from your browser to that endpoint, which must permit browser-based inference, and the endpoint operator's policy applies

Cloud voice is also optional. Depending on the provider and feature you select, recorded audio may be sent for transcription and text may be sent to generate speech. Supported routes include the selected AI provider where compatible and separate xAI (see its API terms and Data Processing Addendum) or ElevenLabs connections. Audio and voice data may itself be personal or biometric data depending on its content and how the provider uses it.

Ordinary requests to the listed cloud AI and voice providers are sent directly from your browser to the selected provider, not through getbased's hosted compatibility service. OpenRouter may route a request to the model provider you selected; Routstr may route it to the selected node. Review the provider's retention, training, privacy, and data-policy controls before sending sensitive information.

Before the first data-bearing request to each cloud provider, getbased displays a separate, unchecked approval that names the recipient and transmission route. The approval covers cloud AI and voice requests you later initiate with that provider. Refusing sends nothing and leaves local features available. The app stores the provider, recipient, route, consent-version, and timestamp locally in your browser. You can withdraw all future cloud AI approval in one action under Settings → Privacy. Withdrawal does not affect processing already completed by a provider or delete data from the provider; use the provider's own controls for that.

Before text-based AI analysis, getbased can replace likely identifiers found by deterministic patterns and, optionally, a local model. Automated obfuscation can miss identifiers and cannot scrub image or audio content, so review what will be sent. Obfuscation is a risk-reduction aid, not anonymisation or a guarantee.

4.2 Direct requests and hosted services

AI, voice, and Custom API requests on the official hosted app run directly from your browser to the provider you selected. The Company-operated /api/proxy does not offer a generic authenticated or body-bearing forwarding service for those requests. A Custom API or other AI/voice provider that does not permit browser-based inference is unavailable on the official hosted app; you may instead use a compatible provider or a self-hosted deployment whose infrastructure you control.

The official app does provide a narrowly scoped compatibility path at integrations.getbased.health for features that cannot operate browser-direct. This service runs on Company-operated Czech VPS infrastructure. Its server-side policy fixes the permitted provider host, path, method, headers, and request shape. It covers Oura, Withings, Polar, and existing legacy Fitbit OAuth/API calls; the exact NVIDIA NRAS GPU-attestation endpoint used to verify Venice E2EE; a fixed privacy-rounded CAMS lookup; and an explicitly marked public product-page read that cannot contain authorization headers or a request body. Requests outside those shapes are rejected before an upstream connection is made.

• The hosted app does not receive plaintext AI prompts, voice recordings, speech text, or Custom API credentials for forwarding.
• For a supported hosted wearable connection, getbased and its Czech VPS infrastructure transiently process the OAuth authorization code or refresh token, returned access/refresh credentials, and the provider's raw API response while relaying it to your browser. For Oura this can include personal information, sleep, readiness, activity, heart-rate, SpO2, stress, resilience, temperature, VO2-max, and cardiovascular-age records; Withings and Polar responses may include the body, cardiovascular, sleep, activity, and exercise measurements exposed by the scopes you authorized. Existing legacy Fitbit connections may return the Fitbit categories previously authorized.
• The compatibility service does not intentionally log or persist proxy request or response bodies. Its abuse limiter uses a short-lived one-way hash of the request IP and empty rate-slot markers. Nevertheless, ordinary HTTPS terminates at the service and the application can technically read allowed plaintext while the request is running; this is processing, not end-to-end encryption. The VPS infrastructure provider can process ordinary network, security, and operational metadata.
• A public product-page import reveals the URL requested and the returned public page to the hosted function. It is limited to a credential-free public GET and a bounded readable response.
• The NVIDIA attestation step exposes GPU evidence, challenge/status data, timing, and transport metadata, but not the encrypted Venice inference messages or their decryption key.
• Home postal codes stay in the browser; the hosted app uses country-level latitude rather than resolving them through a getbased function.
• For the hosted Sun/UV default, the browser rounds coordinates to a 0.1-degree grid (approximately 11 km) and the compatibility service enforces that rounding again. The rounded grid coordinates and requested time pass transiently through the Company-operated VPS service to the fixed uvdata.getbased.health CAMS service. The services can technically read those limited values while processing the request; this route is minimised plaintext processing, not end-to-end encryption.
• The fixed CAMS route performs an in-memory lookup against a configured CAMS grid downloaded separately on a schedule. It does not send or cache an individual request's coordinates to Copernicus or Open-Meteo and does not intentionally log or persist the request body. Copernicus receives the relay's fixed configured grid/bounding-box download request and its server metadata, not a user's location.
• If CAMS is unavailable or lacks fields needed by the feature, the browser may send the same 0.1-degree rounded coordinates and time directly to Open-Meteo for weather, UV, or air-quality data. That fallback does not pass through the getbased proxy. You may instead select browser-direct Open-Meteo or explicitly configure a server you control.
• Encrypted profile sharing uses a separate isolated service at shares.getbased.health. The browser encrypts before upload, so the service stores ciphertext plus expiry, deletion, and bounded abuse-prevention metadata but has no password or decryption key. Temporary share copies are not backed up and can be lost after a service failure; the source profile remains in the sender's browser.

Hosting a website cannot eliminate all hosting metadata. Vercel serves the public website and app assets and may process IP address, timestamp, requested path, TLS/connection, routing, status, security, and abuse-prevention metadata under its configured terms and retention. Current official-app compatibility payloads and new encrypted profile-share ciphertext use the separate Company-operated VPS services described above rather than Vercel storage or execution.

Browser-direct provider traffic uses HTTPS/TLS in transit, but it is not end-to-end encrypted against the selected provider: that provider must decrypt the request to perform the service. getbased is not in that route. When a feature is described as end-to-end encrypted below, the getbased-operated relay or storage service receives ciphertext and does not hold the decryption key.

4.3 Cross-device sync (optional)

Opt-in sync uses Evolu, a CRDT protocol with end-to-end encryption. Your BIP-39 mnemonic derives the encryption key; a relay server relays ciphertext between your devices but cannot read the contents. You can choose the relay (getbased's default, or one you host).

4.4 Wearable integrations (optional)

When you connect a wearable (e.g. Oura), getbased:

• On the official hosted app, shows a provider-specific consent screen before starting a supported hosted connection. It names getbased s.r.o., explains the purpose, data, relay route, local storage, and withdrawal controls, and requires an unticked explicit-consent checkbox before Continue is enabled. The app stores the provider, local profile identifier, controller, purpose, consent version, and timestamp locally in that browser so approval is not reused across profiles; disconnecting withdraws the approval, stops future imports, and removes the local connection and imported source data
• Performs a standard OAuth2 authorisation flow with the vendor; you grant permission directly to the vendor
• Stores every wearable access/refresh token only in that browser, encrypted with AES-256-GCM under a non-extractable device key; tokens are excluded from profile sync and backups
• On the official hosted app, Oura, Withings, Polar, and existing legacy Fitbit connections use the fixed compatibility relay described above. WHOOP, Ultrahuman, and Google Health are self-host only and use that deployment operator's OAuth application; they do not fall back to getbased infrastructure. Confidential token exchange and refresh use that deployment's same-origin proxy. WHOOP and Google Health data requests also transit it, while Ultrahuman resource data is requested directly from the user's browser where Ultrahuman permits browser access
• Stores raw daily rows only in your browser's IndexedDB, never on any server
• Derives a compact rolling summary (baselines, trend, recent anomalies) that may sync via the E2E-encrypted relay to your other devices, if you have cross-device sync enabled

Disconnecting a wearable wipes its local rows immediately. The vendor retains the data they already have on their side per their own policy; getbased cannot delete it there. To revoke getbased's access, disconnect inside the app and revoke the app on the vendor's site.

4.4.1 Google Health

Google Health is a separate, explicit opt-in, self-host-only connection. It is intended for Fitbit and Pixel Watch data and can also act as an optional hub for other sources linked to your Google account. The official getbased-hosted app does not operate the confidential OAuth relay it requires. It does not silently replace or route independent integrations.

Immediately before starting Google's OAuth consent flow, getbased shows an in-product disclosure and asks you to continue. If you continue, getbased requests only these three read-only Google Health permission categories:

• Activity and fitness — used for daily activity signals such as steps and heart-rate rollups
• Health metrics and measurements — used for available measurements such as HRV, resting heart rate, weight, body fat, oxygen saturation, temperature trend, respiratory rate, and VO2 max
• Sleep — used for total sleep, sleep stages, awake time, and related nightly measurements

getbased does not request Google Health write access, profile, location/GPS, ECG, irregular-rhythm, nutrition, or settings permissions. You can grant only a subset of the requested read permissions; metrics from a category you decline will be omitted.

Google Health data is handled as follows:

• OAuth token exchanges, refreshes, and Google Health API requests use the self-hosted deployment's own infrastructure. Those requests do not transit getbased-operated Vercel infrastructure.
• OAuth access/refresh tokens and imported daily rows are always encrypted in the browser with AES-256-GCM using a non-extractable key stored on that device. The credentials and raw Google Health rows are not included in getbased profile sync or backups, so every browser must be connected separately and can re-fetch data from Google.
• getbased uses the imported rows to display your Body dashboard and calculate visible personal baselines, trends, comparisons, and compact summaries. It does not use Google Health data for advertising, data brokerage, credit decisions, or medical-device functions.
• A compact derived wearable summary is stored with your profile. If you enable cross-device sync, that summary is sent only as end-to-end-encrypted relay ciphertext. If you use a cloud AI provider or agent while Wearables context is enabled, the compact summary may be sent to the provider or endpoint you selected for that visible feature; you can disable Wearables context before using it. Raw Google Health daily rows are not sent as ordinary AI context. Agent daily-series access is a separate opt-in.
• Local credentials, rows, and Google-derived source data are retained until you disconnect Google Health, clear the relevant profile/app data, clear browser storage, or the browser evicts the storage. getbased has no account to deactivate.

Disconnecting Google Health deletes that browser's credential record, imported rows, and Google-derived source data. To stop access across every browser, also revoke getbased in your Google Account. Revoking or disconnecting getbased does not delete source data held by Google or a connected device vendor; their policies apply to their copy. See the Google Privacy Policy.

4.5 Encrypted profile sharing (optional)

If you create a password-protected profile share link, your browser exports the selected profile and encrypts it before upload using AES-GCM with a password-derived key. The isolated shares.getbased.health service on the Company's Czech VPS stores only the encrypted ciphertext envelope and the limited expiry, deletion, size, and abuse-prevention metadata needed to operate the link. The password is not sent to getbased, and the Company cannot decrypt the shared profile.

Share links expire automatically, with a maximum lifetime of 30 days. You can also stop sharing from the device that created the link. Temporary share copies are not backed up and can be lost after a service failure. Anyone with both the link and the password can decrypt and import the shared profile, so keep them separate.

4.6 Knowledge Base (Interpretive Lens)

Documents you add to the on-device Knowledge Base are indexed and embedded locally in your browser using the Origin Private File System (OPFS). Nothing is uploaded. If you use the external-server lens option, the server you point at is under your control and its privacy model is yours.

4.7 Fonts, analytics, and CDNs

The public website serves Inter, Outfit, and JetBrains Mono locally and does not contact Google Fonts. The public landing page may load the Umami tracker described above from umami-iota-olive.vercel.app; Terms, Privacy, blog, and other public pages do not load that tracker. The app bundles its core fonts locally, while some optional libraries or models such as transformers.js may load from jsdelivr.net only when you invoke the relevant feature and are then cached by your browser.

4.8 Voluntary donations and external links

The public website contains user-activated links to third-party sites. When you follow one, the destination receives ordinary request metadata under its own policy. If you choose a HydraNode/BTCPay or Ko-fi donation option, that provider and any payment processor it uses handle the payment. The Company may receive the amount, transaction identifier and status, and any name, contact detail, or message you choose to provide. The getbased site and app do not collect full payment-card credentials or cryptocurrency private keys.

5. Legal basis for processing

• Hosted website security, abuse prevention, infrastructure logs, and operational metadata: legitimate interests in operating, securing, debugging, and preventing abuse of the service.
• Cloud AI and voice: consent under GDPR Article 6(1)(a) and, where special-category data is involved, explicit consent under Article 9(2)(a). Accepting the general Terms and Privacy Policy is not this consent.
• Wearable connections and fixed hosted compatibility relay: your requested connection and authorization to retrieve the selected health data, including explicit consent where special-category data is involved; the provider's own legal basis applies to its systems.
• Encrypted sync and sharing, Custom API, and external Lens features: your request to provide the selected feature. Payloads protected by end-to-end or password encryption are designed to be unreadable to getbased.
• Support emails, GitHub issues, and vulnerability reports: responding to your request and maintaining service security.
• Voluntary donations: carrying out the transaction you request and meeting applicable accounting, tax, fraud-prevention, and legal obligations.
• Public-website analytics: your consent. The tracker is not loaded before you allow it, refusing does not restrict the website, and you can withdraw below at any time.
• Cookieless analytics in the hosted app: the Company's legitimate interest in understanding aggregate product use and improving the service, balanced by data minimisation, no health/content fields, a first-run notice, and an opt-out in Settings → Privacy.

6. Recipients and processors

Depending on what you use, the following providers may receive limited data:

• Vercel — public website/app hosting and associated access, routing, security, and operational metadata.
• SecurityNet.cz / Hukot — Czech VPS infrastructure for the fixed compatibility, CAMS, and encrypted profile-share services described in section 4.2. Depending on the feature, this can include ordinary network/security metadata, transient allowlisted compatibility payloads, privacy-rounded CAMS values, or encrypted share ciphertext and its limited service metadata.
• Umami analytics infrastructure — cookieless public-website pageviews after you consent, and limited hosted-app pageview or product-event data unless you opt out in the app.
• Evolu sync relay — end-to-end encrypted sync ciphertext and relay metadata when you enable sync.
• AI, model-routing, node, and voice providers — prompts, selected context, images, recorded audio, transcripts, or speech-generation text you choose to send.
• The Company-operated CAMS service — 0.1-degree rounded grid coordinates and request time for the transient local-grid lookup described in section 4.2.
• Open-Meteo — 0.1-degree rounded coordinates and request time when you select it or the browser-direct fallback is needed.
• Copernicus CAMS — fixed configured model-grid/bounding-box download requests and relay-server metadata; individual users' coordinates are not sent with those downloads.
• Wearable vendors — OAuth authorization, tokens, and wearable API requests for vendors you connect.
• Google — Google OAuth authorization and Google Health API responses when you explicitly connect Google Health; Google processes its own copy under its policies.
• jsDelivr — library or model fetch metadata such as IP address and browser request metadata only when a feature loads an asset from it.
• HydraNode/BTCPay, Ko-fi, and their payment providers — donation and transaction data when you choose one of the external donation links.

6.1 Retention

• Local app and consent records: remain in that browser until you delete them, withdraw cloud AI approval, disconnect the relevant hosted wearable, clear site data, or the browser evicts storage. A new consent version invalidates the corresponding older approval.
• Encrypted profile shares: expire automatically after the period you select, never longer than 30 days, or earlier when you stop the share from the creating device. Temporary share copies are not backed up.
• Hosted access/security metadata: is kept according to the hosting provider's configured retention and only as long as needed for operation, security, abuse prevention, or legal obligations.
• Cookieless analytics: retained according to the configured Umami deployment retention for product trend analysis. It excludes the health and content fields listed above. You may opt out of future events at any time.
• Support and security correspondence: is kept until the request is resolved and afterwards only as reasonably needed for follow-up, security records, legal obligations, or legal claims.
• Donation records: are retained as required for accounting, tax, fraud prevention, transaction support, and legal claims; the payment provider applies its own retention to its copy.
• External providers: apply their own retention settings and policies to data sent directly to them. Withdrawing in getbased does not delete their copy.

6.2 Automated processing

getbased uses deterministic calculations and optional AI to produce educational summaries and suggestions. The Company does not use them to make decisions about you that produce legal or similarly significant effects. You decide whether and how to act on any output.

7. Your rights

Under GDPR and most privacy frameworks, you have the rights to access, correct, delete, export, restrict processing, object, withdraw consent, and complain to a supervisory authority. Because getbased stores most data on your own device, you can exercise many of these rights directly, without contacting us:

• Access — the data is visible in the app; you can also export a JSON dump via Settings → Data → Export
• Correct — edit any value inline
• Delete — delete individual records, individual profiles, all local data (Settings → Data → Clear all data), stop active profile-share links from the creating device, and disconnect integrations
• Export / portability — Settings → Data → Export produces a portable JSON file
• Restrict processing — disable website or app analytics, disable the AI context toggle, disconnect any wearable, turn off sync, stop sharing, or avoid cloud providers
• Object — object to processing based on legitimate interests, including hosted infrastructure metadata
• Withdraw consent — use Settings → Privacy → Cloud AI sensitive-data approval to stop future cloud AI and voice requests until you approve again; also disconnect optional integrations or revoke access with the provider. Withdrawal does not undo prior processing.
• Complain — you may lodge a complaint with your local supervisory authority. In Czechia, this is the Úřad pro ochranu osobních údajů (ÚOOÚ), uoou.gov.cz.

For personal data the Company controls (for example, if you email a support request, submit a vulnerability report, or contact through GitHub), you can write to privacy@getbased.health.

8. Children

getbased is not designed for children under 15. This matches the minimum age for consent to information-society services under Czech law (the governing law of the Terms). If you live in an EU Member State with a higher minimum age (16 in several countries under GDPR Article 8), that higher age applies to you. Please do not enter a child's medical data without appropriate guardianship and consent.

9. Security

Measures we apply:

• TLS for Company-hosted traffic and supported external-provider routes. A local or private-network endpoint you configure may use HTTP and should remain on a device or network you trust
• AES-256-GCM passphrase-based encryption for sensitive fields at rest, when you enable it
• End-to-end encryption on cross-device sync
• Strict same-origin handling on the dev server
• Regular security audits of the codebase (see the CHANGELOG for history)

No system is unbreakable. If you discover a vulnerability, please report it via a private GitHub security advisory at github.com/elkimek/get-based/security.

10. International data transfers

If you use the hosted getbased website or app, Vercel may process website/app access and security metadata in regions outside your country. The compatibility, CAMS, and encrypted profile-share services described above run on Czech VPS infrastructure; their destination wearable vendors and other upstream services may still process data elsewhere. Google Health on a self-hosted deployment, jsDelivr, Umami infrastructure, AI/model-routing/voice providers, wearable vendors, Evolu relays, Copernicus CAMS, Open-Meteo, custom endpoints, and optional donation providers may also process request metadata or user-selected payloads outside the EU/EEA depending on their infrastructure and policies.

Do not enable a provider, relay, custom endpoint, or share link unless you are comfortable with that provider's jurisdiction, transfer safeguards, and privacy terms. Self-hosting lets you replace getbased's hosted infrastructure with your own.

11. Changes to this policy

If we update this policy, we'll change the Effective date above and mention it in the app's changelog. Material changes, or changes to the app's built-in privacy version, will also be shown on the app's first launch after the update and the app will ask you to accept the current Terms and Privacy Policy before continuing.

12. Contact

getbased s.r.o.
Drahanovice 315
783 44 Drahanovice
Czech Republic
IČO: 298 97 777
Commercial Register: Regional Court in Ostrava, file C 104867

Privacy questions and data-subject requests: privacy@getbased.health

Source code, issues, general discussion: github.com/elkimek/get-based