BiteSize — Privacy Policy (children's learning breaks)

DRAFT v0.19 · 2026-09-29 (policy 2.3, material — what we collect changed: every item shared with our server listed with its reason, and two named that were not: the phone's break time left (from app v0.78) and the parent browser's time zone — §3.3, §3.4, §3.6, §4, §5.2, §7) · 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.md LN-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.md LN-15).

Effective date: «TBD — effective date (C8)» · Policy version: 2.3 · 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:

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:

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.

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).

The time zone of your browser. When you open the BiteSize website, a small script on the page reads your browser's time-zone name — for example Europe/London — and puts it in a cookie called bs_tz. The cookie holds that name and nothing else, lives one year, and goes only to our own server; it is not an advertising or tracking cookie. When you are signed in, the server stores the name on your account, so that your child's days and week are counted in your family's local time and not in the server's. A week runs Sunday to Saturday in Israel's time zone and Monday to Sunday in any other. Until a browser has sent one, we count in Israel time (Asia/Jerusalem). We use the name for that and nothing else: we do not work out where you are from it, and we do not show it to anyone. Deleting your account deletes it (§7). Details in §3.6.

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. The one thing near it is the parent browser's time-zone name in §3.4, which is used to count days and is not turned into a place.
• 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.

3.6 Every item that reaches our server: why, when, how long, who sees it

All of it is stored in our server's database in West Europe (§10). Kept points at §7, which is the retention policy itself. Who sees it is the signed-in parent, on their own pages, unless a row says more; our own staff reach the database only as §9 describes, and Microsoft hosts it as §6 describes. Nothing here goes to anyone else (§6).

The consent records, the parent's account and the app's own log (analytics) are described in §5.4, §3.4 and §3.3, and their retention in §7.

4. Why we use it, and on what 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.

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:

1. 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.
2. They read the notice on the child's phone — what is sent, what is never sent, why — before any switch is offered.
3. 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.
4. 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.
5. 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 decision — a grant, a refusal, a withdrawal — is recorded the moment it is made. That is how we can show later that consent existed, and how a parent can read the exact words they agreed to.

What the record holds, and nothing more: which consent (learning or analytics); the exact texts on screen — this policy and the consent notice, each by version and language; the decision (given or not); how it was given (on the phone, by our support staff, or ended by a change of this policy); when; and the app and configuration versions in force.

What it never holds: your e-mail address, your name, your child's name, the id we give your child, or anything about a phone. In their place it holds two codes: one made from your e-mail address (trimmed and lower-cased) and one from your child's id, each computed with HMAC-SHA-256 under a secret key. Without the key, nobody can turn a code back into an address or a child, or link it to a person.

The key is kept apart. It lives in a separate key vault (Azure Key Vault), never in the database; only our server reads it, once when it starts. It is never changed, so a code made today still matches in seven years. This makes the record pseudonymised data in the sense of GDPR Art. 4(5) — not anonymous: we, holding the key, can still check a code.

How a record is checked. When a consent must be proved — to you, to a supervisory authority, or in a legal dispute — we take the e-mail address and the child's id put to us, compute their codes with our key, and look for records carrying them. A match shows what was agreed to, under which texts and when; no match shows there is no record. Nobody can search the records by name.

Nobody can change it. Only our database writes the record, at the moment of the decision. Nobody can edit or delete it afterwards, our own staff included. The one thing ever added is the date the child was deleted.

It outlives a delete, for 7 years. While your child is with us, the record stays with them. When you delete the child or the account, everything else about the child is deleted (§8); the record stays, still naming nobody, so that we can show the consent was obtained lawfully and answer a claim about it. It is deleted automatically 7 years after the child's delete (§7).

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.

Three necessary exceptions, none 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.
• Android's own push service (Google Firebase Cloud Messaging). It is part of the Android system already on the phone (Google Play services), not a party we bring in: no third party outside the Android ecosystem is involved, anywhere. Once a phone is paired and you have accepted learning, the app registers an app-instance token with it, and our server uses that token for one thing — an empty "check in now" signal, so a Break now you press reaches the phone in seconds. The signal carries no name, no answer, no app and no command; the command itself travels only between the phone and our server. Google sees the token and the delivery metadata any Android push has. The token is deleted with the child.
• App icons from Google Play. To show an app's icon next to its name on the parent's page, our server asks Google Play for that app's public store icon, by package name only — no child id, no device id, no account, nothing about who has the app. Google sees our server asking for an app's icon, as it would for any visitor to that store page. The icon is kept once per app, not per child.
• 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. Every row below has a purpose, a reason we need it that long, and either a deletion date or the reason it has none.

What we keep with no end date, and why. Two things, and neither names a child or a parent. The key of a phone we erased: a one-way code made from that phone's own security token, so a phone we can no longer reach is told its child is gone and wipes itself. Our own service log: the rows saying what the service did — a consent recorded, a purge run, an account deleted — as counts and versions, never a name, an address or a child.

Two clocks. Only two things are deleted by age: the app's own log, 30 days after each row, and the consent record, 7 years after the child's delete. Every row we store carries the date we created it, and a job runs once a day that deletes the rows past their period and records how many it removed. Nothing else is deleted automatically.

Server logs. Our hosting platform's request log (Application Insights) keeps one line per request to our server — the route, the result, how long it took and which phone or account made it — for the platform's default period.

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 deletes, in one step, every row it holds about the child — the name, the answers and the learning record, the app's own 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 only once a check finds nothing left; if the delete fails, nothing is deleted and we say so.

What a delete keeps: the consent record. It stays for 7 years, holding neither your e-mail address, nor any name, nor your child's id — only the two keyed codes (§5.4, §7). The law lets us keep it to show the consent was given and for legal claims (GDPR Art. 17(3)(b) and (e)).

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.