For schools
Privacy for districts
Who processes student information for us, how it is protected, and what we do if something goes wrong. Everything here comes from the documents a school accepts.
Companies that process information
These are the companies that handle information for TaleTykes, what each does and what reaches it. The school agreement carries the same list.
| Company | What they do | What reaches them |
|---|---|---|
| xAI | Writes the stories, draws the pictures, reads them aloud, turns a child's spoken words into text, and checks words a child wrote when our own checks are unsure of them | The story instructions a child chose, the text of their book, and the pictures made from it. A first name only when the child asked for themselves to be in the story. When a child chooses to speak to Pip, a few seconds of their voice go to xAI to be turned into words: we do not keep the recording, and the words are kept only if a safety check objected to them. The names in their book go with it so that made-up names are heard correctly. When a child writes a comment about a shared book and our own checks cannot tell whether it is fine, the words of that comment are sent to be checked; a comment refused because it named a person, a place or a way to reach somebody is never sent, because it is refused before that step. Using it to train their models is forbidden by contract. Nothing is kept once zero data retention is in force for our account, which the application checks on every single call. Without it, thirty days. |
| Anthropic | Reads finished books back and marks how well they are written and drawn | The text of a finished book and its pictures. Nothing a parent typed, and a child's first name only where the book already contains it. Using it to train their models is forbidden by contract. Thirty days unless zero data retention is arranged, which the application records so a lapse is noticed. |
| Sightengine | Looks at every picture, before it is stored, for the one thing we are obliged to report | The picture, and nothing whatever alongside it. Not a name, not an age, not a word of the story, and not even the name of the file: it is sent as "picture.jpg" so that nothing about whose it is travels with it. This is the check a drawing sent in by a child goes through as well as a picture we drew ourselves, and so does a photograph a grown-up adds as a reader's picture or as their own; a photograph is refused rather than kept if this check cannot be made. Their models can be taught from a picture only where it is handed to them for that purpose through a separate service of theirs, which this product never calls. Using it to train their models is forbidden by contract. Their contract provides for deletion on request, and within ninety days of the agreement ending. Whether a picture is discarded the moment it has been looked at is a setting on the account rather than a promise in the contract, so this notice does not claim it. |
| Stripe | Takes payment and checks that an adult is holding the card | A parent's email address and card details, which go to Stripe directly and never through us. We keep a one-way fingerprint of the card and no card number. |
| Vercel | Runs the site and stores the pictures, including any photograph a family adds as a reader's picture | Everything the site holds, as the place it runs. That includes every picture, each stored privately with no public address, among them any photograph a grown-up adds as a picture for a reader or for themselves. |
| Neon | Runs the database | Everything the site holds, as the place it is stored. |
| Upstash | Holds short-lived counters and passes each step of book-making to the next | Identifiers and counts. No story text, no names. A book's identifier passes through it; the book does not. |
| SendGrid (Twilio) | Delivers email to parents and staff | A parent's email address and the message itself. Nothing is ever addressed to a child. Open and click tracking are turned off. |
| PostHog | Draws the graphs from the counts of what happened on the grown-up and public pages | A copy of the counts this product already keeps in its own table, and only those it is allowed to copy. What travels is the name of the event, which of the three surfaces it happened on, an opaque identifier for the account, and a short list of allowed properties such as which plan was chosen. No address travels and none is worked out at the other end. Nothing counted on a child's screens goes, because nothing is counted there at all; and the events written elsewhere at a child's own press, such as switching Pip's voice on, are kept off the list that may be copied, along with their age group. No script of theirs runs on any page here: the copy leaves from our servers. How long they keep it is set by our plan with them rather than by us, so this notice does not claim a number it cannot enforce. What is ours to enforce is stated instead: our own copy of these counts is deleted at four hundred days by the nightly job, and a family who asks to be deleted is asked to be deleted at PostHog too, along with the events attached to them. |
| Sentry | Tells us when a page has broken, so that it is noticed rather than reported | What went wrong and where in the code it happened. Personal details are switched off rather than filtered, and everything is put through a scrub of our own before it leaves. Recording what is on the screen is switched off and is not merely unconfigured: this product is used by children, and a recording of the screen is a recording of a child reading. |
| Yoto | Plays a finished book on the screen-free player a family already owns, and only for families who connect their own Yoto account | The book's title, and a web link to each page's recorded voice. The title is the book's own, and a book made for a child often has their first name in it, so a first name usually goes with it. Nothing else about them does: not their age, not a word of the story and none of the pictures. The chapters are called "Page 1", "Page 2" and so on so that no part of the story travels with them. This applies only to a family who has connected a Yoto account, and only to the books they choose to send: for everybody else, nothing at all reaches Yoto. The audio is streamed from us when it plays and no copy is kept there, so taking a book back stops it. Nothing of ours is stored with them. They keep the playlist, which is the title and the links, until it is taken back. |
| Lets a grown-up sign in with a Google account they already have, instead of inventing another password, and only for those who choose that button | Nothing is sent to Google. Pressing the button takes the grown-up to Google's own page, where they sign in to Google rather than to us, and Google tells us back their name, their email address, and whether it has confirmed that address. That is the whole of it, and it happens once at sign-up and again each time they sign in this way. We ask for no other permission on their account, so nothing in their mail, their contacts or their files is reachable. Because it is Google's own page, Google knows that this person signed in here; a family who would rather it did not can use an email address and a password instead, which is what the same screen offers. Nothing about a child is involved at any point: children have no email address and no account here, and never see this screen. What we keep is the token Google hands back, so that the button works next time. It is deleted with the account. What Google keeps about their own sign-in is theirs and is covered by the notice below. | |
| Google Ads | Counts when an advertisement led to a new grown-up account or to a payment, and nothing else | That a grown-up account was created, or that a payment finished. A payment also carries the payment's own reference, so that opening the confirmation again is not counted as a second payment, and the amount and the currency when we already have them. No child's name, no age, and nothing a child did. No address. Their script loads only on the grown-up marketing pages, the sign-up page and the page that confirms a payment, and only when the same rules that allow our own measurement allow it. It never loads on a child's screen, and it never loads on a sample book a child can open without an account. We tell them not to use what they receive to build an advertising profile, and it is not used to decide what anybody here is shown. Signing in with Google, which is the row above, is a different use of the same company and does not load this. How long they keep a conversion is set by their own terms rather than by us, so this notice does not claim a number it cannot enforce. What is ours to enforce is where the tag may load and what it may be told, which is set out in the privacy notice. |
| Apple | The same thing with an Apple account, for a grown-up who would rather use the one their phone or laptop is already signed in to | As with Google: nothing is sent to Apple, the grown-up signs in on Apple's own page, and Apple tells us back an address and, on the first time only, a name. Apple offers to hide the real address and give us a relay address instead, and that choice is theirs and works here: the account is made against whichever address they picked, and every email this product sends reaches them through it. Apple learns that this person signed in here, for the same reason Google does. Nothing about a child is involved. The token Apple hands back, deleted with the account. If a parent hid their address, we never hold the real one at all. |
How information is protected
From our written information security programme, version 4. Read the whole programme.
The safeguards
One family cannot see another's data, and this is enforced by the database. The application connects as a role that cannot bypass row level security. Every request opens a transaction and declares which parent and which child it is acting for; a query that forgets to declare a context matches nothing rather than everything. Code that legitimately crosses families, such as a payment webhook or the moderation console, uses a separate owner connection and writes an audit entry.
Secrets are hashed with an algorithm chosen for the purpose. Parent passwords and children's PINs use Argon2id. A four-digit secret has little entropy, so the defence is attempt throttling, not secret strength: five wrong attempts locks the profile for fifteen minutes, and a parent can revoke every session.
A child's sign-in is a profile selector, not a security boundary. This is a deliberate design decision rather than an oversight. A child's PIN or picture sequence opens their own shelf on a device a parent has already trusted. It cannot change a setting, reach billing, see another child's books or leave the child area: leaving requires the parent's own account password. The blast radius of a guessed PIN is one shelf of that family's own books on that family's own device.
Addresses and browsers are recorded as one-way hashes. Knowing that two events came from the same place is useful. Keeping the place is not worth the risk.
Pictures and audio are private. They are stored with no public URL and served through a route that checks who is asking and signs a short-lived link.
Records that are evidence cannot be edited. The credit ledger, the audit trail and the consent records accept new rows only; a database trigger refuses updates outright and permits deletion only inside a declared erasure. A mistake is corrected by an opposing entry, never by rewriting the first one.
Staff accounts require a second factor. A staff sign-in needs time-based one-time codes actually enrolled, not merely offered. Every staff action requires a written reason, which goes to the audit trail.
Anything that can run away has a ceiling. Book generation has a per-book cost ceiling and a daily platform cap, both enforced before spending rather than after. There are kill switches for generation, signups, email and the shared library, operable from the console without a deploy.
Nothing becomes public without a person. A book is private to its family unless a parent turns sharing on and a member of staff has read it.
Testing
- The isolation rules have their own test suite, which asserts that one family's connection cannot read another's rows. It runs on every change, against a real database branch, in continuous integration.
- Unit tests cover the safety cascade, the reading checks, the moderation rules, pricing and the consent gate.
- End-to-end tests walk a family from sign-up to a finished book, including the consent gate.
- An accessibility check runs over the parent and child screens in the same pipeline.
- Dependencies are updated on a schedule and on advisory.
If something goes wrong
- Contain it: the kill switches stop generation, signups and mail without a deploy, and a compromised credential is rotated first.
- Establish what was reached, using the audit trail.
- Tell the families affected, in plain words, saying what happened, what it means for their child, and what we have done. We do this promptly and without waiting to be asked.
- Notify the regulators that apply, within the time each requires.
- Write down what we changed so it cannot happen the same way twice.
If something goes wrong
From the school agreement, version 2, which a school accepts before any student is added.
Security, and if something goes wrong
We protect student information with the same measures that protect every family's, described in our security programme. If we confirm that student information has been accessed without authority, we tell the school without undue delay and within 72 hours, with what we know, and we keep the school informed.
The records belong to the school
The school controls its students' records. It can download them at any time, and it can ask us to correct or delete them. Where the Family Educational Rights and Privacy Act applies, TaleTykes acts as a school official with a legitimate educational interest in the records, under the school's direct control as to how they are used and kept.
A signed agreement
Many districts sign their own data protection agreement, the Student Data Privacy Consortium’s national one, or a state addendum. A school admin can ask for one from the data and privacy page in their school’s account, and we reply by email. Anybody else can write to us.