What we hold, and what we refuse to

A product that supervises a child accumulates the most sensitive data a family has. The design position is to collect the least that makes it work, and to make the boundary something you can check rather than something we assert.

This is the privacy policy for ParentProof Secure — the parent dashboard at platform.parentproof.com, ParentProof Play profile preparation, the setup app for Windows and macOS, the protection it installs on those computers, and the app installed on a supervised Android device. In effect from 6 September 2026. It replaces the version dated before that.

What changed, and why we are saying so

The current release does not make screenshots or remote taps available. This page previously described dormant implementation details as though families could use them; that was wrong, and the correction matters for a monitoring product.

This release also removes detailed app-open/app-close history and allowed-site visit history. New Android apps discard old queued copies before upload; both ingest services refuse or drop those fields; and parent reads suppress legacy rows. Deleting historical production rows is a separate, authorized operator action that is still outstanding, so we do not claim that old copies have already been purged.

This release adds preparation for ParentProof Play. If you choose to create or link a Play profile for a child, we keep a game display name and the broad age band you selected. Game sign-in, connected-game data and points exchange are not in effect yet; no game receives this information in the current release.

A correction, stated plainly because the previous wording was the opposite of the truth. An earlier version of this page listed “camera or microphone” among what is not collected, and invited you to check the app’s manifest to confirm it. The camera half was right; the microphone half was wrong. The child app does hold the microphone permission, and ParentTap’s microphone button records your child’s voice and uploads it to us so you can hear it. That feature was in the product before this page said it was not. Nothing about the recording changed — what changed is that this page now describes it, above, along with the 7-day limit that has always applied to it. A recording of a child speaking is the most sensitive thing this product touches, and a policy that denies holding it is worse than no policy at all.

The waiting list is closed, and we would rather say why than quietly drop it. Its form invited an address in exchange for one message when ParentProof was ready for everyone. Two things then became true at once: you can create an account and download the setup app today, so there was no such message left to send — and nothing in ParentProof could show anyone the list, because no screen, tool or report was ever built to read it. Collecting addresses we could not read, for a message we would not send, is not something a page like this can defend, so we stopped: the form is gone and the endpoint it posted to refuses every request. If you left an address while it was open, it has not been deleted — clearing them out is a decision with a record and we will not pretend it has been made. It is attached to no account, nothing reads it, and ask and we will remove it.

So the rule for everything below: it describes what the code does today, not what we intend to build. Where a protection is real, it is stated plainly. Where something is planned but not running, it is marked Not in effect yet. Where a gap exists, it is named rather than left out.

What is collected

Your account

Your email address, a hashed password, which devices and child profiles belong to your household, who else you invited into it, your settings, and — only if you choose to set one — a display name for yourself, so a household with two parents can tell who did what. Leaving it unset is a supported state, not a nag: accounts without one simply read as “Owner” or “Co-parent”. No phone number and no postal address — there is nowhere to put those.

We do not store IP addresses. Your address is used in memory to rate-limit abusive requests and is not written to the database.

Activity from the child's device

Security, enforcement and request events: unlock attempts and PIN failures, leaving or re-entering kid mode, a child's request, an alert, a blocked-site denial, a boot, a crash, and per-app daily usage totals.

Ordinary app opens and closes, the app in the foreground right now, and allowed website visits are not uploaded or kept as detailed history. Screen-time numbers are aggregate usage totals, not a timestamped list of what opened when.

The apps on the device

The full list of installed apps is uploaded and stored — up to 300 apps, plus the smaller lists of what you allowed and what you marked essential. Alongside each app we keep a running total of screen time, first seen and last seen, which follows the child's profile from a tablet to a PC.

We also hold a rolling device-health snapshot, refreshed roughly every five minutes, with battery, charging state, network type, app version and whether each protection is still switched on. It does not contain the app currently in the foreground.

Sites, only from our own browser

When the kid browser blocks a site, we may record the normalized host — example.com, never the page, path or search terms — and when the denial happened. Kept 30 days. Allowed visits are not recorded.

This is the only browsing that is recorded today. Chrome, Firefox or any other browser on the device produces no history in ParentProof. What we cannot see there, we cannot show you. Two changes to that are named, with their limits, below.

Your child's voice, when they press the microphone

ParentTap lets a child who cannot make the pictures say it speak instead. When — and only when — your child presses the microphone button, the app records a short clip and sends it to you as their message. It is recorded on no other trigger: nothing in this app can open the microphone in the background.

The clip is stored on our server so you can play it, capped at one megabyte, and deleted after 7 days whether or not you listened. Deleting the request deletes the audio with it. A transcript is attempted on the device itself; the recording is never sent to any transcription service, and our server refuses an upload that claims a cloud transcript. A clip that could not be transcribed still reaches you — that is the normal case, not a failure.

ParentProof Play profile

Only if you choose to create or link one: a game display name, a broad age band — Under 8, 8–12, 13–15 or 16–17 — and the link to the ParentProof child you selected. We do not ask for a birthday or exact age.

The Play identity is kept separate from the child’s ParentProof profile identifier. Game sign-in and the points/data bridge are not available yet, so no game activity is being collected through Play in this release.

Everything in this section is used to operate the parent controls you chose and, only when you create one, prepare that child’s Play identity. None of it is sold, and none of it is used for advertising — see the wall below.

Screenshots and remote taps

These features are not available in the current release. The safeguards below are requirements for any future release, not protections families can rely on today.

Off in the current release. Parents cannot request, upload or view screenshots, and remote taps and swipes do nothing. The related dashboard controls and server addresses are unavailable.

Before screenshots could be released, ParentProof would need all of the safeguards below to be implemented, tested on physical devices and described here as shipped behaviour.

Safeguards required before release

A fresh parent password or equivalent verification before each capture. A signed-in session on its own is not enough.
An access history that shows which parent requested or viewed an image and when, kept for 400 days.
Automatic deletion after a short, published retention period, including queued and failed captures.
A parent switch that is off by default and, when switched off again, stops capture on the device rather than only hiding the control — including deleting pictures already taken and cancelling requests already sent.
Availability limited to a child profile in your own household, on a device you set up as the managed owner. It is never available for an adult’s profile or an unmanaged device.
Physical-device testing across supported Android versions and manufacturers before any availability claim.

No notice by default, and the choice is real

Off by default: no notice on the child’s device, and no child veto. An earlier version of this page listed a notice on the child’s device as a requirement, unconditionally. That is not the plan: if screen viewing is ever released, the DEFAULT is that your child is not told when you look at their screen and cannot refuse. You would be told this, in those words, at the moment you switch screen viewing on — not afterwards, and not in fine print.

The default is not the only option. A notice to the child is a real, built setting — off unless you turn it on — for a parent of an older child who wants their teenager to know, or for a country or app store that requires it. Turning it on is a choice you make, not a promise we are making for you either way.

Remote taps

Remote taps and swipes are also unavailable in the current release. They would require their own child-visible notice, parent verification, access history, expiry rules and physical-device testing before release.

What is not collected

Message content, from any app.
Photos, files or camera. The Android app requests no camera, location, SMS, contacts or storage permission at all — the whole permission list is in the app's manifest and none of those are in it.
The microphone, at any moment your child did not choose. The app does hold the microphone permission, for one feature and nothing else — see your child's voice below. Nothing in this app opens a microphone in the background: there is no service, no receiver and no scheduled job that can.
Location tracking, of any kind.
Keystrokes, message content, form fields and page content — from any app, at any time. One optional accessibility service opens the parent gate when you press volume-down three times from inside another app. It sees only those hardware key presses and stores and sends nothing. A separate remote-help accessibility service is reserved for a future feature; it does nothing in this release and should be left off. One narrow addition is coming and is described below: the address bar of the browsers on your child’s tablet. Nothing else on the screen is read, then or now.
Continuous screen recording, video or screenshots. Screenshot capture is unavailable in the current release; any future version would require the safeguards described above.
Browsing in any browser other than our own kid browser is not kept as history. What a blocked or waiting-for-you address produces is described below — the address, not a history of everywhere your child went.

We are not building the product that reads a teenager's conversations and mails them to a parent. That product exists; this is a different one.

Two things the child app is about to read, and their exact limits

Neither of these is in the child app you have today. They are written here before they ship rather than after, because a privacy page that describes yesterday’s software is the failure this page exists to avoid. When they land, this warning box goes and the text below stays.

1. The address bar of the browsers on your child’s tablet

Filtering that works by refusing to look a name up knows the site and never the page, and it leaves your child staring at a browser error we did not write. Reading the address bar fixes both: a request can name the actual page, and ParentProof can put its own screen up instead of ERR_NAME_NOT_RESOLVED.

The alternative we refused, and why it matters that we did. The usual way to see inside encrypted browsing is to install a certificate on the device and decrypt everything. We will not: it would let us read every secure connection your child makes, Android would show a permanent “your network may be monitored” warning, and it teaches a child to click through certificate warnings. No ParentProof product installs a certificate on your child’s device.

What is read: the address in the address bar, in a browser, on the child’s tablet.
Not page content. Not what is typed. Not form fields or passwords. Not other apps. Not notifications, clipboard or messages. An accessibility service could read all of those — that is why Android restricts them — and everything outside a browser’s address bar is out of scope by design, not by effort.
What leaves the tablet: the same thing a blocked or waiting request has always carried — the site, and at most a short leading part of the path. The query string and everything after # are dropped on the device before anything is sent, so a search you would not want recorded is not sent to us and cannot be.
How long: 30 days, on the same clock as every other request and denial, then deleted.
Where it does not run: the parent app on your own phone. This capability is never going in it.

2. Which app asked for a site

Most of a child’s web now arrives inside somebody else’s app, in a browser built into it that has no address bar to read. Android can tell us which installed app opened a given connection, and that is what lets a request say “this app asked for that site” instead of naming a site with no context.

What is derived: for a request ParentProof is deciding about, which app made it — the same app name that is already in your app list.
Not a log of every connection. Not a list of the addresses each app talked to. Not a record of anything the filter did not act on. The answer is worked out at the moment of the decision and discarded with it.
The honest limit, which the wording you see will keep: inside another app’s built-in browser we know the site and the app, and never the page. A hostname is not a page, and ParentProof will not show you one as though it were.

And the small key in the status bar

ParentProof’s filtering runs as a connection on the device itself, which is why Android shows a key icon whenever it is on. Nothing about your family’s browsing travels through a ParentProof VPN — we do not run one, deliberately: it would put every byte of your family’s traffic through our machines, which is the opposite of how this product is built. The key means the filter is running on the tablet. It cannot be removed while the filter is on, so we explain it during setup instead of hoping you do not notice.

Who else sees any of it

Every outside service the product talks to, what reaches it, and on what terms. There are no others — this is the complete list of network destinations in the code, not a representative sample.

Who	What reaches them	Why	Terms
Cloudflare 1.1.1.1 / 1.1.1.3	Every name your child's device looks up, from every app, not only from a browser.	Resolving names, and refusing adult and malware domains on the family route.	Forwarded over TLS from our server, so Cloudflare sees our address and the name — never your home address. We do not log the queries; the only thing we write down is that the resolver was degraded, and why.
Quad9 and AdGuard 9.9.9.10 / 94.140.14.15	The same lookups, only when Cloudflare is unreachable.	Failover, so the internet does not stop working when one resolver does.	Same shape: over TLS, from our server, not logged by us.
Google Cloud (Vertex AI, Gemini) app classifier	An app's identifier and the developer's name — for example `com.mojang.minecraftpe`. On a Windows PC a program is named by its location rather than by a package name, so what is sent is the folded path, in which the folder named after the person is replaced by a placeholder: `C:\Users\Sam\AppData\Local\Zoom\Zoom.exe` is sent as `%localappdata%\zoom\zoom.exe`. Alongside it go the publisher from the program's code signature, where it is signed, and the company and product names the program states about itself. Never your child's name, your household, or the device — and never the unfolded path, because that one contains the Windows account name.	Sorting an app into a category, so you can write one rule instead of naming apps one at a time.	Off by default. Without the exact documented operator release opt-in, the scan address behaves as though it does not exist and the background job stops before reading the model-provider secret or an app inventory. Malformed values stay off. In an explicitly opted-in deployment, each request carries routing that requires the model provider to retain nothing and train on nothing, refuses fallback to any provider that will not agree, and is restricted to a named list. If those conditions cannot be met the request is not sent at all. Only in that opted-in deployment, this one runs on its own: a background job reads the list of apps your child has opened, classifies any it has not seen before, and repeats on a timer. It runs on Google Cloud's Vertex AI, with OpenRouter as a fallback if Google cannot be reached, and the stored answer records which of the two produced it. As with web addresses, the app's identifier is also submitted to Google Search so the model can look the app up rather than guess from its name.
Google Cloud (Vertex AI, Gemini) web address classifier	A web address on its own. Never your child's name, your household, or the device.	Sorting an address into a category, so a rule can cover a kind of site rather than a list of them, and writing one plain sentence describing what the site is.	This one is on. It runs on Google Cloud's Vertex AI. The address is also submitted to Google Search, because the model looks the site up rather than guessing from the letters in the name — that is the whole point of it, and it is a real disclosure: an obscure address your child visited becomes a search Google performs. Only the address is searched; nothing about your child, your household or the device goes with it. If Google cannot be reached the request falls back to OpenRouter under the routing conditions in the row above, and the stored answer records which of the two produced it. An answer is kept and reused for every other family, so the same address is looked up once rather than once per child.
OpenRouter setup assistant	Your conversation with the setup assistant, plus what its tools read from your own computer and a redacted tail of the setup app's log.	Answering you inside the setup app when something will not work.	Off unless the operator turns it on. Without the exact documented release opt-in, the address the setup app would talk to behaves as though it does not exist, and the setup app hides its chat box and says so rather than offering one that cannot work. Malformed values stay off. No such routing. And in a deployment that HAS turned it on, this one still does not carry the no-retention terms described in the rows above — it runs under OpenRouter's ordinary terms, so do not paste anything into it you would not want stored. Fixing that is on us, and it is why this one is off by default.
OpenRouter family assistant	Your question, and a summary of your own household written with your children's names replaced: the provider is told “Child A”, never a real name, and never a profile, household or device identifier. What it does carry is the shape of your setup — daily limits, bedtimes, how many devices there are and how long apps have been open.	Answering a question you asked about your own family, on the Assistant screen in the dashboard.	Off unless the operator turns it on. Without the exact documented release opt-in, the address behaves as though it does not exist and the screen is not in the menu at all. It only ever answers — it cannot change a setting on a device, because the path that would let it does not exist in this feature. The names are replaced before the request leaves our server and put back on the way out, so you read “Maya” and the provider never saw it. Each request carries the same routing the classifier rows above describe: the model provider must retain nothing and train on nothing, fallback to a provider that will not agree is refused, and the providers are a named list. The one part of that which has no per-request setting is logging at the gateway itself, which is a property of the account the key belongs to rather than of a request; it is why this feature waits on a key of our own.
Resend	Your email address and the message we are sending you.	Sign-in and password-reset email.	Nothing about a child is in these messages.
Google Firebase Cloud Messaging	A push token for your phone and a generic wake-up message. The message contains no child's name, app, site, device name or reason; details are fetched only after the signed-in app opens.	Reaching the signed-in Android parent app for permission requests, help alerts, check-ins and quizzes when the dashboard is closed.	This is built and tested, but has not yet been proved end to end on a released build, so we do not describe it as verified.
Apple Push Notification service	A push token for your iPhone or iPad, and the same generic wake-up message described in the row above — no child's name, app, site, device name or reason.	Reaching the signed-in iPhone or iPad parent app when the dashboard is closed. iOS is sent to Apple directly rather than through Firebase, so Google is not involved in an iPhone notification at all.	The same shape as the Android row, from a different provider. Apple receives the token and a message that says only that something is waiting.
Your browser's push service Mozilla, Apple or Google	Ciphertext only.	Desktop and browser notifications.	Encrypted end to end to your browser. The push service cannot read the contents.
Stripe	Nothing about a child, ever.	Billing.	Hosts subscription checkout and keeps payment records. ParentProof does not receive your full card number.

Two things to know about the resolvers. The category filtering on that route is Cloudflare's list and Cloudflare's categories, not ours — it is on or off, and the per-category switches in your dashboard do not change what it refuses. And DNS is broader than the blocked-site denials described above: it sees every app on the device, which is exactly why it is forwarded rather than recorded.

How long it is kept

There is a temptation to publish a tidy table of retention periods that the code does not actually enforce. Here is the real one, which is shorter and less flattering.

What	How long
Device events — security, requests, blocks, alerts, PIN failures, crashes and usage totals	30 days, then deleted
Blocked kid-browser host denials	30 days, then deleted
Legacy detailed app and allowed-site history	No new rows are accepted or returned. Historical production deletion is still outstanding.
Password-reset links	One hour
Pairing and enrolment codes	Minutes, single use
Legacy screenshots from unreleased testing, if any exist	No new screenshots are captured in the current release. No automatic deletion limit exists for legacy rows; they are removed when the device or account is deleted.
App inventory and cumulative screen time	No limit is implemented. Removed with the profile, the device or the account.
The latest device-health snapshot — battery, charging, network, app version and protection status	No limit is implemented. Overwritten rather than aged out — the newest one is kept until the device is removed.
A ParentProof Play profile — game display name, broad age band and child link	Kept until the parent deletes that child or the household. Explicitly unlinking first preserves the Play identity and its game history so it can be linked again.
A ParentTap voice clip recorded by your child	7 days, then deleted — and deleted immediately with the request it belongs to
Support tickets and their messages	No limit is implemented. Removed when the account is deleted.
An email left on the waiting list, back when there was one	No limit is implemented. The waiting list is closed — the form is gone and the endpoint that took it now refuses everything, so no new address can be added. Any address left while it was open has not been deleted. Nothing in ParentProof reads it and nothing writes to it. It is not attached to an account, so deleting an account does not remove it — ask and we will.

One caveat on the 30-day rows, because it matters: the deletion runs when the next event of that kind arrives, not on a timer. On a device that has gone quiet, the last events sit there until something wakes it or the device is deleted. That is a real limitation of how it is built, not a rounding error.

Children's data

This product exists to be used by a parent or legal guardian on a device belonging to their own minor child, with the authority to do so where they live. That is the only use it is designed, tested and written for — see Terms.

A child profile is not an account. A child does not sign up, does not give us an email address, and cannot be contacted by us. What we hold about a child is the activity described above, attached to a profile you created and named.
We do not ask for a birthday or exact age. Child setup optionally asks for one coarse range to suggest a starting app list; that answer is processed once and is not retained. If you choose to prepare a ParentProof Play profile, you separately select one broad age band so games can later choose a suitable experience. That Play band is your choice; we do not infer or verify it from what a child does.
The supervised device says so, the whole time. The ParentProof app runs in the foreground with a notification that stays visible — "ParentProof Secure · Watching over this phone" — and carries its own name and icon in the app list. Nothing about it is hidden, renamed or disguised, and we will not build a version that is. A monitoring tool a child cannot see is a different product with a different name for it.
Nothing about a child reaches an advertiser. See the wall.
You control all of it. Every rule, every profile and every piece of history is yours to change or delete from the dashboard, at any time, without asking us.

Where you live may give your child or you rights over this data — under COPPA in the United States, the UK and EU GDPR, or an equivalent local law. We will honour them; the practical route is below, and a person reads and answers it rather than a form.

The age band is not age verification. Several laws draw a line at 13. A Play band can record what the parent selected, but it does not prove a child’s age and is never inferred from their activity. The adult still represents that they are 18 or over and are the child’s parent or guardian under the Terms. This is a product description, not legal advice, and our lawyers may revisit it; if they do, this paragraph changes with it.

The wall between your child and our marketing

This is the part we are most willing to be held to.

Marketing consent is separate, off by default, and split into three independent choices you can change at any time from your dashboard. Nothing is on because you did not notice a pre-ticked box.

Behind that, there is a filter every outbound marketing event has to pass. It works on the payload, not the label: an event carrying a device identifier or any marker of child telemetry is refused before consent is even consulted, no matter what type it claims to be. A bug that mislabels a child event as a marketing one therefore does not leak it — it gets dropped.

And the plainest fact of all: there is no marketing tool connected on the other side. No analytics vendor, no advertising pixel, no email marketing platform is wired up. Events that pass the filter are written to our own log and go nowhere else. If that ever changes, the vendor gets named on this page before it happens.

Why it is built that way. Consent checks fail the moment something is labelled wrong, and labels are written by people. Checking the contents instead means the boundary holds even when we make a mistake.

Technical detail attached to a bug report

When you send us a report, there is a tick box for attaching technical details. It is opt-in, it is capped in size, and nothing is transmitted until you press the button. Untick it and you send only your words. We never collect it from your machine on our own — it is attached by the app, on your instruction, or not at all.

Be precise about what "redacted" means here, because it is narrower than the word suggests: the filter strips things shaped like credentials — setup codes, tokens, long hex and base64 strings — so a secret cannot leak in a log tail. It does not strip personal information. A file path containing your child's name, a device name, or an app name will come through as written.

The child's app also reports its own crashes so we can fix them. A crash report is the failure itself, not what the child was doing — with one caveat we would rather state than gloss: the error message is included, up to 200 characters, and if the thing that failed was a page load then a hostname can appear inside that message.

Your data, and getting rid of it

Delete your account, from the dashboard, yourself. It asks for your password, then removes the household record — child and Play profiles, policies, rules, app history, activity, screenshots, entitlements, support tickets and your login. If any tablet or computer is still linked, it names them and warns you first, then releases them: see the note just below.
Withdraw any marketing consent at any time, from the dashboard, without contacting anyone.
Download a copy of your account from the dashboard: your account, household, devices, profiles, policies, app lists and rules. It does not include the activity history — events, browsing, screenshots, support messages. If you want those too, ask and we will put them together by hand.

Deleting the account releases your devices, and you no longer have to unlink them first. Before anything is erased, every linked device is told to stand down; the instruction is kept for devices that are offline at the time, so it is still waiting when they next connect, even though the account is gone by then. A tablet that never connects again never hears it and keeps its last rules — so release a broken, lost or permanently offline device from the dashboard while you still can. An earlier version of this page described the old behaviour, where deletion stranded a tablet, and called it a bug being fixed. It has been fixed; this paragraph is what replaced it.

Three things that survive deletion

Not everything goes, and we would rather explain the exceptions than let you find them.

The security audit log, with your account identifier replaced by a one-way hash so the rows are no longer connected to you.
The record of who was added to or removed from a household, and who switched a child profile.
An email address left on the waiting list, if you left one before it closed. You cannot join it any more — the form and the endpoint behind it are both gone. Ask and we will remove your address.

The first two survive on purpose: they exist so that an adult cannot erase the record of their own actions in a household by closing the account. In a product where two adults share control of a child's device, that is a safety property, and we are not going to trade it away for a tidier deletion promise. The third is not a design — it is a leftover of a form we no longer offer, and we would rather list it here than let you find it.

Security, in the same plain terms

Passwords are stored hashed, never in a form anyone can read back.
Everything between a device, the dashboard and our server travels over TLS, and so do the DNS lookups we forward.
Anything available for a device — its settings and its history — requires a valid session on an account that shares that household. Screenshot addresses are unavailable in the current release.

What our own staff can see

Our support staff have an operator console, and pretending otherwise would be the same mistake this page was written to correct. What it can reach: the list of account email addresses and which household each belongs to, support tickets and their messages, and service diagnostics. What it cannot reach: your devices, your child's activity, browsing, app history or screenshots — there is no operator route to any of them, and we checked every route on that console before writing this sentence.

Getting in requires a separate operator login with the specific permission for that action; anything beyond an operator's standing permission needs a time-limited grant that another operator has to approve; and the reads are written to an audit ledger that the operator who performed them cannot edit.

Cookies, and this website

There are no cookies, anywhere in ParentProof. Not on this site, not in the dashboard, not a "necessary" one. Your dashboard keeps its sign-in token in your own browser's storage and signing out deletes it.

parentproof.com loads nothing from anyone else either — no analytics, no tracking pixel, no third-party fonts, no embedded video from a platform. The only thing this site ever sends anywhere is the email address you type into the waiting-list box, plus which page you typed it on, and it goes to our own server.

What we will not claim: that any of this makes a breach impossible. If one happens, you will hear it from us, quickly, with what was taken.

Asking us something, or complaining

Two routes, both reaching a person:

Email support@parentproof.com — for anything about this page, a request for what we hold about you, a deletion you cannot complete yourself, or a complaint.
The report button inside the setup app or the "Something not working?" card in your dashboard — best for anything broken, because it arrives with the context attached. See Support.

Who to write to. This page describes the system you can check, and it is the policy we hold ourselves to. If you need a formal record of anything on it, or a postal address to write to, ask and you will get a straight answer.

We can update this page as the product changes. When something material changes we date it and say what changed, as at the top of this page — we do not backdate an edit to cover something that already happened.