mmumble is a voice keyboard. You talk, we transcribe and clean the text, it shows up at the cursor. This page explains what we collect, where it goes, and how to make it stop.
The short version: we do not store your audio, your transcripts, or your cleaned text. We don't log keystrokes. Accounts are optional and only exist to sync your personal vocabulary, dictation stats, and subscription tier across your iOS devices. If you don't sign in, mmumble works anonymously against a per-device identifier and nothing syncs anywhere. The personally identifying things we may hold — depending on what you do — are an email address (if you put it in our waitlist form, or if you sign in by email or OAuth), your first and last name (only if Apple's "Sign in with Apple" relays them on your very first sign-in), your subscription state, and the small synced datasets listed below.
mmumble is provided by Covalet LTD (“Covalet”, “we”, “us”), a company registered in England and Wales under company number 15869880. Covalet is the data controller for the personal data described on this page. Our registered office is on file with Companies House and can be looked up at find-and-update.company-information.service.gov.uk/company/15869880. For any privacy question, write to support@mmumble.com.
When you tap the mic, your device uploads to our backend a short audio recording together with a small set of request metadata needed to produce a useful cleaned result:
The backend hands the audio to one of several speech-to-text providers, sends the resulting transcript along with the metadata above to one of several language-model providers for cleanup, and returns the cleaned text to your device. The audio, the transcript, the metadata, and the cleaned text exist in transit only — none of them is written to disk, a database, or a log on our side. Which speech-to-text or cleanup provider handles a given request can vary by audio length, language, region, capacity, or A/B test; the full set is listed under “Third parties that touch your data” below. Every provider we use is contractually limited to fulfilling the request and is prohibited from training models on your data.
Each request is signed by a per-device key generated through Apple's App Attest. We see a device-level identifier we issue at first launch — no Apple ID, email, name, or device serial. The identifier is used to apply rate-limits, remember your subscription, and attribute installs to ad campaigns. It is not linked to any other profile.
The words you teach mmumble to spell correctly are stored on your device. They are sent with each dictation request to bias the model toward your spellings, then discarded by our backend along with the rest of the request. If you are not signed in, your vocabulary stays on your device between dictations — there is no mmumble account to sync it to — but it is still sent transiently with each dictation request and discarded immediately after the request completes. If you are signed in, your vocabulary is additionally stored in your mmumble account so it can sync across your devices, as described in the next paragraph.
If you are signed in, your vocabulary is also synced to your mmumble account so that the same word list is available on any other iOS device where you sign in. Sign-out clears the vocabulary from that device; the cloud copy stays with the account until you delete the account or remove the word.
The keyboard extension does not read what you type with the system keyboard, what app you're in, what's on your screen, or any text beyond the small snippet immediately adjacent to the cursor that iOS hands keyboard extensions for context. When you dictate, that snippet itself may be sent with the request so the cleanup model can resolve pronouns and continue your sentence in the right tense. Like the audio and the transcript, the snippet exists in transit only and is discarded as soon as the request completes — we do not store it, log it, or use it for any other purpose.
mmumble works fully anonymously. If you want your vocabulary, dictation stats, and paid subscription tier to follow you to a second iOS device, you can create an mmumble account by signing in with Apple, Google, or a one-time code sent to your email address. Sign-in is handled by Supabase. We don't see your password, ever.
When you create or use an account we receive and store:
What we don't store at the account level: your audio, your transcripts, your cleaned text, or what you typed with the keyboard. The sync layer only carries the small datasets listed above.
You can sign out at any time. Signing out keeps your data in your account in the cloud (so you can sign back in on another device) but clears the local vocabulary and stats cache from that device. You can delete your account from inside the app — see the “Your rights” section below for what that does.
If you subscribe, Apple handles all billing. We never see your card details. Apple notifies us of subscription events (purchase, renewal, cancellation, refund) so we know whether you're on the free or paid tier. We store your subscription tier and expiry date against the device-level identifier described above.
If you're signed in to an mmumble account when you purchase or first surface a subscription, the subscription is linked to that account so the paid tier follows you to other devices you sign in on. The link is permanent and there is no in-app flow to move a subscription to a different mmumble account afterward.
To measure whether our ad campaigns work, the app sends a small set of events to advertising partners:
These events include the device-level identifier we issued, the event name, and for purchases the price and currency. They never include audio, transcripts, cleaned text, vocabulary, contacts, or your email.
We do not display ads inside the app. We do not sell your data. We do not combine your in-app activity with your browsing history on other sites or apps. We can switch off any of these advertising integrations remotely; if a privacy concern arises we don't need to ship an app update.
During onboarding, mmumble asks for the iOS App Tracking Transparency permission with the prompt: “mmumble shares some app activity with advertising partners so they can measure ad campaign performance.” You can decline in the iOS prompt or change your answer later in iOS Settings → Privacy & Security → Tracking.
If you allow tracking, the advertising SDKs bundled in the app — currently Meta and Google (Firebase Analytics) — may include your Apple advertising identifier (IDFA) in the attribution events they send to their servers, so they can match an install or purchase to an ad campaign. If you decline the prompt or have tracking turned off in iOS Settings, the IDFA is not read and is not sent.
Our own backend never reads or stores the IDFA, regardless of your ATT choice. The only device identifier we issue and hold is the per-device key generated through Apple's App Attest at first launch, described above. Apple Search Ads attribution is IDFA-free by design — it uses Apple's AdServices framework, which returns an install-attribution token without identifying you across apps.
If you arrive via a referral link (e.g. a podcast or influencer campaign), we record the short campaign code so we can attribute the install. The code is a marketing slug, not a personal identifier.
To enforce the free-tier weekly word allowance, we record how many words mmumble has cleaned for your device this week. The record is keyed by the same device-level identifier — no Apple ID, name, email, or serial — and contains only the identifier, the week-start date, the running word count, and a last-updated timestamp. It does not contain your audio, your transcripts, your cleaned text, or which apps you used mmumble in. Records roll over weekly and are deleted after a short retention window.
The companion app and this website send anonymous product-usage events to our analytics provider (e.g. "user opened settings", "transcription succeeded", "visited privacy page"). These events do not include audio, transcripts, vocabulary, contacts, or email. App events are tied to the same device-level identifier; website events are tied to an in-memory session that does not persist across visits.
If you submit your email on the waitlist form, we keep it until we email you when the cohort opens, or until you ask us to delete it — whichever comes first. We do not sell it, share it, or add it to a marketing list.
Each provider below is contractually bound to use the data only to deliver the service we contract them for. We require every provider that receives personal data through mmumble to protect it with privacy and security protections at least equivalent to those described in this policy, including the prohibition on training models on your data.
Cross-border note for users in the EU and UK: several of these providers store or process data in the United States, and Alibaba Cloud processes cleanup requests in Singapore. Standard contractual clauses or equivalent transfer mechanisms apply.
mmumble is not directed at children under 13. We do not knowingly collect data from anyone under 13. If you believe a child has used the waitlist form, email us and we'll delete the record.
Because we don't keep transcripts or audio, there is nothing of that kind to export or delete. For the limited data we do hold — waitlist email, subscription state, usage counter, referral code, analytics, and (if you signed in) your account profile + synced vocabulary, stats, and style — you can:
Email support@mmumble.com and we'll handle the request within 30 days.
If you're in the EU, UK, or California, you have additional rights under GDPR, UK GDPR, or CCPA respectively — including the right to opt out of sharing with advertising partners. The same email address handles those requests.
Under the GDPR and UK GDPR we rely on the following bases to process the limited personal data described above:
If you believe we have handled your data improperly, please tell us first and we will try to put it right. You also have the right to lodge a complaint with a data-protection supervisory authority. In the United Kingdom this is the Information Commissioner's Office (ico.org.uk/make-a-complaint). In the European Economic Area, complaints go to the supervisory authority in the country where you live, where you work, or where the issue occurred.
If we change this policy, we'll update the effective date at the top. For material changes — anything that broadens what we collect or who we share with — we'll surface a notice in the app the next time you open it.
Questions, deletion requests, opt-outs, or anything else: support@mmumble.com.
Updated the list of speech-to-text providers mmumble may route a dictation request to. The full set is now Groq, OpenRouter, Cloudflare (via Workers AI), and DeepInfra. Audio is still handled in memory only and discarded as soon as a request completes; none of these providers retain it for model training. No change to what's collected, what's stored (still nothing — audio, transcripts, and cleaned text remain in transit only), or your account data.
Disclosure and clarity improvements. No new collection, no new sharing, no new providers — this revision just makes the existing data flow easier to verify against what the app actually does:
Added DeepInfra as the primary speech-to-text provider. Audio is processed in memory only and discarded as soon as the request completes; DeepInfra does not retain it for training. Groq stays in the system as a fallback when DeepInfra is unavailable. No change to what's collected, what's stored (still nothing — audio and cleaned text remain in transit only), or your account data.
Added Microsoft Azure (Azure OpenAI Service) and Alibaba Cloud (Model Studio / DashScope, Singapore region) as language-model cleanup providers alongside Anthropic. Cleanup may be routed to any of these providers based on language, region, capacity, or A/B test. Updated the cross-border note to mention Singapore. No change to what's collected, what's stored (still nothing — audio and cleaned text remain in transit only), or your account data.
Corrected the App Tracking Transparency description: the previous version said we don't ask for tracking permission and don't read the IDFA. In reality, we show an ATT prompt during onboarding, and if you allow tracking, the bundled advertising SDKs (Meta and Firebase Analytics) may include the IDFA in the attribution events they send to their servers. Our own backend still does not read or store the IDFA. Added a new “App tracking permission (ATT)” section that lays this out in full.
First publication under the in-app legal versioning system. Codifies what mmumble collects, shares, and stores at launch: a device-level identifier issued via Apple's App Attest, optional accounts with synced personal vocabulary and dictation stats, the weekly free-tier usage counter, subscription state, anonymous product analytics, advertising-attribution events to Meta and Google and Apple Search Ads, and the third-party processors that touch each. Future changes to this policy will be tracked under this same versioning scheme and surfaced in-app on next open.
Notable revisions to this policy during development, before formal version tracking went live: