Privacy Policy

Blurt is a macOS menu-bar dictation app. You hold your configured push-to-talk key, speak, and Blurt transcribes your voice, lightly formats the text, and types it into your active app. Where your audio is processed depends on which mode you use. This policy explains each one, what is stored, and who we share data with. It is written to match what the software actually does — please read the mode that applies to you.

1. Who we are

"Blurt", "we", and "us" refers to the maker of the Blurt app. The controller within the meaning of Art. 4(7) GDPR — the same person named in our Impressum — is:

Ivan Chabanenko
Lutherstraße 12
39112 Magdeburg
Deutschland / Germany
Email: support-blurt@chbnk.one

Blurt is run by an individual (Einzelunternehmen) and is not required to appoint a data protection officer. For dictation processed by ready, selected local speech and clean-up models, Blurt does not receive your audio or text, and you control the data on your device. For the managed Cloud plan, where audio passes through our server, Blurt is the data controller for that processing and the providers listed below act as our processors under Art. 28 GDPR.

2. The two modes — and where your voice goes

Blurt can transcribe your speech in two different ways. The mode in effect depends on your Mac and your settings.

2a. On-device (default on Apple Silicon)

Fully local dictation requires both speech and clean-up models to be installed and selected. In Blurt 0.3.27 and later, On-device mode never switches to cloud processing automatically. When both stages run locally, your dictation audio and text stay on your Mac. Local models are downloaded on demand to your Application Support folder. Versions before 0.3.27 could send transcripts to cloud clean-up when a local model was unavailable; update Blurt to use the explicit On-device mode.

That download is the one moment this mode uses the network, so here is who sees it. Blurt asks our own mirror first and falls back to Hugging Face, where the model files are published; whichever of the two serves the file sees the request your Mac makes for it, including your IP address, as any file download does. As this is written on 1 September 2026 the mirror is not switched on — it is described in the Cloudflare row of our processor list — so in practice the file comes from Hugging Face. Hugging Face is not our processor and is not on that list: it publishes the model to everyone, not to us on our instructions, and is an independent controller of its own server logs. Nothing of yours travels in that request — it asks for a file, and it is the same file for everybody who asks.

2b. Managed Cloud (Blurt Pro)

With the paid Cloud plan, Blurt handles transcription for you using our own keys. In this mode your audio is uploaded over TLS to Blurt's backend at api.blurt.me, which relays it to a third-party speech-to-text provider using Blurt's server-held keys. Which provider that is depends on the model you pick in the app:

• Live (streaming) speech, the words that appear in the pill while you hold the key — Soniox (stt-rt-v5, the default) or ElevenLabs (scribe_v2_realtime). Both receive your voice as it is spoken.
• Batch speech, the recording sent after you release the key — Groq (whisper-large-v3-turbo, the default) or OpenAI (gpt-4o-mini-transcribe, whisper-1). You can pick Whisper on Groq in the app as your speech model; it shows no live words. Groq also transcribes a take whose live stream failed midway, and the app then names Groq's model in the pill instead of using it silently.

The provider returns a transcript, which our backend returns to your Mac. Our backend relays the audio and does not store the audio file after the request completes. However, on this plan your audio and the resulting transcript do pass through Blurt's server and the third-party provider named above. We do not use your audio or transcripts to train any model, we do not authorise our providers to do so either, and we do not sell them. This plan requires an account (see Accounts & stored data).

On the Cloud plan, the resulting transcript text is then sent over TLS to a language-model provider to clean up filler words and punctuation, apply your chosen writing style, carry out spoken edit commands, and — if you use the Translate feature — translate it. That provider receives the transcript text only, not your audio, and returns the polished text to your Mac:

• OpenRouter serves the clean-up model (openai/gpt-oss-120b), in two rows you choose between in the app. OpenRouter is a router, not the machine that runs the model: it forwards the request to a host, and each row names its hosts. The default row may go to Baseten or Nebius; the row named Groq goes to Groq only. A request never leaves the hosts of the row you picked. Your transcript therefore reaches OpenRouter and the host that serves it.
• OpenAI serves gpt-4o-mini and is the fallback for any model not listed above.

In Blurt 0.3.27 and later, On-device mode keeps formatting local. If a required model is missing, Blurt asks you to download it; it does not send the transcript to cloud clean-up automatically.

3. Processors we use

Depending on the mode and features you use, we rely on the following providers to deliver the service. Most of them are processors acting on our instructions under Art. 28 GDPR — Blurt is the controller, and they do not decide on their own what to do with your data. Not every entry below is that, and the ones that are not say so in their own words rather than hiding under this sentence: the sign-in providers, which are independent controllers for their own sign-in service, and our support mailbox, for which no processing agreement exists. We share only what each one needs for its function. We do not authorise any of them to use your content to train their models, and we do not sell your data.

Correction, 1 September 2026. Until this date the list below, and the processor page it points to, left out two companies that do receive personal data: Cloudflare, which holds the off-site copy of our database, routes our support mail and runs the panel we read tickets in, and Google, whose mailbox that support mail is delivered into. Both were already in use — nothing about where your data goes changed on this date, only what we tell you about it. They are named below and on the processor page now. The change log there records what was missing and for how long.

The table itself — what each provider receives, where it is located, and the transfer mechanism — is on our list of processors, which also carries the date of the last change and our promise to announce new providers normally 30 days in advance — and, where a failure or a security problem forces a faster swap, to update the list without delay and say why.

• Soniox — real-time streaming speech-to-text on the managed Cloud plan (2b), and the default for the live row of words. Receives your voice audio and returns an incremental transcript. Not used for on-device dictation. Privacy policy.
• ElevenLabs — the second real-time streaming speech-to-text provider on the managed Cloud plan (2b), used when you select that model in the app. Receives your voice audio and returns an incremental transcript. Not used for on-device dictation. Privacy policy.
• Groq — the default batch speech-to-text provider on the managed Cloud plan (2b). Receives your voice audio (relayed by our backend) and returns a transcript. When you pick the clean-up row named Groq it also runs that model (see OpenRouter below), and then receives your transcript text. Not used for on-device dictation. Privacy policy.
• OpenAI — batch speech-to-text and text clean-up. Receives your voice audio and/or transcript text when you pick an OpenAI model on the managed Cloud plan (2b), or as the fallback clean-up provider. Privacy policy · API terms & data usage.
• OpenRouter — routes the default clean-up model on the managed Cloud plan (2b). Receives your transcript text (not audio) and forwards it to one of the hosts we allow. Privacy policy.
• Baseten and Nebius — the hosts OpenRouter may forward the default clean-up request to; Groq — the host of the clean-up row named after it, used only when you pick that row. Each receives your transcript text (not audio) when it serves the request. Baseten privacy · Nebius privacy · Groq privacy.
• DeepInfra — a former text clean-up provider, withdrawn on 23 August 2026. It serves no model and receives nothing. It is still named here, rather than quietly deleted, because it did receive transcript text before that date. Privacy policy.
• Cerebras — a standby text clean-up host. It is configured in our backend but currently serves no model and receives nothing; it is named here so that re-enabling it is not a surprise. If it is ever switched on it would receive transcript text (not audio), and we would announce it on the processor list first. Privacy policy.
• Hetzner Online GmbH — hosts our backend and database, in a data centre in Germany. Processes everything our backend processes, as our infrastructure provider. Privacy policy.
• Cloudflare — several roles, one company, and they apply whichever mode you dictate in. It holds the daily off-site backup of our database, which is a complete copy: account emails and names, password hashes, Stripe identifiers, support tickets and their messages — and, in the same backup, our analytics database: the website's visit counts (6f), the payment events filed under your account identifier (6g) and, if you switched them on, the app's usage counts (7). When you delete your account, our server's request to erase those events passes through Cloudflare's network on its way to our own server; it carries your account identifier and nothing else. So does a request to erase the usage counts of an install when you withdraw (7d); it carries that install's random identifier and nothing else. It runs the panel we read support tickets in, so a ticket you send — your address, your subject and your words — passes through it while it is on screen, though it is not stored there. And it routes the mail you send to our support address into the mailbox below. It also receives crash reports, which carry no identifier of any kind, and is the DNS provider for blurt.me — a role that puts none of your browsing in front of it, because this site's records are not proxied. Privacy policy.
• Google, as our support mailbox — separate from the sign-in row below, and not the same answer. Mail you send to our support address, and the notification our server raises for every new ticket, are delivered into a Google mailbox and kept there: your email address, your account identifier, the subject and your words. Our answer goes out from our own server, not from that mailbox. It is an ordinary consumer Google account, which means there is no data processing agreement behind it — we state that plainly on the processor page instead of implying one. Privacy policy.
• Stripe — processes payments and manages billing for the paid plan. Receives your email address, payment card details, and billing address; it does not receive your audio or transcripts. Privacy policy.
• Resend — sends transactional email (email verification, password reset, the subscription confirmation, support messages). Receives your email address and the contents of those messages; it does not receive your audio or transcripts. Privacy policy.
• Apple and Google (sign-in only) — only if you choose to sign in with "Sign in with Apple" or Google. The provider you pick handles the sign-in and returns a basic identifier and email to us. Here they are independent controllers for their own sign-in service, not our processors. Apple privacy · Google privacy.

4. International transfers

Our servers and database are in Germany (Hetzner). Most of the processors listed above are, however, established in the United States and process the data they receive there or in other countries outside the European Economic Area. That means your dictation audio or transcript leaves the EEA whenever you use the managed Cloud plan.

Some of it leaves the EEA even if you never use that plan, and this policy said nothing about it until 1 September 2026. Your account lives in a database that is copied to off-site backup storage at Cloudflare once a day; a message you send to our support address is routed by Cloudflare and lands in a Google mailbox. Neither depends on which mode you dictate in — an on-device user with an account is in that backup like everyone else. The mechanism for the Cloudflare transfer is the one described below; for the support mailbox there is none, which the processor page states rather than covers up.

For each such transfer we rely on one of the two mechanisms the GDPR provides:

• Art. 45 GDPR — adequacy. Where the provider is certified under the EU–US Data Privacy Framework, the transfer is covered by the European Commission's adequacy decision of 10 July 2023. You can check any company's current certification in the official DPF list.
• Art. 46(2)(c) GDPR — Standard Contractual Clauses. Otherwise we rely on the Standard Contractual Clauses in the version adopted by Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor), as contained in that provider's data processing terms, together with the supplementary measures described on our security page (transport encryption end to end, no storage of audio on our side, no training use).

The United States does not offer a level of protection identical to the EEA: in particular, US authorities may have access rights that have no equivalent under EU law, and the enforcement routes available to you differ. We tell you this plainly rather than burying it. To keep dictation content on your Mac, install and select both local speech and clean-up models and check that the app shows both stages as local. Account and other service data described in this policy are separate from dictation content.

Which mechanism applies to a specific provider, and a copy of the clauses where we are allowed to share them, is available on request: email support-blurt@chbnk.one and we will answer in writing.

5. On-device dictation history

By default, Blurt keeps a history of your dictations on your Mac so you can review and re-copy past results. This history is stored locally on your device (using SwiftData, under ~/Library/Application Support). It holds up to the most recent 1,000 entries, and each entry includes the raw transcript, the cleaned-up text, the name of the app you dictated into, and a timestamp.

This history is stored unencrypted on your Mac and persists after you quit Blurt until it is cleared or rolls over past 1,000 entries. It stays on your device — Blurt does not upload your history. Because dictation can include sensitive content, you can control it:

• Turn it off: enable Privacy Mode in Blurt to stop new dictations from being saved to history.
• Clear it: clear the stored history from within the app at any time.

Before you sign in, and if you never do. Blurt keeps this history — together with your Workspace documents and their edit history, your dictation statistics and your personal dictionary — on your Mac, filed under no account. The first time an account signs in on a Mac where no account had signed in before, Blurt copies these into that account's own storage on the same Mac, once. Signing in uploads none of it; the copy adds to what the account already has on that Mac and replaces nothing, the statistics are copied only if the account has none there yet, and the no-account copy stays where it was. An account that signs in on that Mac later receives none of it. Your settings — language, dictation key, microphone, models, appearance — are stored on the Mac, not in an account, and signing in does not change them.

6. Accounts & stored data

On-device dictation needs no account. An account — free, with a confirmed email address — is needed for the managed Cloud plan, both for its free cloud words and for Blurt Pro. The app asks you to sign in when you use the cloud, and you can also sign in from the first screen of its setup. Once you have an account, our backend (a PostgreSQL database, hosted in Germany) stores the following, depending on how you sign up and use the service:

• Account details: your email address and name.
• Authentication: if you use email/password, a scrypt hash of your password (never the password itself); if you use Google or Apple, the OAuth provider, the subject identifier they assign you, and the email they return.
• Sessions & devices: hashes of your refresh tokens together with the device User-Agent, so you can stay signed in across devices and we can detect token misuse.
• Usage: monthly word counters, used to operate and meter the service and to enforce the fair-use ceiling described in our Terms. The counters hold numbers only — never the text you dictated.
• Subscription: the Stripe subscription and customer identifiers, plan, status and period end. Card numbers are held by Stripe, never by us.
• Email/security tokens: short-lived tokens for email verification and password reset.
• Free-trial device marker: a salted hash of a per-Mac identifier — the one macOS hands the app for your machine, or, when macOS does not answer, a random one the app generates once and keeps on your Mac. We store it so that the Blurt app does not start a second free trial on a Mac that has already started one — including from a new account, and including after the first account is deleted. It binds what the app does, not what the machine can do: it is a speed bump against reusing the trial, not a guarantee that the trial cannot be reused. The raw identifier is never stored, and the hash cannot be turned back into it.

We include no third-party analytics, tracking or crash-reporting SDKs in the app or on this website — no Google Analytics, no Firebase, no Sentry, no advertising or attribution kit, and our marketing and legal pages load no third-party resources. Checkout loads Stripe’s payment library and embedded payment fields directly from Stripe. That sentence is about other companies, and read on its own it would leave you with the wrong impression, so here is the other half plainly: Blurt does collect usage analytics and crash reports of its own. Both are off unless you switch them on, both are governed by the same single switch, neither contains any text or audio, and both are described in full in Section 7 — including that, with your yes and while you are signed in, the usage counts are linked to your account identifier (7c); crash reports never are. This website counts its visits with analytics we run ourselves, without cookies and without anything stored on your device — see Section 6f. And if you subscribe, the payments of your subscription are recorded in that same analytics of ours under your account identifier — never your name, email or card — and erased with your account: Section 6g.

6a. Connection metadata

When your app or browser connects to our backend, we process standard connection metadata — your IP address and User-Agent — server-side to operate the service securely and to prevent fraud and abuse (for example, rate-limiting). The website's static pages are served without request logging by our web server; how visits to them are counted is in Section 6f.

6b. Lawful basis (GDPR)

Where GDPR applies, we rely on:

• Art. 6(1)(b) — performance of a contract. Your account, the paid Cloud plan, and the dictation itself: relaying your audio to a speech provider and your transcript to a clean-up provider is the service you asked for. This is the basis for the core function, not consent.
• Art. 6(1)(f) — legitimate interests. Connection metadata, rate limiting, the free-trial device marker and other abuse and fraud defence — our interest being to keep a small service affordable and available to the people paying for it. Also the counting of visits to this website (Section 6f) — our interest being to know whether the site and checkout work for the people who come to them — and the payment events of a subscription (Section 6g) — our interest being to know what the service earns, how many subscriptions continue and why they end.
• Art. 6(1)(c) — legal obligation. Billing and invoice records, which German tax and commercial law requires us to retain (§ 147 AO, § 257 HGB).
• Art. 6(1)(a) — consent. The optional usage analytics and crash reports — the two things the single switch in Settings governs — and nothing else. See Section 7d, which also explains how to withdraw it and what withdrawing deletes.

We do not rely on consent for dictation. The macOS microphone permission is a system permission granted to the app on your own Mac — it is not a GDPR consent, and withdrawing it stops the app from recording rather than changing our legal basis. Where we ever do ask for consent for something optional, you may withdraw it at any time with effect for the future (Art. 7(3) GDPR), without affecting the lawfulness of what happened before.

6c. Is providing data required?

Providing an email address is a contractual requirement for an account: without a confirmed email address we cannot create the account, let you use the managed Cloud plan or its free cloud words, bill you, or send you the statutory contract confirmation. You are under no obligation to provide it — the consequence of not doing so is that you can use Blurt on-device only. Dictation content stays on your Mac only when speech and clean-up both run locally. In Blurt 0.3.27 and later, selecting On-device prevents automatic cloud fallback. Earlier versions could use cloud clean-up when the local model was unavailable.

6d. No automated decision-making

We do not carry out automated decision-making, including profiling, that produces legal effects concerning you or similarly significantly affects you within the meaning of Art. 22 GDPR. The AI models Blurt uses transcribe and tidy your words; they do not evaluate, score or decide anything about you.

6e. Retention

• Account data (email, name, authentication, usage counters) is kept while your account is active, and is deleted when you delete your account (see your rights below).
• Refresh-token records are retained for the life of the session and removed on logout, rotation, or expiry.
• Email/security tokens are short-lived and expire automatically.
• Audio on the managed Cloud plan is relayed in-flight and is not stored by our backend after the request completes.
• Connection metadata (IP, User-Agent) in server logs is not archived. It exists as a rolling, size-bounded buffer used to diagnose faults and defend against abuse, and it is overwritten automatically as new requests arrive. It is never exported, never combined with dictation content, and never used to build a profile.
• Support tickets and the messages in them are kept while the request is open and afterwards as a record of what was asked and answered — at the latest until three years after the last message on the ticket, matching the regular limitation period (§ 195, § 199 BGB), then deleted. If you delete your account earlier, the ticket is depersonalised: the link to your account is removed and only the reply address on the request itself remains.
• Backups. Everything above lives in one database, and that database is copied off-site once a day. Deleting a row deletes it from the live database at once; the copies of it in the backups that were already taken disappear when those backups age out of the rolling window described on the security page. It is a short window, not an archive — but it is not instantaneous, and a policy that said "deleted" without this line would be reading better than it behaves.
• Support email in the mailbox. The retention above governs the ticket in our database. A copy of the same message also sits in the mailbox it was delivered to, as any email does with the person you sent it to, and is deleted there when it is deleted there.
• Billing and invoice records are kept for 10 years where German tax and commercial law requires it (§ 147 AO, § 257 HGB). This obligation survives account deletion — it is the one thing we cannot delete on request.
• The free-trial device marker (a salted hash, never the raw identifier) deliberately outlives account deletion, so that deleting an account and signing up again does not get the Blurt app a second free trial on the same Mac.
• Usage analytics, if you switched it on: 25 months, then deleted automatically; from Blurt 0.3.31 and earlier, individual events for 90 days from receipt, after which only an anonymous daily total remains, which contains no identifier. Switching analytics off, or deleting your account, deletes what was already sent — see Section 7e.
• Crash reports, if you switched them on: a report waits on your own Mac for at most 14 days and is deleted unsent if it is still there — and at most five are ever kept at once. Once sent it is an anonymous count in our own crash panel with no identifier attached to it. See Section 7f.
• On-device history is controlled entirely by you on your Mac, as described in Section 5.
• Website visit counts (Section 6f): 25 months, then deleted automatically. The daily key that groups a visit's pages is deleted after two days at most.
• Payment events (Section 6g): 25 months, then deleted automatically — or earlier, when you delete your account: they are erased with it.

6f. Counting visits to this website

We count how this website is used with OpenFrog, analytics software we run ourselves on our own server at Hetzner in Germany — the same machine that serves these pages. Your browser loads it from blurt.me and sends to blurt.me; no analytics company is involved, nothing is shared with anyone else, and nothing is used for advertising. No cookies, no local storage and no similar technology are stored on or read from your device, so there is nothing to accept.

What is recorded: the page visited (its address without anything after ? or #, except utm_* campaign tags, and its title), the referring site, browser and operating-system family, device type, and the country your connection comes from — plus these steps, each with nothing more than what is listed: a Download button pressed (which one), the Pro button on the pricing page pressed (monthly or yearly), and on checkout the payment form shown, submitted, completed or failed (the plan, whether it is the free trial or a paid start, and for a failure the kind of error Stripe or the network reported — never its message). Nothing you type into the payment form, no email address, no name and no account identifier is recorded, and the visits are not linked to your Blurt account.

Your IP address is not stored. While a visit is being counted our server uses it for two things and then drops it. It looks up the country the address belongs to in a database file kept on that same server (IP Geolocation by DB-IP, licensed CC BY 4.0) — no one is asked, your address goes nowhere else, and only the country is kept: no region, no city. And to group the pages of one visit, OpenFrog computes a hash of your IP address and browser identifier with a key that changes every day and is deleted after two days at most; after that a visit cannot be traced to you or linked to visits on other days. The counts are kept for 25 months; like the rest of our data, they are copied to our off-site backup (Cloudflare R2, see Section 3), where a copy lasts at most 14 days.

Lawful basis: our legitimate interest in knowing whether the site and checkout work (Art. 6(1)(f) GDPR). You may object at any time (Art. 21 GDPR) by writing to the address in Section 14; a content blocker that blocks /of/ on this site stops the counting in your browser altogether, and the site works the same without it.

6g. Payment events of a subscription

If you subscribe to Blurt Pro, our server records the payments of that subscription in the same analytics software, OpenFrog, on our own server at Hetzner in Germany. Nothing happens in your browser or in the app for this: Stripe tells our server about a payment, and our server writes it down. It goes from our server to OpenFrog through blurt.me, on the same machine, and through no other company; nothing is shared with anyone and nothing is used for advertising.

What is recorded, and nothing else: that a subscription started (after the free trial, or at once), renewed, ended, that a charge failed, or that money was refunded — each with the plan (monthly or yearly), the amount in euros, whether it began with the free trial, for a failed charge which attempt it was, and for an ended subscription the kind of reason Stripe reports (cancelled by you, payment failed, disputed, or another of Stripe's fixed categories). Each event is filed under your Blurt account identifier, a random code, so that the payments of one subscription can be told apart from another's. Your name, email address, card or billing address, Stripe's identifiers and anything you typed when you cancelled are never recorded. These events are not combined with your visits to this website, which are not linked to your account (6f). They are combined with the app's usage counts only if you said yes to those and are signed in (7c) — withdrawing that yes erases the usage counts, not these. No decision about you is taken on them.

Lawful basis: our legitimate interest in knowing what the service earns, how many subscriptions continue, and why they end (Art. 6(1)(f) GDPR). You may object at any time (Art. 21 GDPR) by writing to the address in Section 14. They are kept for 25 months and then deleted automatically. When you delete your account, they are erased with it: our server asks OpenFrog to delete everything filed under your account identifier, and payments Stripe reports after the deletion are no longer recorded. Copies in our off-site backup (Cloudflare R2, see Section 3) last at most 14 days. Your invoices and payment records themselves are a different matter: they stay with Stripe and in our billing records for as long as tax law requires (6e).

7. Usage analytics and crash reports — optional, and off unless you switch them on

Blurt can send us two kinds of diagnostics: counts of how the app is used, so that we can see which features earn their place, where dictation is failing people and what leads people to subscribe, and a report when Blurt itself crashes, so that a fault which hits people in Berlin is something we find out about rather than something we hear about when they leave. Both are off until you say yes. We ask once, in the app; if you say no, we do not ask again, and nothing about Blurt behaves differently either way.

One switch governs both. That is deliberate: two switches would mean two consents to keep in step, two paragraphs here, and eventually a difference between what one of them says and what the app does. The ask in the app names both, the row in Settings names both, and turning it off turns both off. Sections 7a and 7c–7e below are about the usage counts; Section 7f is about the crash reports and says everything that is true of them, including where they go. Section 7b — what is never sent — and Section 7d — the lawful basis and how to withdraw — apply to both.

What changed after Blurt 0.3.31. Up to version 0.3.31 the usage counts went to our own backend database, were never linked to your account and were deleted after 90 days. Later versions send them to OpenFrog, the analytics software we run ourselves on the same server (7e), and — while you are signed in — link them to your Blurt account (7c). Because that is not what anyone agreed to before, a later version asks again anyone who had said yes, and collects nothing from them until they answer. If you said no, you are not asked again. What 0.3.31 and earlier sent stays as it was described then: in our own database, not linked to your account, deleted 90 days after we received it, and erasable as 7d says.

7a. Exactly what is sent

Counters, drawn from a fixed list. Every event name, every property and every property value is a token from that list, built into the app — there is no field in the app's events in which a sentence could be carried even by mistake. The complete list is:

• that the app was opened, how (by hand or at login), and how old this install is as a band — "1–6 days", "7–29 days" and so on;
• which step of the first-run tutorial you reached, and whether you finished it or skipped out;
• that a dictation finished or failed, with: on-device or cloud, push-to-talk or Workspace, your clean-up level and tone, whether translation is on, the spoken language, and the length as a band ("10–24 words", "10–29 seconds") — never the exact figure;
• which screens you open, and which settings you change — the setting and the value it was set to, both as tokens;
• whether you met the subscription wall, where, and whether you went on to open checkout;
• whether an on-device model download started, finished, failed or was deleted;
• that one of six features was used at all: word rules, voice editing, hands-free, a Workspace document, the support form, or starting an update.

Each event also carries: the random identifier this install generated for itself (see 7c), the app's version and build number, macOS as major.minor only — never the patch level, your interface language, your plan tier (free / trial / Pro) and your Mac's processor architecture. Our server adds the country your connection comes from, looked up as it is for this website's visits (6f): in a database file on the same server, your IP address going nowhere and not kept. While you are signed in, one further event links the install identifier to your account identifier (7c).

7b. What is never sent — in either kind of report

Nothing you dictate. No audio, no transcript, no cleaned-up text; no personal word rules; no Workspace document titles or contents; no names of the apps or windows you dictate into; no file names; no microphone name; no clipboard contents; not even which keys you use for push-to-talk (only that you changed them).

This applies to a crash report exactly as it applies to a usage count, and it is worth saying how, because a crash report is the place where such things usually leak. Nothing in one is free text: every value is either a number or a name drawn from a fixed alphabet. The one line a crash report would most obviously want — the error message the system prints, which on macOS often quotes the object that went wrong — is deliberately dropped in full, because it is assembled from arbitrary values and one of those could be something you said. Stack frames name functions in Blurt's own code; frames from macOS or from any other application are discarded, and no file path from your Mac is ever included, so your home folder and your user name cannot appear.

No email address and no name, ever. Your account identifier — the random code of 6g, not your email — appears in the usage counts only as 7c describes: while you are signed in, and only because you said yes to exactly that. A crash report never carries it. Your IP address reaches our server because every internet connection does; it is used to look up the country (7a) and to rate-limit, and is never written down.

7c. The identifier, and the link to your account

A random UUID the app generates on your Mac at the moment you switch analytics on. It is not your account identifier, not the per-Mac identifier behind the free-trial device marker described in Section 6, and not derived from either. Switching analytics off destroys it; switching it back on later creates a brand-new one, so it cannot follow you across a change of mind.

While you are signed in, it is linked to your account. The app sends one event saying "this install identifier belongs to this account identifier", once per install and account. From then on everything that identifier sent — including counts from before you signed in — and the payment events of your subscription (6g) are one record in our analytics, which is what lets us see, for example, whether people whose first dictations failed went on to subscribe. Nobody's name or email is in that record, and no decision about you is taken on it. When you sign out, the app starts a new identifier, linked to nobody until someone signs in — so what happens on this Mac afterwards is not filed under your account. The identifiers used before a sign-out are remembered on your Mac for one purpose only: so that withdrawing (7d) erases what they sent too.

A crash report does not carry any of this, or any other identifier. Not the UUID above, not your account, not your device — nothing. Two crashes from the same Mac are not knowable as the same Mac. That is why 7f says a crash report cannot be looked up or erased individually: there is no identifier in it to look one up by.

7d. Lawful basis, and how to withdraw

Consent — Art. 6(1)(a) GDPR, together with § 25 Abs. 1 TDDDG for storing that identifier, and for writing a crash report, on your own device. Nothing is collected before you agree. You may withdraw at any time with effect for the future (Art. 7(3) GDPR) in Settings › Data & Privacy › Usage analytics and crash reports — the same one click it took to give, which is what the law asks of us and what we would want anyway.

Withdrawing also deletes what was already sent: the app asks our server to erase everything recorded under every identifier it used while you had said yes — including those from before a sign-out — and the link of each to your account, then destroys the identifiers. If our server cannot be reached at that moment, the app keeps asking, at every launch, until it can. The payment events of your subscription (6g) are not usage counts and are not erased by this; they go with your account. The same erasure is available on its own, as Erase sent data, if you want the record removed but would like to keep helping; you then continue under a new identifier.

For crash reports, withdrawing does two things at once. Blurt stops watching for crashes — the handlers come off, so nothing is written even to your own disk — and any report still waiting on your Mac is deleted, rather than merely left unsent against the day you might change your mind. What was already sent has no identifier attached to it (7c), so there is nothing to look up and nothing left that is about you.

7e. Where the usage counts go, and how long they are kept

To OpenFrog, analytics software we run ourselves on our own server at Hetzner in Germany — the same software and the same machine as this website's visit counts (6f) and the payment events (6g). The app sends to blurt.me, which hands the events to OpenFrog on that same machine. No analytics company is involved at any point: no Google Analytics, no Firebase, no Sentry, no Amplitude, no advertising or attribution SDK of any kind, and switching this feature on engages no new provider.

The events are kept for 25 months and then deleted automatically — or earlier, when you withdraw or press Erase sent data (7d), or delete your account, which erases them together with the payment events filed under it. Like every other part of our data they are copied to our off-site backup (Cloudflare R2, see Section 3), where a copy lasts at most 14 days. The request to erase them passes through Cloudflare's network on its way to OpenFrog on our server; it carries the install identifier and nothing else.

Blurt 0.3.31 and earlier sent the same counts to our own backend in Germany instead — the same server and PostgreSQL database as the rest of the service — not linked to any account. There, individual events are deleted automatically 90 days after we receive them; before they go, each day is folded into a plain daily total — how many times each event happened that day, and how many installs were seen — which carries no identifier of any kind and is kept as an anonymous statistic.

Correction, 1 September 2026 (about that database). Until this date the paragraph about it read "there is no third party in this at all", and said the feature adds nobody to our list of processors. The second half is right and stands. The first half went a step too far: these rows sit in the same database as everything else, and that database is copied to off-site backup storage at Cloudflare once a day, so a third party does hold a copy of them — for the ordinary reason every other row is copied, and on the terms now set out on the processor list. What the sentence was reaching for is true and is what it now says: nobody but us processes your usage counts as analytics.

7f. Crash reports

Nothing is sent at the moment of a crash. A program that has just failed is the last program that should be opening a network connection, so Blurt does not. It writes a few hundred bytes to a file on your own Mac and lets itself close. The next time you start Blurt, that file is sent and then deleted. If it cannot be sent — you are offline, or our server is down — it waits, for at most 14 days and never more than five reports at a time, and is then deleted unsent.

Here is the whole of what one contains. Not a summary of it — the whole of it:

• the crash class: the name of the fault (SIGSEGV, SIGABRT) or of the exception (NSRangeException), drawn from a fixed list of names;
• up to sixteen stack frames, each the name of a function in Blurt's own code. Frames belonging to macOS, to a system framework, or to any other application are discarded rather than sent, and no file path from your Mac is ever included — so your home folder and your user name cannot appear in one;
• Blurt's version and build number;
• macOS as major.minor only — never the patch level;
• whether your Mac is Apple Silicon or Intel.

There is no sixth item and there is no field for one. In particular there is no message and no reason: the human-readable line macOS prints when an app crashes is assembled from whatever objects were involved, and one of those could hold something you dictated, so it is dropped in full rather than filtered. It is the single most useful line in a crash report and we do not take it. There is also no identifier of any kind — not your account, not your device, not even the random analytics identifier from 7c — and no IP address is recorded with it.

Where it goes. The app sends it to our own backend in Germany, the same server everything else in this policy goes to. Our backend then forwards it to our own crash panel — the same place our server's own faults are recorded and counted, which is what lets us see "this broke forty times today" instead of guessing. That panel runs on Cloudflare's Workers platform, so we will say plainly what does and does not travel that last hop: what reaches the panel is the list above and nothing else, it arrives from our server rather than from your Mac — so the connection carries our server's address, never yours — and it carries no identifier, so nothing that arrives there can be connected to you, to your account or to your Mac, by us or by anybody. No personal data of yours travels that hop.

How long. In the panel, an individual crash event is deleted once it is 14 days old — the panel clears out what has aged past that each time a new report reaches it. What remains after that is the group it belonged to: a crash class, the place in our code, and how many times it has been seen — a running total with no identifier in it, kept as an anonymous statistic.

Withdrawing. See 7d. Turning the switch off stops Blurt watching for crashes at all, and deletes any report still waiting on your Mac. There is no way to erase an individual crash report after it has been sent, and no way for us to find yours among the others, for the reason given in 7c: it has no identifier to find it by.

8. Your rights

Subject to applicable law (including GDPR and CCPA), you have the right to access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), data portability (Art. 20) and to object to processing based on legitimate interests (Art. 21). For data held in your account, you can:

• Export your data — request a copy of your account data from within the app, or by emailing us. The payment events of Section 6g are not in the app's export; ask us and we send them.
• Delete your account — delete your account and its associated data from within the app, or by emailing us; this removes your account record and the data linked to it, including the payment events of Section 6g, and cancels related subscription entitlements. Records we must keep by law (see Retention) are retained and blocked from further use.
• Erase your usage analytics — Settings › Data & Privacy › Erase sent data, which removes everything recorded under this install's identifiers, and their link to your account (7d). It works whether or not you have an account; deleting your account does it too. Crash reports are not covered by this button and do not need to be: they carry no identifier at all, so there is nothing recorded under yours — see Section 7f.

Where GDPR applies you also have the right to lodge a complaint with a supervisory authority (Art. 77 GDPR). For us that is the Landesbeauftragte für den Datenschutz Sachsen-Anhalt, Otto-von-Guericke-Straße 34a, 39104 Magdeburg, Germany (datenschutz.sachsen-anhalt.de) — but you may complain to the authority in your own country of residence instead.

We do not sell or "share" personal information as those terms are defined under US state privacy laws. To exercise any right, use the in-app controls or email support-blurt@chbnk.one. We answer within one month (Art. 12(3) GDPR).

9. Permissions and why

• Microphone — to record your voice while you hold the key. There is no always-on listening and no wake word.
• Input Monitoring — to detect the push-to-talk key being held. Blurt uses a listen-only tap and does not capture or log your other keystrokes.
• Accessibility — to insert the transcribed text into other apps.

Blurt does not read your screen contents, does not log keystrokes, and does not monitor your typing.

10. A note on sensitive content

Because Blurt inserts whatever you dictate, transcribed text may briefly pass through the macOS clipboard during insertion, is saved to your on-device history unless you turn that off, and — when a cloud processing stage is used — may be sent to a third-party API for processing. If you are using the managed Cloud plan, avoid dictating passwords or other secrets you do not want transmitted to a third party. To keep dictation content local, install and select both local speech and clean-up models and verify the effective route in Blurt. Privacy Mode separately skips history; it does not select a processing route.

11. Children

Blurt is not directed to children. You must be at least 16 years old to create a Blurt account or to use the managed Cloud plan (Art. 8 GDPR; Germany has not lowered that age). Separately, under §§ 106 ff. BGB a person under 18 needs their parent's or guardian's agreement to enter into a paid subscription. If we learn that we hold data of a child under 16 without the required authorisation, we delete it.

12. Security

All transmission to our backend and its processors uses TLS. Passwords are stored only as scrypt hashes; refresh tokens are stored only as hashes; the backend and database run in Germany. The full description of our technical and organisational measures is on our security page, and it is also the annex to our data processing agreement for business customers.

13. Changes

The current version of this policy is always available at blurt.me/privacy.html. If we make material changes, we will update the date above. New processors are announced on the processor list normally 30 days before they start receiving data; where an outage or a security problem forces a faster change, the list is updated without delay, with the reason.

14. Contact

Questions about privacy? Email support-blurt@chbnk.one.