What we hold, and what we refuse to

What changed, and why we are saying so

Copy corrections prepared 1 November 2026. The app-list section now names the apps the tablet actually reports instead of claiming a full-device list. Screen capture has passed QA checks on two physical devices, but the public tablet app predates that path; the screenshot section distinguishes the two. Tablet purchases depend on stock. This version also explains database-backup retention and the limit on restoring a deleted account. These are corrections to the description, not a new product release.

3 October 2026: screenshots are now part of ParentProof, and the section on them says exactly how they work. Until this version, this page said screen capture was off and listed the safeguards any release would need. Those safeguards are now how it works rather than a list of requirements, and the one that is not finished is named. It also corrects what an earlier version got wrong: capture on the tablet is silent, so your child is not told when you look and cannot refuse — an earlier version wrongly said the tablet showed a prompt your child could decline, and it no longer works that way. Remote taps and swipes are still unavailable. (A version before that described dormant features as though families could use them; that was wrong too, and it is why this page now describes only what the code does.)

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. When you give a child’s age range while adding them, ParentProof also creates that child’s Play profile, and we keep a game display name and the broad age band taken from that range. 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. Both permission claims needed correction: the child app declares camera permission for its setup QR scanner, which opens only when you choose to scan a pairing code on the tablet; it also holds microphone permission for ParentTap. 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. The recording and its 7-day limit are described above. A recording of a child speaking is among the most sensitive things this product touches, and a policy that denies holding it is worse than no policy at all.

This update also corrects the public-site storage description. The previous version said there were no cookies anywhere and still described a waiting-list form that had already been removed. The dashboard actually writes one shared light/dark preference cookie, the public site reads it, and the tablet funnel has a small local event and consent layer. The exact values and network boundary are now described below.

24 October 2026: the early beta is open to every family, and free. Anyone can create an account and download the setup app, and no card is needed. The old waiting list is closed, because there is nothing left to wait for: its 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.

Added in this version: the free tools at try.parentproof.com. Our free printable tools (checklists, routines, app plans and handouts) run in your browser, and your answers in them are never sent to us. If you choose to save a result, we keep what you type into that form: your name, your email address, and any optional question on that page you answer. With it we keep the title of the result you saved, which tool it was, the exact wording and version of the consent you ticked, your browser type, the country your connection came from, and the time. Nothing about your child is kept. Your IP address is used for two minutes to stop repeated submissions, then discarded. This is stored with Cloudflare, which runs those pages for us, and is deleted automatically 12 months after you save it. It is not attached to a ParentProof account, so deleting an account does not remove it. To unsubscribe, or to have it deleted sooner, reply to any email from us or write to support@parentproof.com. These tools send no email today; when they do, each message will say who it is from and how to unsubscribe. The free tools are separate from the ParentProof app, so they are not in the table of the app’s outside services below.

3 October 2026, tablet orders. This page said there was nowhere to put a postal address and called the tablet store test-only. A tablet can be bought from your signed-in account only while one is in stock, so an order keeps the shipping address you confirm at checkout. What is kept, who sees it, and for how long are now set out below and in the retention table.

3 October 2026: four more corrections, because this page had fallen behind the code again. It had the age range in child setup wrong: setup will not add a first child without a range, the range is kept, and the child’s Play profile is created with it. It called its list of outside services complete when eight were missing (they are now in the table below). It said the microphone served one feature when the app also carries ChatProof’s recorder, which cannot start in this release. And it described the address-bar reader and the which-app-asked attribution as coming, when both were already in the child app. The product did not change; the page did.

Added in this version: photos and videos you choose for your child’s tablet. A new section, below, describes a feature that arrives switched off: what you upload, where it is kept, what reaches the tablet, what your child can do with it, and when it is deleted. It also adds four rows to the retention table, says how those photos and videos are backed up, encrypted, at Cloudflare R2, and how a parent turns them off for the whole family.

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.

Screenshots

A parent can ask to see one picture of what is on a child’s Android tablet right now. It is off until you switch it on for that child, you confirm your password once per viewing session, and the capture is silent on the tablet — your child is not told and cannot refuse.

Who can ask, and for whom

• Any adult in your household can ask, once screen viewing is switched on for that child. Opening a viewing session needs a fresh confirmation that it is you — your password, plus your second sign-in step if you turned one on, or a passkey. One confirmation opens a session: for about five minutes you can take more pictures of that child without confirming again, and after that you confirm once more. An account with no password cannot ask at all.
• Only the adult who asked can open the picture. A co-parent who wants to look asks for their own, with their own confirmation.
• Only for a child profile in your own household, on an Android tablet that ParentProof manages as its owner, with protection switched on, while that child is the one using it. Never for an adult’s profile, an unmanaged device, a Windows PC or a Mac. If the tablet is switched to another child before it picks a request up, the request is not sent to it.

Switching it on, and off

• Off by default, for every child. Turning it on needs your password, and a tick confirming you understand that ParentProof sends your child no notice of its own.
• Turning it off is one tap, with no password, and it stops capture rather than hiding a button. Pictures of that child already taken are deleted, wherever the tablet is now; requests still waiting on that child’s tablets are cancelled; a picture that arrives afterwards is refused; and a picture that was ready can no longer be opened.

What your child sees

We disclose this plainly here, and in the app-store listings, because the honest audience for it is you — the parent who set this tablet up for your own child — and the stores that list ParentProof, not a prompt on your child’s tablet. An earlier version of this page said Android showed a prompt on the tablet that your child could decline; that is no longer how capture works, and the page is corrected.

What is taken, and where it goes

• One still picture of the whole screen, at the moment it is allowed. Not video, not sound, not a recording, and nothing left running afterwards. The tablet keeps no copy: it sends the picture and discards it.
• It is stored in ParentProof’s own database, the same place as the rest of your account, and sent to no outside service — no classifier, no AI model, no analytics. Our support staff have no route to it.

How long it is kept

• The picture: five minutes. It can be opened for 5 minutes after it reaches us, and is then deleted from our database within about a minute, by a clean-up that runs every minute rather than waiting for something else to happen. Turning screen viewing off deletes it at once.
• A request nobody allowed expires 3 minutes after you asked. The tablet is not sent it after that, and nothing is stored for it.
• The note of who may open a picture is deleted 8 minutes after the request, and the record of the viewing session (kept so the server recognises the same confirmation within its window) within 5 minutes.
• The access history — which adult switched screen viewing on or off, asked for a picture or opened one, for which child and tablet, and when, never the picture itself — is in your Household activity. It keeps the adult’s identifier for 400 days; after that the identifier is removed and the entry stays. Like the rest of that record, it is not deleted when an account is deleted.

Not finished yet

• Testing on physical tablets. Silent capture passed QA checks on a Pixel 7 Pro and a CP31U with QA build 2026100401 on 4 October 2026. The public tablet download, version 2026091605, predates this capture path; those QA checks do not prove screen viewing works on that release. Testing across other physical tablets, Android versions and manufacturers is still unfinished. A request may fail on some tablets, or the picture may come out blank.

Remote taps

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

Two things the child app reads, and their exact limits

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.

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.

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 asks for one coarse age range, and ParentProof will not add your first child without one. It is used to suggest a starting app list, and it is kept: in your account’s setup progress, with the child’s setup record, and in the ParentProof Play profile that is created for the child automatically when the range is given. A ParentProof Play profile is created for every child who is given an age range, with one broad age band chosen from that range 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.

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.

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. A picture of the screen also needs a fresh password confirmation for each viewing session (about five minutes), and only the adult who asked can open it.

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; and, for the photos and videos a parent adds, removing one, without being shown it. What it cannot reach: your devices, your child's activity, browsing, app history, screenshots, or the content of those photos and videos — 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 at most two cookies, and neither tracks you. pp_theme remembers whether you asked for light or dark mode, so the next page does not flash the wrong one. It carries nothing about you, just "light" or "dark". pp_app_sheet (sent as __Host-pp_app_sheet) is set only when you open a ParentProof screen from our phone app, for example to finish setting up. It is a signed, short-lived session, at most 12 hours, that lets that screen do the one job the app sent you there for, and while it lasts that browser cannot make purchases. It carries no tracking data and expires on its own; signing out clears it. Your dashboard keeps its sign-in token in browser storage instead; signing out deletes that token.

The public site can also keep pp_marketing_consent in local storage as described above. It is a choice value, not an identifier. The site loads its fonts, images, styles and scripts from ParentProof rather than an analytics or advertising network. Depending on the page, it requests current plan, download, or test-hardware catalog data from platform.parentproof.com. Opening a configured test checkout sends only SKU id, quantity, plan id, interval, and a fresh random checkout-attempt id to that ParentProof API; it sends no browser-authored price, email address, account, child, or device id. Only after that endpoint verifies the server-owned Price does the browser navigate to Stripe.

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.