BiteSize — Privacy Policy (children's learning breaks)
DRAFT v0.13 · 2026-09-13 (consent and deletion apart) · not yet published, not yet reviewed by counsel. Every
«placeholder»must be filled by the owner before this is published anywhere. Hebrew version:PrivacyPolicy-HE.md— the same policy; the two change together (../PRD/Legal.mdLN-06).One policy, three regimes (D152). Israel, the EU/EEA and the United States. The body below is unconditional and set to the strictest of the three; everything that genuinely differs by country is in §14, "Where you live", and nowhere else. If a regional rule would change the body, we change the body for everyone (
../PRD/Legal.mdLN-15).
Effective date: «TBD — effective date (C8)» · Policy version: 1.0 · Applies to: the BiteSize Android app
(com.bitesizelearning.app), the BiteSize parent website and the BiteSize server.
1. Who we are
«TBD — legal entity (LQ-2, C1)», «TBD — registered address (LQ-2, C1)», Israel. Controller of the data described here.
- Privacy contact: «TBD — privacy contact address (C2)»
- Security programme coordinator: «TBD — coordinator name/role (LN-13)»
- EU representative (GDPR Art. 27): «TBD — EU representative name + address (C3)» — EU and EEA parents may contact them instead of us, in their own language.
We decide what happens to this data. Nobody else does.
2. Who this policy is about
- The parent or guardian — the adult who installs BiteSize, sets it up behind a PIN, and (if they choose) creates an account on the parent website.
- The child — the person using the phone. The child never signs in, never types an email, and is never asked anything about themselves.
We do not ask any child's age, and we never will. We do not need one: we treat every child as requiring a parent's consent, whatever their age and wherever they live. That is stricter than any of the three laws we work under, and it means we hold no birthday, no age, and no age estimate.
A parent account is required to use BiteSize. The app links to a parent's account during setup, and until it does, it does not run. That is how we know an adult is behind it before a child uses it.
Everything beyond that is the parent's choice. Linking the phone does not send us anything about the child's day. That is separate, off when the app is installed, switched on only by the parent after reading §5 — and our server can never switch it on.
3. What we collect
3.1 On the phone, always (never sent anywhere by itself)
BiteSize works fully offline between syncs. These stay on the device unless §3.2 or §3.3 applies:
| What | Example |
|---|---|
| Which apps the parent chose to put breaks on | com.google.android.youtube — the package name, never the screen content |
| Time accrued in those apps | "24 minutes since the last break" |
| Break and question activity | question id, the answer chosen, right or wrong, points, trophies |
| Learning position | class, month, week, category progress |
| Settings the parent set | break length, cadence, language, the parent PIN (device only) |
| The child's first name and class, if the parent typed them | "Maya, 3rd grade" |
3.2 Sent to our server once the phone is linked — without asking about your child's day
Linking the phone means the phone and our server talk to each other. What they exchange is what a link and a configuration are — never what your child did:
| What | Why |
|---|---|
| A random device id, and a random child id | So the phone knows which account it belongs to |
| App, protocol and configuration versions, and whether the app is running | So we serve the right configuration and can tell an old phone it needs updating |
| The child's first name and class, as the parent typed them | So the parent sees a name and not an id on their own page |
| Any break command a parent sent from their own screen | So "break now" reaches the phone |
None of that says anything about how your child spent their day. That is §3.3, and it needs your consent.
3.3 Sent to our server only with your consent
Only what you switch on, scope by scope (§5.2). Each of these is keyed by the ids in §3.2 — never a name in the stream — and carries the phone's clock for each event, the time we received it, and the app and configuration versions that produced it.
| Scope | What is sent |
|---|---|
learning — the learning and app-tracking record |
Questions shown and answered: question id, the answer chosen, right or wrong, points, and progress by subject; the tracker heartbeat, every app opened (package name, and whether it has breaks) and break events — what the parent's own page shows. Required for pairing |
analytics — the app's own log |
BiteSize's own decisions and errors (week moved, class advanced, day rolled, configuration applied, refusals) and, only when we ask about a fault you reported, a short replay of one day. Optional |
With both refused, nothing in this section is ever sent — and the app is unchanged (§5.1).
3.4 The parent's own account
The account lives on the BiteSize website. You sign in with Microsoft Entra External ID — with an email address and a password, and a name you give when you sign up — and what reaches us from that sign-in is your verified email address, a stable identifier the sign-in service gives us, and that name. We do not receive or keep your password, and we do not keep the name: it arrives with the sign-in, and nothing of ours reads it or stores it. Alongside it we hold the account's children and devices, and a record of every consent given or withdrawn (§5.4).
3.5 What we never collect
BiteSize does not collect, and contains no code that could:
- Images, photos, video, audio, screenshots or screen recordings — of the child, the phone screen, or anything else.
- What the child watched, read or typed — no media titles, no video ids, no URLs, no browsing history, no message content, no keystrokes. Media titles were removed from the product in 2026.
- Location of any kind — no GPS, no coarse location, no IP-based geolocation for profiling.
- Contacts, calendar, call log, SMS, files or photos on the device.
- Advertising identifiers, advertising cookies, or any behavioural profile.
- Biometrics — no face scan, no voice print, no age estimation from a picture.
- Age, date of birth, or any age signal (§2).
- Health, religion, ethnicity, political opinion or any other special-category data.
4. Why we use it, and on what basis
| Purpose | Data | Basis |
|---|---|---|
| Run the break loop and serve questions | §3.1, on the device | Necessary to provide the service the parent installed. Works with no account and no network. |
| Keep a child's learning record across a change of phone; show the parent progress | §3.3 learning events | The parent's consent (§5) |
| Show the parent what their child's day looked like, and support them when something goes wrong | §3.3 event log | The parent's consent (§5) |
| Reproduce a specific reported fault | a short diagnostic trace (scope analytics) |
The parent's separate, expiring consent |
| Link the phone to a parent's account, and run that account | §3.2 and §3.4 | Necessary to provide the service. This is not a consent question and we do not present it as one — the app requires it, we say so plainly, and a parent who does not want it should not install BiteSize. We still obtain verifiable parental consent (§5.3) before any of it, because US law asks for that whatever the basis |
We do not use any of it for advertising, for automated decisions with legal effects, or to train artificial-intelligence models. We do not sell it and we do not accept anything of value for it.
5. Consent
5.1 Consent is required before we collect anything, and refusing costs nothing
We collect nothing about a child's day until a parent has consented. Refusing changes nothing about how the app works — every break fires, every question is asked, every point and trophy is awarded, and every setting still works. The only difference is that we receive nothing, so the parent's own dashboard has nothing to show. A parent may refuse at the start, refuse later, and require us to delete whatever we already hold (§8). Nothing in the app is withheld, slowed, or made worse because a parent said no.
The one thing that is not a choice is linking the phone to a parent's account (§4) — the app does not run without it, we say so before anyone installs it, and we do not dress it up as a switch.
5.2 What can be consented to, separately
Each of these is its own switch. All ship off. Turning one on does not turn on any other.
| Scope | What it covers |
|---|---|
learning — Learning and app-tracking record |
Questions served and answered, correctness, points, progress by subject; heartbeats, apps opened (package names), break events. Required for pairing — a phone whose parent refuses it cannot be joined to an account |
analytics — The app's own log |
BiteSize's own decisions and errors, and a short replay of one day requested by us for a specific fault, expiring after 30 days and revocable at any moment. Optional |
Pairing a phone to an account (the child's first name, class and device id) is not a separate consent — it is what a parent does when they choose to have an account at all. Stopping sharing (§5.5) leaves the phone linked; only deleting the child's data or the account ends the link (§8).
5.3 How consent is given, and how we check it is really the parent
The same way everywhere, for every family, whatever the child's age:
- The parent creates an account on the BiteSize website — on a computer or a phone browser, never inside the child's app — with their own email address, which the sign-in service verifies.
- They read the notice on the child's phone — what is sent, what is never sent, why — before any switch is offered.
- They accept the notice on the phone — the learning record is required, the analytics log is optional —, behind a parent PIN they choose the first time. That tap is the consent. The PIN is set by the parent who then links the phone (step 4) and opens the Parents tab from then on, so a child holding the phone cannot give it. A parent who rejects keeps BiteSize working on that phone alone: it shows no code, it cannot be linked, and nothing about the child is sent.
- They link the child's phone by typing the eight-character code the phone shows, while signed in to that account. Nobody else can: the code is accepted only from a signed-in parent, and only for a phone whose parent accepted the whole notice in step 3 — the phone shows no code before that, and the website refuses one for such a phone.
- The record of the decision names the policy version and the language on the screen they read it on (§5.4).
Only the parent's PIN can turn something on. At setup anyone holding the phone can refuse; after that, stopping sharing is behind the PIN too (Parents → Stop sharing). On the child's phone the app offers the parent two answers to the notice — accept or reject — and they are not symmetric, deliberately:
- Reject is final and immediate. The phone records the refusal itself and tells our server, which refuses anything further from that phone for those scopes from the very next request. A refusal needs no proof of who made it: nobody is harmed by a no.
- Accept asks for the parent PIN first. Only then is the grant recorded and sent to our server, which starts accepting data for exactly the scopes ticked. Support staff can withdraw a consent on our side; they can never grant one.
A phone that is not linked to an account shows no consent switch at all and never sends anything. Linking is required to finish setup, so the app is not usable before it (§4). Once the phone is linked it works on its own — the breaks, the questions and the rewards need no connection to us, and none of them stops if the phone never reaches our server again.
We use one method for everyone rather than a weaker one for some countries, because the strictest of the three regimes we work under — the US COPPA Rule — requires a verifiable method, and we would rather have one honest path than three.
5.4 We keep a record of it
Every grant and every withdrawal is recorded: which child, which device, which scope, when, which version of this policy was on screen and in which language, how it was given, and the app and configuration versions in force. That is how we can show, later, that consent existed — and how a parent can read the exact words they agreed to.
When you delete the account, the record stays for seven years (§7). It keeps the account id and the child id; the e-mail address and every name are replaced, the moment the account is deleted, by a keyed hash — a one-way code we can match against an address you bring back to us, but that nobody can read a name off. So the record still proves that consent existed, and names no one.
5.5 Ending consent — stop sharing
You can stop sharing at any time, on the phone, and it is never harder than accepting was.
Parents (behind your parent PIN) → Stop sharing → confirm. Our server records both scopes,
learning and analytics, as withdrawn, and from the next call nothing about your child leaves the
phone. The phone saves the change once our server has recorded it.
- Only the app's own log: Change what is shared → untick
analytics→ Accept. - To share again: Change what is shared → Accept.
Stopping sharing ends consent, not the link and not the data. The phone stays linked to your account, and what we already hold stays until you delete it (§8). Our support staff can also withdraw a consent on our side; they can never grant one.
Ending never breaks the app. Breaks still fire, questions still serve, trophies are still awarded — all of that runs on the phone, with or without us.
6. Who else sees it
Nobody. We do not share, sell, rent, disclose, trade or transfer children's data to any third party for any purpose. To be unambiguous under each of the three regimes' own words: there is no "disclosure" to a third party (COPPA), no "sale" and no "share" (US state privacy laws, including cross-context behavioural advertising), and no third-party controller anywhere (GDPR). No advertising network, no analytics provider, no data broker, no AI training, no "partners". BiteSize contains no advertising and no analytics SDK of any kind, and a build that added one would fail our own release check.
Two necessary exceptions, both processing on our behalf and neither of them sharing:
- Microsoft (Azure) hosts the server and the database, in West Europe (Netherlands), as our processor — under the Microsoft Products and Services Data Protection Addendum, edition 22 May 2026, which is incorporated into the Microsoft Customer Agreement our subscription is held under and which annexes the EU Standard Contractual Clauses. Microsoft's own sub-processors are named on its live Microsoft Online Services Subprocessor List — we link it rather than copy it, so it is never out of date here. They process on our documented instructions and for no purpose of their own, with written security assurances.
- Law. If we were ever legally compelled to produce data we would comply, and we would tell the affected parent unless forbidden to.
If that ever changes we will ask for fresh, separate consent first. We will not bundle it into a new version of this policy and rely on your having read it.
7. Our written data-retention policy
This section is our retention policy, published here as the law requires. We do not keep children's data indefinitely, and every row below has a purpose, a reason we need it that long, and a deletion date.
| Data | Why we need it at all | Why for that long | Deleted |
|---|---|---|---|
| Everything on the phone (§3.1) | The app cannot run a break without it | It is the app's own working state | When the parent clears it or uninstalls |
The app's own log (analytics) |
The parent's day view; supporting a reported fault | A parent looks back over weeks, not months; a support case is resolved long before | 180 days, then deleted automatically |
Learning and app-tracking record (learning) |
Progress across school years, surviving a change of phone | Its whole purpose is to be long-lived | On account deletion, or after 24 months with no contact from any of the account's devices, whichever is first |
Diagnostic trace (analytics, on request) |
Reproducing one specific reported fault | A fault is diagnosed in days | 30 days maximum, or 24 hours after consent is withdrawn |
| Consent records (§5.4) | Proving what a parent agreed to, and when | A claim about a child's data can be brought years after the account ends, and the record is the only proof of what was agreed | 7 years after the account is deleted, then deleted. From the moment of deletion the record holds the account id and the child id, and a keyed hash in place of the e-mail address and the names — proof of consent that spells nobody's name |
| Your child's first name and class, your account, its guardians and its devices | So the parent's page shows a name and not an id, and so the phone knows where it belongs | Only while the family is using BiteSize | On account deletion, or after 24 months with no contact from any device — the same clock as the learning record. On deletion the names and the address are replaced by the keyed hash of the consent-record row above, which goes with it after 7 years. We do not keep a child's name indefinitely |
| A row we could not read (a corrupted upload), held for inspection | To find out what went wrong | Long enough to look at it | 90 days |
| Parent account (§3.4) | Signing in | While the parent wants it | When the parent deletes it, or on the 24-month clock above |
Nothing is kept indefinitely — including your child's name. Every class in the table above has an end. If a family stops using BiteSize, everything goes on the same 24-month clock: the answers, the activity, and the child's first name and class with them. We email every guardian before that happens, once, in time to open the app and keep the record if you want it.
Two kinds of clock. Most rows are deleted by their own age — the activity log's 180 days is measured from each row, so the window rolls forward while your child keeps using the app, and the oldest days drop off. The learning record is different: it is meant to last across school years, so it ends by disuse instead — when you delete the account, or after 24 months with no contact from any of its devices. The table says which applies to each.
How we enforce it. Every row we store carries the date we created it. Each class above has its retention period configured, and a job runs nightly that deletes what is older, recording per class what it removed and to what cut-off date. So the periods above are something we can show, not something we assert.
8. Your rights
A parent may, for themselves and for each of their children: see what we hold, get a copy in a portable form, have it corrected, have it deleted, restrict or object to what we do with it, withdraw any consent (§5.5), and refuse further collection entirely. Use the controls in the app and on the parent website, or write to «TBD — privacy contact address (C2)».
We give every parent the same rights, in every country, rather than the shorter list their own law happens to require. We answer within 30 days.
Deleting is separate from ending consent. Stopping sharing stops what is sent; deleting erases what we hold. Each is one step, with your account's email address typed to confirm:
- One child, on the phone: Parents (behind your parent PIN) → Delete this child's data. The phone then starts its setup over.
- One child, on the parent website: the child's Settings page → Delete this child's data. The account and your other children stay.
- The whole family, on the parent website: the Account page → Delete everything.
It takes effect at once. For each child deleted, our server erases the identity, learning, activity and audit rows — the answers, the activity log, the phone's link to your account — including anything still in transit when the request arrives, and refuses anything further from that phone even if the phone has not yet been told. We confirm when it is done. The record of the consent itself is kept seven years, naming nobody (§5.4, §7).
9. Security
We maintain a written information-security programme for children's data, with a named coordinator (§1), a risk assessment at least once a year, and written security assurances from every third party that handles any of it (today: our hosting provider, §6).
Data is encrypted in transit and at rest. A device authenticates with a token, not a password, and a parent can revoke a lost phone so it stops syncing. Access to children's data by our own people is recorded — including reading an individual child's answers — and that log is available to the parent on request.
If data is ever breached we will tell the relevant authority within 72 hours of becoming aware, and tell affected parents without undue delay.
10. Where it is stored
In the European Union — West Europe (the Netherlands) — for every family in every country. We chose one region rather than following each family, because a single well-protected location is easier to secure and easier to explain than several.
Our own staff access it from Israel, which the European Commission recognises as providing an adequate level of data protection. If that recognition were ever withdrawn, we would put standard contractual clauses in place for that access; no data would move.
11. Children
BiteSize is built for children and used by them. We collect the minimum a learning break needs, we ask the parent before anything about a child leaves the child's phone, we ask separately for each purpose, we verify the parent the same strict way everywhere, and we never ask a child anything about themselves. See §14 for the specific statement that applies where you live.
12. Changes
If we change what we collect, why, or who sees it, we will say so in the app and on the website, and we will ask for consent again rather than treating silence as agreement. The version and date at the top always say which text is in force, and every previous version stays readable, so a consent record can be checked against the text that was actually on screen.
Languages. This policy exists in every language the BiteSize app does — today English and Hebrew — and the versions say the same thing. Neither governs over the other: if they ever disagree, the reading more favourable to you applies, and we fix the one that is wrong.
Where to read it. Inside the app, from the Parents tab, and on our website without installing anything. The app shows the version and date of what you are reading; if your phone is offline it may be showing a cached copy, and it says so.
13. Complaints
Write to us first: «TBD — privacy contact address (C2)». If we do not resolve it, see §14 for the authority where you live.
14. Where you live
Everything above applies to everyone. This is the only part that differs.
Israel
Data about minors is treated as specially sensitive under the Privacy Protection Law, and our processing rests on the guardian's consent. You have the right to inspect and correct data we hold about you or your child (§8 gives you more than that). Complaints: the Privacy Protection Authority, Ministry of Justice.
European Union / EEA
The lawful bases are in §4. Where a child is below the age of consent in their country — 13 to 16 depending on the country — the consent in §5 is the consent of the holder of parental responsibility; because we require a parent's consent for every child regardless of age, this is satisfied in every member state without our asking anyone's age. Your GDPR rights are in §8, and you may lodge a complaint with the supervisory authority of your member state or of the place of the alleged infringement. Our EU representative is named in §1. Transfers: §10.
United States
We do not knowingly collect personal information from a child under 13 without verifiable parental consent, obtained as described in §5.3. A parent may review the personal information we have collected from their child, refuse to permit its further collection or use, and require us to delete it — write to «TBD — privacy contact address (C2)» or use the parent website. Our written data-retention policy is §7 and our information-security programme is described in §9. We disclose children's personal information to no third party (§6), so no separate consent for disclosure is ever sought or needed. Complaints: the Federal Trade Commission, and your state Attorney General.