Privacy

What Voice Taker knows about you

Voice Taker writes up a record on the device in front of you. It needs no account to do it, and no record leaves that device until you sign in — after that the records on that device sync to your account, until you switch that off. This is what is stored when they do, who holds it, and how to get rid of all of it.

Last updated: 1 August 2026

In short

Recording, transcription, speaker separation, translation, bookmarks, export and reading a record back to you all run on your own device. They need no account and no connection.
Nothing about a record is uploaded unless you sign in. Once you do, the records on that device are sent to Voice Taker on their own, and one switch in the app’s settings turns that off.
What is sent is the record: its title, its sentences, your bookmarks and the names you gave the speakers. On a paid plan the recording follows.
Voice Taker is not always the last stop: making a summary of a synced record sends its words to the company whose model writes it. Asking the assistant about your records sends the sentences it finds to the same company. Those two are separate acts you take one at a time, and they are the whole of what sends a record further.
A record has other people in it, and Voice Taker keeps a voiceprint of each speaker so it can tell the same people apart from one record to the next. Those stay on your device and reach Voice Taker in no form at all.
There is no analytics, no advertising and no tracking in the app or on this site.
You can delete your account from inside the app or from this website. One record survives it, and it is named below.

Using Voice Taker without an account

The app is usable in full with no account at all. It listens, writes the record down, tells the speakers apart, translates, keeps the moments you mark, exports to five formats and reads a record back to you — all of it on the machine in front of you, with the radio off.

The one request the app makes on its own is to fetch the speech models it needs, the first time it runs. That request carries nothing about you and nothing about any record: it downloads files named in a manifest inside the app.

This is enforced rather than promised. A build gate names the four files in the app that are allowed to open a network connection, and the files allowed to reach each of them; any other file that imports an HTTP client fails the build. Three further tests record real records, drive a real network socket, and check that the words of a record made on a device nobody signed in on appear in no byte that was sent.

There is no analytics package, no crash reporter and no advertising code in the app. The same gate refuses those packages by name, so adding one is a failed build rather than a quiet commit.

One diagnostic exists and it is not in the app you would install. A build made with a special flag writes a file in its own folder recording memory use and temperature every thirty seconds, so that battery and heat can be measured over a real lecture. Ordinary builds do not contain that code, and a gate rule fences which files may read that file, so it cannot quietly grow into something that is sent.

When a record leaves your device

Sync is what a device does once somebody signs in on it. A device nobody has signed in on uploads nothing at all; once you sign in, the records on that device are copied to your account, and one switch in the app’s settings turns that off again.

What is sent when a record syncs

The record’s title, and when it started and ended.
Every sentence, with the moment it began and ended, the language it was recognised in, and whether you edited it.
Every moment you bookmarked, with any label you typed on it.
The names you gave the speakers. A speaker you never named travels as an unnamed one.
Whether the record was transcribed or machine-translated.
For each of those fields, which of your devices last changed it — so that two devices editing the same record can be reconciled.
On a paid plan, the recording itself.

Turning that switch off, or signing the device out, stops anything further being sent. Neither removes what has already arrived, and the app says so rather than implying it does: a record that has been synced and then stopped is labelled as having a copy on the server. Deleting the record is what removes it.

The other people in the record

Voice Taker records everyone in the room, not only the lecturer, and it does one more thing that is worth spelling out: to tell two speakers apart it keeps a voiceprint of each of them — a short list of numbers describing how a voice sounds, 192 of them with the model in use today, taken from each utterance as the recording runs.

That is what lets the app recognise the same lecturer in a record you make next week, so a name you typed once keeps working across a whole term. It is also the reason the app cannot do it from a saved recording afterwards: the voiceprint is taken while the record is being recorded, and never again.

Where those stay

On your device, and nowhere else. There is no column for a voiceprint anywhere in this server’s database, so unlike everything else in this section they do not leave even when you sign in. They are removed with the record they were taken from, and a speaker nobody named who no longer has a sentence to their name is removed with them.

What does travel, for a record that syncs to your account, is the names you typed. A speaker you never named travels as an unnamed one. And if you ask a hosted model to summarise that record, those names go with its words — the summaries section below says exactly what is sent.

Those people are not Voice Taker’s users and have no account here, so there is nothing they can ask this product for directly. What exists instead is on your side: deleting the recording, or deleting the record, takes their words, their voiceprints and any name you gave them with it, on the device and on the account. The terms of use set out whose responsibility the recording is.

What an account holds

Nineteen tables make up this server’s database. Every one of them is answered below — including the ones that hold nothing about you — because a list that stops early reads as a complete list.

Your name and email addressWhat you typed when you signed up, whether the address has been confirmed, and when the account was made.

Your passwordStored as a hash by the authentication library, never as text. If you ever sign in through another provider, that provider’s tokens would sit in the same row; today no such provider is configured, so the column is empty.

Your sign-insOne row per signed-in session: a token, when it expires, and the network address and browser or app the sign-in came from. Sessions last seven days.

Your devicesFor each device or browser you sign in on: an identifier that device made up, the name the device reports for itself — which is often a name you chose, such as “Ahmed’s MacBook Pro” — its platform, the app version, the operating system version, when it was last seen, and whether it has been signed out.

Records that have synced to your accountThe record, its sentences, its bookmarks, the speaker names, a log of which rows changed and when, and — on a paid plan — a row describing the recording. A record made on a device nobody signed in on is in none of these.

Summaries made of a synced recordThe summary’s text, which company and which model produced it, and how many tokens it cost. A record that has never synced has no summary here, because there is nothing on the account for one to be made from.

Your plan and the record of what you paidIf you pay: which plan, whether it is active, past due or ended, when the period ends, and the payment company’s own identifiers for you as a customer and for the subscription. Beside it, each payment event exactly as that company sent it. An account that has never paid has no row here at all.

Two short-lived working tablesA stored copy of the reply to a request your own device made, so a retry cannot register the same device twice — kept 24 hours. And a pending password-reset token, which exists only between asking for a reset and using it, and stops working an hour after it is sent.

Administrator activityOne row every time somebody with the administrator role opens a console screen. It records the administrator rather than you — see below for what an administrator can and cannot see.

Three tables with no path to any accountThe list of plans this deployment sells; this deployment’s own configuration, including the summariser’s key; and the receipt a deletion leaves, which carries no account identifier, no name and no address. That is nineteen tables in all, and no twentieth.

What is deliberately not sent

Where the recording sits on your deviceThe file path is meaningless anywhere else and is a fact about your machine. There is no column for it on the server and a test asserts that none appears in what is pushed.

The voiceprints that tell speakers apartThe section above says what these are and why they exist. No table on this server has a column for one, so there is nothing for a push to put in it.

Anything from a device nobody has signed in onThis is the assertion the runtime gates exist for, and it is checked by searching the actual bytes a real server received rather than by trusting the code that built them.

Recordings

Keeping the sound of a record is a choice you make in the app, and it is kept on your device by default. Sending it to your account is what a paid plan adds: the free plan’s recording allowance is zero, and an upload on a free account is refused with a message saying so rather than with a full-disk error.

A recording that does reach the account is stored as a file named after a random identifier this server generated. Your account id, the record’s id and the name you gave the record are all absent from the path.

You cannot download it back, and that is worth being blunt about

The server has three routes for recordings: begin or resume an upload, append a range of bytes, and ask how far it got. None of them returns audio, and no part of the app or this website asks for any. So a recording on your account is a copy you cannot presently retrieve — it protects you against losing the device, and nothing else. The pricing copy on this site says the same thing and does not claim otherwise.

A recording is deleted when you delete it in the app, when the record is deleted, or when the app’s own trash takes it — a record you delete loses its recording after 13 days and disappears entirely after 30. Each of those travels to the server as its own instruction, and the server removes the row and then unlinks the bytes.

The hosted model, and the company that is not Voice Taker

Two things Voice Taker does hand a record to somebody else, and both of them reach the same company: summarising a record, and asking the assistant about your records. Nothing else in this product does.

A summaryOnly offered for a record that has already synced to your account, and part of a paid plan. Making a summary of a synced record sends its words to the company whose model writes it.

A question you ask the assistantAsking the assistant about your records sends the sentences it finds to the same company. It can only see records that have synced to your account, because it reads the copy there and there is nothing else for it to read. What goes is what its search matched rather than a whole record, and one exchange is capped at sixty thousand characters — under half of a ninety-minute lecture.

Exactly what is sent to that company

For a summary: the sentences of that one record, as text.
For a question: the sentences the assistant’s search matched, and the titles of the records they came from. Never a record that has not synced to your account.
The names of the speakers you named, printed once above each run of their sentences. A speaker you never named is not mentioned at all.
The instruction asking for a summary or the question you typed, and a fresh random identifier for that one request.

Not sent: the record’s title, the timings of the sentences, the recording, your name, your email address, your account identifier, or any identifier that would let that company join two of your requests together. The chat API this server speaks has a field for an end-user identifier and this server deliberately leaves it empty.

Which company

That depends on what whoever runs this deployment has configured. The server will only speak to one of four addresses, fixed in its own source: Z.AI, DeepSeek, OpenRouter, or an Ollama server running on the same machine — in which case nothing leaves that machine at all. Free text is refused when the server starts, because an address an administrator could type is an address that could be made to point anywhere.

A summary is never automatic. Nothing summarises in the background, nothing does it at sync time, and there is no setting that makes it happen — it is one record and one deliberate ask, every time. The app puts a note in front of that ask. Today it cannot name the company in advance, because the server does not publish that until a summary exists, and the app says it was not told rather than guessing. The stored summary records which company answered, so “who read this record” can be answered afterwards.

When OpenRouter is the one configured, it is a gateway rather than a company: it forwards the record to a provider chosen at request time. Four of its own defaults are overridden on every request — providers that may keep the prompt are refused, falling back to a different provider is refused, zero retention is asked for explicitly, and a provider that would silently drop those settings is refused. A test reads all four out of the bytes actually sent. Endpoints that may publish prompts are refused outright and no screen offers to switch them on.

What this document cannot promise is what that company then does. Their terms apply to their copy, not this one. That is the cost of the feature, and it is why it is a separate act on a separate screen rather than something sync does for you.

Paying for Voice Taker

Payments are taken by Stripe. Card details are entered on Stripe’s own page and this server never receives them: the only two calls it makes to Stripe create a checkout page and a link to Stripe’s customer portal, and both return a web address and nothing else. There is no card number, expiry or security code anywhere in this server’s code or database.

What this server keeps is which plan you are on, whether it is active, past due or ended, when the period ends, Stripe’s identifiers for you as a customer and for your subscription, and each payment event exactly as Stripe sent it. Stripe holds the rest, under Stripe’s own terms.

Your plan can only be changed by a signed message from Stripe. No request a browser or an app can make grants an account anything.

Email

This server sends two messages and no others: “reset your password”, and “confirm your email address”. Both are sent only because you asked for them, both carry your address and the name you signed up with, and the reset link works once and stops working an hour after it is sent.

There is no marketing email, no newsletter and no announcement list. Nothing in this product’s code composes one.

Mail goes through a relay that whoever runs the deployment configures. The server refuses to start if that relay is unencrypted and is not on the same machine, because a password reset link is a credential.

Confirming your address is optional. Nothing in the product is withheld until you do.

What somebody running Voice Taker can see

There is an administrator console. It has six screens and it can read four things: the list of accounts — name, address, whether the address is confirmed, the role, whether the account can sign in, and when it was made — the subscriptions, the payment events that did not match an account, and the audit log itself.

An administrator cannot read a record. No console route touches the tables that hold records, sentences, speakers, summaries or recordings — the code behind those screens imports two parts of the schema and neither contains a transcript.

Every one of those reads writes a row before it answers, in the same database transaction, recording who looked, what at, when, from which network address and with which browser. Opening the audit screen puts the person opening it into the page they are shown.

The role cannot be granted through any request. It is set by hand in the database. And nobody can sign in as you: the authentication library’s impersonation feature is not mounted, and that endpoint answers “not found”.

What no software can remove: whoever operates the server can reach its database and its disk directly. Nothing you sync is encrypted in a way that would stop them — see the last paragraph of the security section.

Analytics, tracking and advertising

There are none. No analytics, no advertising, no fingerprinting, no session recording, and no third-party script on this website — the site’s only runtime dependencies are its own framework, and every stylesheet, font and image is served from this site.

One honest caveat, because it was measured rather than assumed. The authentication library this server uses ships a telemetry feature of its own. It is switched off in this server’s configuration — and that switch does not, on its own, defend against an environment variable that would turn it back on, because the library treats the two as alternatives rather than requiring both. Whoever runs a deployment has to leave that variable unset. This document cannot promise the feature is impossible; it can say it is off, why, and what the one way round it is.

Cookies and browser storage on this website

A session cookieSet when you sign in, and only then. It is the credential that keeps you signed in, it lasts seven days, and it is marked so that scripts on the page cannot read it. Signing out removes it.

vt-device-idA random identifier for this browser, kept in the browser’s own storage, so that the browser can appear as a row in your own list of devices and you can sign it out from elsewhere. It is made up locally and is not derived from anything about you or your machine.

vt-themeWhether you chose the light or the dark appearance. Set as soon as you use the theme control, including on these public pages.

That is the complete list. There is no third-party cookie, no advertising identifier, and no cookie set before you interact with the site.

How long things are kept

A record you syncedUntil you delete it, or until you delete your account.

A record on your own deviceUntil you delete it. A deleted record sits in the app’s trash: it loses its recording after 13 days and disappears entirely after 30. Those two windows differ on purpose — a ninety-minute recording is around 173 MB and its transcript is kilobytes, so holding both for thirty days would mean holding gigabytes to protect a few kilobytes.

SessionsSeven days, or until you sign that device out.

A password-reset tokenOne hour, and it stops working the first time it is used.

Stored replies to a repeated request24 hours, then swept by the next request that writes one.

The record of which rows changedA log of what changed and when — not the content — so that a second device can catch up. Twelve months, then removed. It goes with the account whenever that happens first.

SummariesKept with the record they are of, and removed with it.

Payment eventsTen years from the event. It is an accounting record, and the period is the one the law where Voice Taker is established sets for those — which is not yet named here, so this document states the longest of the ordinary figures rather than the shortest.

The administrator audit logTwenty-four months. It exists to answer “who looked at what” after something has gone wrong, and that question is asked in months rather than years.

Both of the last two are ledgers, which is why they are kept far longer than anything else here: this server treats an edit or a delete against either as a defect, because a record that can be rewritten afterwards is one nobody can audit. A retention period is the one deletion a ledger may have, and it applies to a whole row by age rather than to a row somebody wants gone.

Voice Taker’s choice — how long the three long-lived tables are keptHow long a change feed, a payment ledger and an audit log are kept is not something the code can decide, and until now this document said “indefinitely” for two of them. Twelve months, ten years and twenty-four months are the answers above, each chosen against what the table is for rather than by picking one number for all three.

One thing has to be said plainly about those three periods: nothing deletes those rows automatically today. There is no scheduled job anywhere in this server — the two sweeps it does have are run by the requests that write the rows they clean up — so the three periods above describe what Voice Taker holds itself to and what it has to build to keep. Until it is built, those tables grow.

Backups

The database is dumped nightly at 03:20 UTC and the dumps are kept for up to 14 days or about 4 GB, whichever runs out first. A dump contains everything the database holds: every synced record and every sentence in it, speaker names, bookmarks, accounts, devices, the billing ledger and the audit log.

The recordings are not backed up, and that is arithmetic rather than a preference. A second copy of the space set aside for recordings is 128 GB, and the room left over on this machine after the operating system, the database and the recordings themselves is about 6 GB — twenty-one times too small. If a recording held on your account is lost, it is lost, and the copy on your device is the only one.

A dump taken before you delete your account still contains that account until that dump rotates out, which takes up to 14 days.

Deleting your account

You can delete your account from inside the app and from this website. It asks for your password, because the password proves it is you, and then it is immediate and permanent. There is nothing to write to anybody about and no waiting period.

One database transaction removes your account and everything reachable from it — sessions, the password, devices, every synced record and every sentence, bookmark, speaker name and summary in it, the change log, your plan, and the stored replies to your own device’s requests. Any pending password-reset token is deleted with them, by hand, because nothing links it to the account automatically. Once that transaction has committed, the recording files are removed from the disk.

One thing survives, and it is named rather than hidden

The payment events Stripe sent are kept. The column linking them to you is set to empty, so nothing joins them to an account any more — but the event itself is kept exactly as it arrived, and for an account that paid, one of those events carries the account’s identifier inside it. That is deliberate: a payment ledger that is edited after the fact is one nobody can audit. It has been measured, and a test names that table so that it stays a decision somebody took rather than something somebody finds.

One case is refused. An account that has used the administrator console has written rows in the audit log, and those rows must not lose the name of who acted. Deleting such an account is refused with a message saying so, and what happens to that trail has to be settled first.

A deletion leaves one row behind that names nobody: when it happened, how many records and recordings went and how many bytes, and the network address and browser the request came from. It holds no account identifier, no name and no email address — a receipt that identified the person would be the account surviving its own deletion in miniature.

Security

Passwords are stored as hashes by the authentication library and never as text.
Signing in to the app through a browser never hands the app a session cookie: the server strips every header carrying one and hands over a single-use token that expires in three minutes and is stored hashed. Each attempt also carries 256 bits of randomness that the reply must carry back, so another app on the same phone cannot answer a sign-in it did not start.
Every route on this server has a rate limit, and a route with no limit written down stops the server starting — so an unthrottled route is a decision rather than an oversight.
Credentials travel in web addresses during a password reset, so this server does not write the query part of a request into its log.
Whoever runs a deployment must name the addresses it trusts to report a visitor’s real network address, so that a header cannot be used to claim somebody else’s.

What is not claimed

Nothing here is end-to-end encrypted. A record that has synced is stored so that this server can read it — that is what makes the web viewer and the hosted summariser possible — and whoever operates the server can read it too. If that matters, there are two remedies and both are in the app: turn sync off in its settings, or sign that device out. Neither removes what has already arrived — deleting the record is what does that.

This document also makes no claim about how any breach would be handled, because no procedure for one exists in writing yet.

Age

The app on your own device has no minimum age, because it collects nothing and sends nothing: making a record, writing it down, translating it, marking a moment and exporting it all happen with no account and no connection, and nothing about any of it reaches Voice Taker.

An account is the part that needs an age, and the minimum is sixteen. An account is what puts a name, an address and — once you sign in on a device — the words of a lecture onto somebody else’s computer, and that is the thing an age rule is about.

Voice Taker’s choice — a minimum age of sixteen, for an account onlyNothing in the law fixes one number for a product like this, and nothing in the code decides it either. Sixteen is the age at which European rules stop treating a service like this as needing a parent’s agreement, and it is one rule rather than one per country — which is what a lower age would mean, along with asking everybody for a date of birth and where they live. Voice Taker would rather not ask for either, so the on-device app has no minimum at all.

Signing up asks for a name, an email address and a password. It does not ask for a date of birth, so nothing in the product checks the age above — it is a rule about who may make an account rather than a gate that stops one being made.

Who is responsible, and how to reach them

Still to be filled in — the name and address of whoever is responsibleNo file in this product records a company name, a legal form, a trading name or a postal address. Until one is supplied this document cannot say who holds your data, and an invented address would read exactly like a real one.

Still to be filled in — an address to write to about privacyThere is no support address, contact form or privacy mailbox anywhere in this product. One has to exist and be named here, because a policy that describes rights and gives nowhere to exercise them is worse than one that describes none.

Still to be filled in — the governing law, and where the data physically isVoice Taker runs on one server with one database and one directory of recordings. Which country that machine is in, and whose law governs this document, are not recorded anywhere in this product and cannot be worked out from it.

Deliberately absent until those are answered: any claim to comply with a named data-protection regime, any statement of a lawful basis, and any list of rights and how to exercise them. What a person may ask for is a matter of law; only what they can do inside the product is a matter of code, and that is what the sections above describe.

Changes to this document

This document is written from the product’s own source and is meant to change when the product does. The date at the top is the last time it was checked against the code, not the last time a word was edited.

Two things in it are already known to be in motion and are described as they stand today: which company a hosted summary is sent to, which is chosen by whoever runs the deployment; and whether a recording can ever be downloaded back, which no part of this product can do at the moment.