Privacy Policy

This policy describes how Natively — the desktop application, the Natively Pro licensed features, and the Natively API managed service — handles your data. We've tried to write it like a person, not a lawyer.

If anything's unclear, email [email protected]. We aim to reply within 24–72 hours on weekdays.

1. Who we are

Natively is built and operated by a single developer based in Kochi, Kerala, India. For the purposes of applicable data-protection law (including India's Digital Personal Data Protection Act, 2023, and the EU General Data Protection Regulation where it applies):

• Data fiduciary / controller: Evin John, the developer of Natively.
• Contact: [email protected]
• Grievance Officer (India IT Rules 2021): Evin John — [email protected] — we acknowledge complaints within 72 hours on weekdays and aim to resolve them within 30 days.

If you're using Natively on behalf of an organisation (under a bulk or team licence), that organisation is a separate data controller for the data of its own users, and you should also consult its own privacy policy.

2. The short version

We've designed Natively to keep as much of your data on your device as possible. In practice that means:

• Audio you capture, screen content, transcripts, notes, and meeting history are stored locally on your device in a SQLite database. They are not uploaded to a Natively-operated server.
• When Apple Speech is selected, microphone and system audio are transcribed by Apple's on-device speech framework. The audio is not sent to Natively or a cloud speech provider. macOS may contact Apple to download the selected language's speech asset.
• When you use a cloud AI, speech-to-text, or search feature, the relevant text or audio leaves your device only to be processed by the provider you've chosen (e.g., OpenAI, Anthropic, Google, Groq, Deepgram, ElevenLabs, Azure, IBM, Soniox, Tavily). The result comes back to your device.
• For paid products (Natively Pro, Natively API), we do store a small amount of operational data on our servers — your license key, hardware identifier, plan, billing email, and quota counters. We need this to make billing and licensing actually work. We do not store the content you generate.
• For the Free Trial, we additionally store anti-abuse signals (rate-limited IP, trial tokens, basic usage counters).
• Every installation, paid or not, reports product-usage events to our own servers: that the app was opened on a given day, that a meeting was held, which features were used, that a trial was started, that a plan page was opened, and the like. They are linked to your device and, if you have one, your trial or account. They cannot contain anything you say, see or type. You can turn them off. See §3.2.1.
• We do not sell your data. We do not use your content to train AI models. The desktop app also sends anonymous usage events to Google Analytics: that the app was opened or closed, which feature or AI model was used, and how long a session lasted. These events never contain anything you say, see or type, and IP addresses are anonymised. We don't use advertising or marketing trackers inside the desktop app.

The rest of this document explains those flows in detail.

3. What we collect, store, and process

Different categories of data are handled in different places. This section is the source of truth for what goes where.

3.1 Stays on your device — never sent to us

These never leave your device unless you choose a feature that sends a specific portion to a third-party provider (see §4):

• Audio captures (microphone and system audio).
• Screen captures (when you take or trigger one).
• Transcripts generated by speech-to-text.
• Meeting notes, summaries, exports, and anything you generate inside the app.
• Settings & preferences (stored via electron-store in the standard OS application-support directory).
• Your custom context files (resumes, notes, JDs, knowledge base).
• Local SQLite database containing meeting history.
• Your bring-your-own-key (BYOK) provider API keys when you use the desktop app outside the Natively API. These are stored locally on your device. We do not transmit them to our servers, and we strongly recommend keeping your computer protected by full-disk encryption — electron-store itself stores its data as readable JSON, so anyone with file-system access to your device could otherwise read those keys.

3.2 What we store on our servers — only for paid products and the Free Trial

For Natively Pro, the Natively API, and the Free Trial we maintain a small operational record. Specifically:

We do not store the audio you capture, the screen content you capture, your transcripts, your prompts, or your generated outputs on our servers.

This applies to the usage ledger too. The ledger records that something happened — when, through which endpoint, on which model, whether it succeeded, and how much of your quota it used. It never records what it was about. No prompt text, answer text, résumé or job-description content, meeting transcript, document content, clipboard content, keystroke or screenshot is written to it, and neither is any provider API key: your Natively key appears only as a one-way hash that cannot be reversed back into the key.

The installation identifier is a random value generated on your device the first time the app runs. It is not derived from your hardware, and we do not collect a hardware fingerprint for this purpose. One licence may have several installations, and we record them separately so we can tell them apart — not so we can identify a machine.

Where the app reports its own feature activity to us, we label those records as self-reported by the application and keep them separate from what our servers observed directly. We do not present the two as the same kind of evidence, because they are not: the first is a report from software running on your computer, and the second is something our own systems executed and measured.

3.2.1 Product-usage events — what every installation reports, and who it is linked to

The desktop app reports product-usage events to our own servers, whether or not you have bought anything. We use them to follow how people move through the product: who installs it, who holds a first meeting, who tries it, who pays, where the others stop, and who comes back. They go to us only, not to an analytics company.

These events are linked to you, not anonymous. Each one is tied to your device, and, when you have a trial or an account, to that trial or account.

Every event is a fixed name with fixed choices, whole numbers, or yes/no values. No field in it can hold text, so an event cannot contain anything you say, see, type or paste, a file name, a meeting title, the name of a model, or a key. A count of answers is a number; the answers are never sent. We do not store your IP address with these events.

Country. Our server reads the address a request arrives from once, to look up the country in a database it keeps on its own disk (IP geolocation by DB-IP), and stores the two-letter country code with the event. The address is not stored and is not sent to anyone for this lookup. Nothing finer than the country is kept: no region, city or network.

Shown on our website. Our website shows where the app was open in the last 24 hours. For each country it shows a whole percentage and a shade of colour, and never a number of people. Nothing about a single installation is published, and nothing is shown at all when fewer than 50 installations reported in that time.

Registering the installation. Before it reports anything, the app registers its installation with our server once: it does a short calculation in the background (about a second on most computers, never during a meeting) and receives a token that it sends with later events. This exists to stop made-up installations being reported to us; it sends nothing about you.

What gets linked. Events from one device are joined into one history, so we can see the steps one person took. When you start a free trial or use a Natively key, those events are linked to that trial or account. When you open a checkout page from the app, the link carries your installation identifier and the screen you came from, and Dodo Payments returns both to us with the purchase, so a purchase is linked to the installation it started from. Your purchase history is part of the same record: the purchase, each renewal, a cancellation, a failed renewal payment, and any refund or chargeback, with the product, amount, currency and billing country. It is tied to your account, and through your account to the devices it has been used on. This includes free trials and purchases made before this version of the app. We can look up one person's history by their email or device when we need to, for example to answer a support question.

Turning it off. Open Settings › General › Advanced and turn off Usage statistics. That stops these events, discards any that had not been sent yet, and stops the identifier being added to checkout links. It is on by default. If you email [email protected], we will also delete the events already reported for your device and account.

The switch does not change the records described in §3.2 for paid products and the Free Trial (the usage ledger, licence activity and the feature activity a licensed app reports). Billing and dispute handling depend on those, so they continue while you hold a licence or a plan.

3.3 What payment processors handle

Payments are processed by Dodo Payments. Card details, bank details, and similar payment-instrument data are handled by Dodo and are subject to Dodo's privacy policy. We receive transaction metadata from Dodo (order ID, amount, currency, status, billing email, and the installation identifier and screen name the app attached to the checkout link — see §3.2.1) but we do not receive or store full card or bank details on our servers.

3.4 What software updates send

The desktop application periodically checks for updates. Update checks reach GitHub's release infrastructure and transmit:

• The application's current version;
• Your operating-system family and architecture (e.g., macOS arm64, Windows x64, Linux x64).

This is the standard data sent by any GitHub-hosted update check and is governed by GitHub's privacy policy. No personal identifiers are sent.

3.5 Phone Mirror (Beta)

When you pair the desktop app with a phone via the Phone Mirror beta feature, a short-lived pairing token is generated and used to establish the connection. The session content (the mirrored screen and notifications) is not stored on our servers. You are responsible for the security of any device you pair and for the network on which the pairing happens.

3.6 Google Calendar (optional)

Connecting Google Calendar is optional. If you connect it, Natively asks Google for read-only access to your name and email address (to show which account is connected), the list of calendars you have turned on, and the events on those calendars. Natively cannot add, change, or delete anything in your calendar.

We use this data only for the calendar features you see in the app:

• showing your upcoming meetings, with a Join button that opens the meeting link stored in the event;
• linking a session you start to the calendar event it belongs to, so the saved notes carry that meeting's title, time, and attendees;
• naming the speakers in your notes: your own first name and, in a one-to-one meeting, the other attendee's first name;
• filling in the recipients of a follow-up email, which opens as a draft in your own Gmail. Natively never sends email for you.

The app fetches calendar data directly from Google to your device. The sign-in tokens are encrypted with your operating system's secure storage, and the details of an event are kept on your device with the meeting they belong to. Your calendar events are not stored on a Natively-operated server. Two things derived from this data leave your device:

• When Natively writes notes, answers, or a follow-up for a meeting, the text it sends to the AI provider you have chosen (see section 4.2; this can be Natively AI) can include the meeting's title and those speaker first names.
• To show attendee pictures, the app asks Gravatar for an image using a SHA-256 hash of each attendee's email address. The address itself is not sent.

Limited Use. Natively's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements. We do not use Google user data, whether raw, aggregated, or derived, to create, train, or improve foundational or generalized AI or machine-learning models, and we do not transfer it to anyone for that purpose. We do not sell it or use it for advertising.

You can disconnect at any time in Settings › Calendar, which deletes the stored tokens from your device. You can also remove Natively's access from your Google Account.

4. Where your data goes when you use AI / STT / search features

This is the most important section of the policy, so it's spelled out in detail.

When you use a feature that calls a third-party provider, the relevant input — usually a transcript, a prompt, or an audio chunk — is sent directly from your device to that provider to be processed, and the provider's response is sent back to your device. We do not relay this content through our servers (with one exception: the Natively API, where we relay through our infrastructure to provide a single managed endpoint).

The data sent to a provider is not anonymised — transcripts and prompts contain whatever you spoke or typed, including names, places, employer details, and the content of conversations. Please be mindful of what you send to a provider, just as you would be with any cloud service.

4.1 Speech-to-text providers

Apple Speech and the local Whisper models process captured audio on your device. Apple Speech uses the speech assets managed by macOS; the operating system may contact Apple to download a language asset the first time it is needed, but Natively does not send captured audio to Apple for transcription.

If you select a cloud speech-to-text provider instead, audio chunks may be sent to one of:

• Natively STT (operated by us, billed via the Natively API)
• Google Cloud Speech-to-Text
• Groq (Whisper via Groq)
• OpenAI (Whisper)
• Deepgram
• ElevenLabs Speech-to-Text
• Azure Speech Services (Microsoft)
• IBM Watson Speech-to-Text
• Soniox

Each of these providers has its own privacy policy and data-retention behaviour. We encourage you to review the policy of any provider whose key you configure. By default, most of these providers do not use API audio for model training, but check the current terms before sending sensitive content.

4.2 AI / language-model providers

Depending on your settings, prompts and transcripts may be sent to one of:

• Natively AI (operated by us, billed via the Natively API; routes to one or more underlying models)
• OpenAI (GPT family) — does not train on API data by default
• Anthropic (Claude family) — does not train on API data by default
• Google (Gemini family) — different defaults for free-tier vs paid; see Google's terms
• Groq (open-weights models hosted by Groq) — does not train on API data by default
• Ollama (local model running on your own machine — no data leaves your device)

By default, OpenAI, Anthropic, and Groq do not use API content to train their models. Google's behaviour depends on the tier. We encourage you to review the current terms of any provider whose key you configure.

4.3 Search providers

The search feature (where enabled) calls Tavily or, where you've configured it, another search provider. The query you've entered is sent to the search provider; the results are returned to your device.

4.4 Natively-managed services

When you use the Natively API (instead of BYOK), your inputs flow through our infrastructure to one or more of the providers listed above, and the response flows back. We do not persist the content of these requests. We do log request metadata (timestamp, plan, quota usage, status) for billing, abuse prevention, and quality monitoring; that metadata is retained for up to 90 days.

5. International transfers

The third-party providers listed above operate globally. Depending on the provider and your location, your data may be processed in jurisdictions outside your country of residence — most commonly in the United States (OpenAI, Anthropic, Google, Groq, Deepgram, ElevenLabs, IBM, Tavily), the European Economic Area (Azure where you've selected an EU region), and India (Natively-operated services).

By using the Service you acknowledge that your data may be transferred to and processed in these jurisdictions. Where a transfer is from the EEA / UK to a country without an adequacy decision, the receiving provider's standard contractual safeguards apply.

6. Cookies and the website

The Natively desktop application does not use cookies (it isn't a web app). The marketing website at heynatively.com may use:

• Essential cookies required for the site to function (e.g., session, CSRF, language).
• Analytics cookies to understand which pages are visited (the specific tool, if any, is documented on the website's cookie banner).

We do not run third-party advertising trackers or remarketing pixels.

7. Permissions the desktop app requests

To function, the desktop app needs the following operating-system permissions. You can revoke any of them at any time in your OS settings — though the corresponding feature will stop working.

• Microphone — to capture audio from microphone-input meetings.
• Screen Recording / Screen Capture — to capture system audio (on macOS, this is bundled into the same permission) and to capture screen content for Vision features.
• Accessibility — required on macOS for global hotkeys, window-management, and certain capture paths.
• Notifications — to alert you when summaries are ready, when a session ends, etc.
• Network — to call AI / STT / search providers, verify your licence, and let macOS download an Apple Speech language asset when one is not already installed.

We request the minimum necessary set for the features you've enabled.

8. Security measures

We follow industry-standard practices for the limited data we do hold:

• In transit: all communication with our license server, the Natively API, and any third-party provider is over HTTPS / TLS. The desktop app rejects unencrypted endpoints for these services.
• At rest (on our servers): the metadata we store (license keys, hardware IDs, billing email, quota counters) sits behind authentication on managed infrastructure. Backups are encrypted at rest.
• At rest (on your device): local data (the SQLite meeting database, transcripts, settings via electron-store) is not encrypted by Natively at the application layer. Please use full-disk encryption (FileVault on macOS, BitLocker on Windows, LUKS on Linux) to protect your local data.
• Secrets in code: API keys and secrets are never embedded in shipped builds.
• Access: as a single-developer project, server-side data is accessible only to the developer, and only for legitimate operational purposes (handling support requests, debugging billing issues, fraud prevention).

For information on how to report a security vulnerability, see our Security Policy.

9. Your rights

You have the following rights in respect of personal data we hold about you:

• Access — you can ask what data we hold about you and receive a copy.
• Correction — you can ask us to correct data that's inaccurate or incomplete.
• Erasure — you can ask us to delete your account and the data associated with it. Where a record must be kept by law (for example accounting and tax records), we pseudonymise it rather than keep it identifiable: your billing email, installation identifiers and licence-key hash are erased from the usage ledger, and the remaining rows are re-keyed to a salted hash so they survive only as an anonymous count for accounting. The salt is not stored, so the link back to you cannot be rebuilt afterwards. If a payment dispute is open when you ask, we hold the underlying records until it closes and pseudonymise immediately after.
• Portability — you can ask for a copy of your data in a machine-readable format.
• Withdraw consent — where processing relies on your consent, you can withdraw it at any time. (Note that this may require us to terminate paid services that depend on the data.)
• Object — you can object to processing that relies on legitimate interest (e.g., anti-abuse).
• Complain — you can lodge a complaint with the relevant data-protection authority (in India, the Data Protection Board under the DPDP Act 2023; in the EU/UK, your local supervisory authority).

To exercise any of these rights, email [email protected] with your order ID and a description of your request. We aim to respond within 30 days.

If you're in California, you may have additional rights under the California Consumer Privacy Act (CCPA) — including the right to know, the right to delete, and the right to opt out of "sale" of personal information. We do not sell personal information. You can exercise CCPA rights by emailing the same address.

10. Children's privacy

The Service is not directed at children under 18 and we do not knowingly collect personal data from anyone under 18. Use of paid products requires you to be at least 18 (see Terms & Conditions §2.1). If you believe a child has provided us with personal data, please email us and we'll delete it.

11. Communications from us

By using paid products you'll receive operational emails related to your purchases, licence, security incidents, terms changes, and billing. These emails are part of the Service and you cannot opt out of them while the relevant relationship is active.

Marketing emails (product updates, feature announcements, promotions) are optional and you can opt out at any time using the unsubscribe link, or by replying to the email.

12. Source transparency

The desktop application source is available on GitHub at https://github.com/evinjohnn/natively-cluely-ai-assistant under the Natively Personal Use Source License v1.0. You are welcome to audit the code to verify the claims in this policy.

A small caveat: source availability does not by itself guarantee that the binaries we distribute are byte-for-byte produced from that source — reproducible builds are a separate effort we don't currently provide. If you require reproducible binaries, build from source.

13. Changes to this policy

We may update this policy from time to time. Material changes will be announced in-app, on the website, or by email, with a revised "Last updated" date at the top of this page. Continuing to use the Service after a change means you accept the updated policy.

We don't make adverse changes (e.g., expanding what we collect or share) without giving you prior notice and a chance to opt out by stopping use of the Service.

14. Contact

For privacy questions, data-rights requests, complaints, or anything else covered by this policy:

Email: [email protected]

Grievance Officer: Evin John — [email protected] — acknowledgements within 72 hours on weekdays, resolution targets of 30 days.

We may not respond on weekends or Indian public holidays — if you write in over a weekend, please expect a reply early the following week.