Privacy policy

Earkeep transcribes your meetings locally, on your device. Your audio is processed only in memory and is never written to disk and never uploaded anywhere. Your transcripts are saved as plain files on your own computer, under your control. There's no account and no cloud storage of your meeting data, and nothing from your meetings is ever sent to us.

Three things reach a server, and none of them is your meetings: our own service at earkeep.com (which starts your trial, checks your license and, unless you switch it off, receives usage statistics about which features you use), Creem (our merchant of record, who handles your purchase and issues your license key), and our own self-hosted, cookieless website analytics. A fourth is Google, because we advertise and would like to know which ads lead to a download: Google's tag loads on every page of this site, but it is denied permission to store anything unless you allow it, and as things stand it stores nothing either way. All four are described in detail below, with nothing left vague.

Audio. While Earkeep is running, it processes microphone and system audio only in memory, to run local transcription. That audio is never written to disk in any form, and it is never sent to Earkeep, to us, or to any third party. There is no server that receives your audio, no API call that carries it, and no upload step of any kind.

Transcription. Transcription runs entirely on your device, using Whisper or Parakeet models running locally with Apple Silicon hardware acceleration. Earkeep does not call out to any transcription APIs to do this work.

Storage. Transcripts are saved as plain files on your device, in a location you control. You can open them, search them, back them up, or feed them to any tool you choose. We don't have a copy. There is no Earkeep server that stores, syncs, or backs up your meeting transcripts. If you keep the transcripts folder in a git repository of your own, Earkeep commits the files there and pushes them to the remotes you set up, under your own account; both are settings you can turn off, and nothing in it reaches us.

Deletion. Because the files are yours and there is no copy anywhere else, deleting is immediate and complete. In the app you can purge a selected stretch of a day or delete a saved meeting together with its transcript; you can also just delete the files yourself. Nothing is written in place of what you removed, there is no recycle bin, and nothing has to be reconciled against a server, because there is no server. It also means there is no undo.

Stopping capture. Earkeep runs continuously while it is open by default, and you can stop it: pause from the transcript for a set time or until you resume, or mark an event on a connected calendar so capture stops for the length of that meeting. You can also change when it runs at all, with the calendar-driven mode in Settings → Recording & calendars, which keeps the microphone released except around the meetings on your agenda. Pausing releases the microphone and the system audio stream instead of discarding what they hear, which is why your operating system's own recording indicator goes dark while it lasts. Neither pausing nor deleting is logged anywhere: a stretch you paused reads afterwards like a stretch where nobody spoke.

No account required. Using Earkeep, including the full 14-day trial, requires no email address, no sign-up, and no cloud account of any kind.

Other people's privacy is yours to look after. This policy covers what we do with data, and the answer for your meetings is that we never receive any. It cannot cover what you owe the people you record. Earkeep announces itself to nobody: no bot joins the call and no banner appears on anyone else's screen, so unless you tell the room, nobody in it knows. Many places require you to say so beforehand and some require everyone's agreement, not just yours. Earkeep asks you to acknowledge this when you first run it, and repeats it under the transcript, but acknowledging it is not the same as it being handled. Telling people you're recording covers what to say and how to stop; the terms set out the responsibility itself.

Calendar connections. If you connect Google Calendar, Apple Calendar, Microsoft Outlook, or an ICS calendar URL so Earkeep can start and end meeting spans automatically, that connection is read-only and is used only to read event titles, start and end times, and the handful of facts that tell Earkeep whether an event counts (all-day, cancelled, declined, and whether anyone besides you is on it). The app on your device talks to the provider directly: no Earkeep server sits in the middle, receives your events, or keeps a copy of them. Earkeep never writes to your calendar, never creates, edits, or deletes events, and never asks for your mail, contacts, files, or anything else in your account. The Google connection is described in full in the next section.

In-app agents and MCP. Earkeep lets you run other local agent apps (Claude Code, Codex, Cursor Agent, Gemini CLI, and others) directly against your meeting history, and exposes an MCP server so external tools can read your meetings too. These are integrations you choose to use and configure yourself; whatever data leaves your machine through them is governed by the privacy policy of whichever agent or tool you've connected, not by Earkeep. Earkeep itself doesn't relay your meeting data anywhere on its own. The one time Earkeep starts an agent by itself is to resolve a conflict when pushing to your own git repository, if you have an agent set up and have not turned that off; it runs the same agent, under the same terms.

Connecting Google Calendar is optional. If you do connect it, here is exactly what Earkeep asks for and what happens to it.

The one scope we request. Earkeep requests a single OAuth scope, https://www.googleapis.com/auth/calendar.readonly. It is read-only, and it is the narrowest scope that lets the app do the one job you connected it for: know when your meetings start and end, so a span on your timeline can be created and named without you doing it by hand. Earkeep requests no other Google scope, and a read-only scope cannot modify anything in your account even if it tried.

What we do with the data. Event titles and times are read by the app on your device, matched against your timeline, and used to create and label meeting spans. That is the whole purpose, and it is the only purpose.

What we never do with it. Google Calendar data is never transferred to Earkeep's servers, never sold, never shared with any third party, never used for advertising or for any credit or lending purpose, never used to train, retrain, or improve any machine-learning or AI model, and never read by a human at Earkeep. We could not read it if we wanted to: it is on your device and never reaches us.

How the credentials are protected. The connection uses the OAuth 2.0 authorization code flow with PKCE, in your real browser, redirecting to a loopback address on your own machine, with the state parameter verified on return. Earkeep never sees or handles your Google password. The short-lived access token lives only in memory and expires; the refresh token is stored in your operating system's own credential store (Keychain on macOS, Credential Manager on Windows) under the service name earkeep. It is never written to a configuration file, never written in plain text anywhere, and never transmitted to us or to anyone but Google.

What is cached on your device, and for how long. So the app can still show your day when a provider is unreachable, Earkeep keeps a small local cache file of the events it last fetched, covering only a rolling window of 7 days either side of today. It lives in Earkeep's own application data folder on your device, and days that fall outside that window are deleted automatically, both whenever the cache is written and once a day while the app runs. No other copy of your calendar data exists.

Revoking access, and deleting the data. Settings → Recording & calendars → Disconnect deletes the refresh token from your credential store immediately, and the app stops fetching from that point. You can also revoke Earkeep's access at any time from your Google Account at myaccount.google.com/permissions, which is authoritative regardless of what any app has stored. Cached events roll off on their own as the 7-day window moves, so within a week of disconnecting nothing is left; deleting Earkeep's application data folder removes them at once.

Limited Use. Earkeep's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

The Microsoft Outlook connection works the same way, with the read-only Calendars.Read Microsoft Graph scope and the same keychain storage. An ICS URL is stored in the same credential store, not in a config file, because a private ICS link is itself a secret.

Security procedures are in place to protect the confidentiality of your data, and we use encryption to protect it. Concretely:

• The strongest protection is not holding the data. Your audio is processed only in memory and never written to disk. Your transcripts stay in files on your own device. Your calendar events are fetched by the app straight from the provider. None of these ever reach a server we run, so there is no central store of meeting content to breach, subpoena, or leak.
• Encryption in transit. Every network call Earkeep makes is over HTTPS with TLS: to Google and Microsoft for calendar events and token refreshes, to your ICS feed, to Hugging Face for transcription model downloads (and, when you add a model of your own, for looking up the one you named), and to our own licensing service. The website is served over HTTPS only.
• Secrets encrypted at rest, in the OS credential store. Calendar refresh tokens and ICS URLs are held by your operating system's own credential store (Keychain, Credential Manager), which is encrypted at rest and access-controlled by the OS, not in a file an unrelated program could read.
• Encryption and hashing on the licensing service. Hardware fingerprints, license keys, and request IP addresses are stored only as peppered HMAC-SHA-256 hashes, which we cannot reverse. The one value we must be able to read back, the license key needed to re-validate with our merchant of record, is encrypted with AES-256-GCM. The pepper and the encryption key live only in the server's environment, so the database file and its off-site replica carry no usable secrets on their own.
• Access control. The licensing service runs on infrastructure we operate, reachable only over key-based SSH by the maintainers who run it. There is no admin console, no support portal, and no third-party dashboard with a view into the database. Backups replicate to object storage that is encrypted at rest and private.
• Data minimization by design. The licensing service stores one row per device: a hashed fingerprint, a trial start date, platform and app version, and when it last checked in. Next to it sit that device's usage statistics, which are settings, counts and fixed names. There is no account, no name, no email, no profile, and nothing about your meetings.
• Retention and deletion. Calendar data on your device is capped at the rolling 7-day cache described above and pruned automatically. Licensing rows are kept while the trial or license is live, plus a short activation history so we can answer you if you write in. Usage statistics are kept with the device row they belong to, and deleted with it when you ask. Support email is kept only as long as needed to resolve your request. Anything on your device is deleted the moment you delete the files or uninstall the app, because your device is the only place it lives.
• If something ever went wrong. In the event of a security incident affecting data we hold, we will notify affected users and the relevant supervisory authority as required by law. The scope of what such an incident could touch is bounded by the list above, and does not include your meetings.

Earkeep is sold through creem.io, which acts as the merchant of record for every purchase. That means Creem, not Earkeep, is the party that actually processes your payment and is responsible for the data involved in doing so.

When you buy Earkeep, Creem's hosted checkout collects and processes:

• Your email address (to send your license key and receipt)
• Your payment details (processed by Creem and its payment processors; Earkeep never sees or stores your card details)
• Billing information needed for tax/VAT compliance, where applicable

Creem then issues a license key by email. That key, and the fact that it's associated with a license instance on your device, is what Earkeep itself stores and checks.

Starting your trial. The first time Earkeep runs, it registers the device with our licensing service at earkeep.com. This happens before any purchase, and it is the one thing the app does that we ask you to know about up front. It sends a one-way hash of a hardware identifier, the platform name, and the app version. Nothing else — no email, no account, no name, and nothing from your meetings. The hash is what lets us stamp your 14-day trial once, so that reinstalling the app doesn't hand out a second one; we cannot reverse it back into an identifier for your machine, and we never share it.

License activation and validation. When you activate your license, Earkeep sends the key to that same service, which verifies it with Creem and records your device as the license's active instance. The app never contacts Creem directly — Creem's license API requires a secret key that cannot safely live inside a downloadable app, so our server holds it and makes the call. Afterwards Earkeep checks in about once a day. These checks use an offline grace period: Earkeep does not phone home every time you launch the app, and a week without internet won't interrupt your use of it. License enforcement shouldn't mean constant network chatter, and it never touches your meeting data — only the key, the device, and whether the two still go together.

What that service stores. One row per device: the hashed hardware identifier, the date your trial started, the platform and app version, and when we last heard from you. If you buy a license, it also stores the license key (encrypted), which device currently holds it, and a short history of activations and moves so we can answer you if you email us about it. Request IP addresses are used to rate-limit abuse and are stored only as a hash, never in the clear. Unless you switch them off, the same service also receives the app's usage statistics, described in the next section. There is no account, no profile, and nothing to log in to.

The app tells our licensing service how it is set up and which of its features get used, so that we know what to improve and what nobody uses. It is on by default, and one switch turns it off: Settings → General → Share usage statistics. Switching it off sends one last message saying so, and nothing after it.

What is sent. The app's settings as plain facts (which transcription model, whether a calendar of each kind is connected, whether capture is always on or follows the calendar, how git is set up), the platform, OS version, processor and memory, how fast the chosen model transcribes on this machine, and counts: minutes the app ran and minutes it transcribed, pauses, agent sessions, and which MCP tools other apps called. It also sends a short note when something happens: a step of the first-run setup, a meeting span saved, renamed or deleted, a model downloaded, a calendar connected, a Settings section opened, a Buy button pressed, an update offered.

What is never sent. Nothing from your meetings: no meeting titles or notes, no transcript text, no calendar event names or calendar names, no account emails. Nothing you typed: no folder paths, no names of your own agents, templates or models, no git remote addresses or commit messages, no search queries an agent sent, and no audio, ever. Where a fact involves something you typed, the app sends a yes or no, a number, or a fixed name instead. A meeting span is never named, and not even its time is sent: each one is identified by a one-way code that only this device can link back to the span.

How it is tied to you. Each message carries your device's id, the same one shown in Settings → General under your license, and nothing that names you. The messages are stored next to that device's licensing row, kept with it, and deleted with it if you ask.

Our own website analytics is self-hosted and cookieless, and that part has not changed. Concretely:

• It sets no cookie. A session id lives in your browser's own sessionStorage for 30 minutes and is gone when you close the tab.
• It goes to us, not to a data broker. The collector runs on our own infrastructure, so these numbers are not a product anyone else is selling.
• Only aggregate data is collected: page views, referrers, rough visit counts, and which pages get clicked. None of this is tied to an individual identity, and none of it touches the app or your meetings, which run entirely separately on your device.

Separately from analytics, the site opens in the language your browser asks for when it has that page translated. If you pick a language from the list at the foot of any page, we remember that pick in a cookie named earkeep-lang. It holds the language code and nothing else, lasts a year, and is only set when you click.

This is the one place a third party reaches your browser on earkeep.com, so here is the whole of it, including the part that changed. We buy ads on Google to get this app in front of people who would use it. What we cannot tell from our own analytics is which of those ads actually led anywhere, and the only way to know is to let Google's own tag see that someone who clicked an ad reached the download page.

Google's tag asks for three separate permissions, and Allow grants exactly one. It grants the permission Google calls ad storage: keeping an identifier that can link an ad click to a download. We refuse the other two outright, for everybody, whichever button you press: sending your data to Google for advertising, and using it to personalise ads or build the remarketing audiences that follow people between websites. We buy ads on search results. Neither of those is any use to us, so neither is worth asking you for.

The result, measured rather than assumed: Google's tag sets no cookie here at all. We checked on 16 September 2026 on this domain, before and after pressing Allow, across more than one page: nothing. Granting all three permissions, which we do not, makes Google set an identifier on earkeep.com that lasts 90 days. Refusing two of them appears to make the whole thing not worth its while. We still ask, because Allow is permission to store and Google could start using it in a later version of their tag, and because we would rather ask for a permission we are not using than assume one. If that day comes, this page changes before the behaviour does.

We changed how this works on 16 September 2026, and one part of it is a step back from what this page promised. Until then Google's script was not fetched at all until you pressed Allow. That was stricter, and we would have preferred to keep it, but it did not survive contact with how Google works: Google decides whether a tag is installed by loading your pages itself, and it does not press Allow, so our tag read as broken and we could not tell whether any of the advertising was working at all. Google's tag now loads on every page, in the mode Google calls consent mode, with every permission denied until you say otherwise.

What that means in practice:

• Google does learn the visit happened. This is the honest cost of that change and we are not going to bury it. Loading a script from Google means Google sees your IP address, which page you are on and what browser you use, the same as any third-party script on any website. We additionally tell Google's tag to strip ad click identifiers from what it sends while you have not agreed, so those requests carry nothing that ties them to you or to each other.
• Nothing is stored before you agree, and as it stands nothing is stored after. The permission is the thing you are being asked about; the storage is Google's to use or not, and today it does not.
• Saying no costs you nothing. No feature of the site, the download, the trial, or the app depends on it. The bar goes away and does not come back, and we are left with a rougher idea of our own ad spend, which is our problem rather than yours.
• We count downloads, not people. What the advertising side of this measures is that somebody reached the download page. Google is not told who you are, what you read, or anything about the app, and the app itself has no part in this at all: it never talks to Google, and nothing on this page applies to your meetings.
• You can change your mind. The button below clears your answer and puts the question straight back, and saying no then actively withdraws the permission rather than merely stopping short of granting it. Clearing this site's data in your browser is the way to remove anything that did get stored.

If you have JavaScript turned off, none of this can run at all, so the tag never loads and there is nothing to answer.

If you email [email protected] (support, license issues, feature requests, or anything else), that message and your email address are used only to have the conversation and resolve whatever you wrote in about. We don't add you to a marketing list from a support email, and we don't share your email with anyone outside of what's needed to help you.

Because transcription and storage happen locally on your device, Earkeep the company never holds a copy of your meeting audio or transcripts. There's nothing on our servers to request, correct, or delete on that front, because it was never sent to us: your device is the only place that data ever exists.

The data that does involve us is narrower and handled by named parties:

• Purchase data (email, payment, license key) is processed by Creem as merchant of record. Rights around that data (access, correction, deletion) are best exercised through Creem directly, or by emailing us and we'll help route the request.
• Support email correspondence is held only as long as needed to resolve your request. Email [email protected] if you'd like a copy of, or the deletion of, correspondence you've sent us.
• Usage statistics from the app are stored against your device's id. Email [email protected] with the id shown in Settings → General and we'll send you what we hold for it, or delete it along with the device's licensing row.
• Website analytics are aggregate and not tied to an individual, so there's no per-person record to request or delete.
• The advertising cookie is only ever set if you agreed to it, and you can withdraw that agreement at any time from the section above or by clearing this site's data in your browser. What Google holds against its own ad click is Google's to answer for; their controls are at My Ad Center.

For any privacy question or request not covered above, email [email protected] and we'll sort it out directly. There's no ticketing system standing between you and an answer.

If this policy changes, we'll update the effective date and describe what changed. Because Earkeep is local-first by design, we don't expect the core promise (your audio and transcripts never leave your device) to change; if it ever did, that would be the most prominent thing on this page, not a quiet edit.

20 October 2026. The app now sends usage statistics to our licensing service: its settings, counts, and short notes about which features get used, never anything from your meetings. It is on by default and Settings → General switches it off. The short version above no longer says there is no telemetry, because now there is, and this policy says exactly what it is.

12 October 2026. Added how the optional git integration fits in: Earkeep commits your transcripts to a git repository you own and pushes them to remotes you set up, which never reaches us and can be turned off, and it may start your own agent to resolve a conflict while doing so.

16 September 2026. Google's advertising tag now loads on every page of this website with every permission denied, rather than not loading at all until you agreed, so Google does now see that a visit happened. In the other direction, Allow was narrowed to a single permission, and with the other two refused Google's tag sets no cookie here at all. The reasoning and the measurements are in the advertising section. Nothing about the app changed: your audio and transcripts still never leave your device, and the app has never talked to Google.

Questions about any of this go to [email protected].