Privacy Impact Assessment
Mr. Aube and Friends — Learner Profiles & Progress (local-first architecture) · Version 1.6 · September 26, 2026 · Published in line with the October 8, 2025 joint resolution of Canada's privacy commissioners on educational technology · Plain-language policy
1. Purpose and scope
Mr. Aube and Friends is a membership website made by a New Brunswick elementary teacher. It offers Grade 2 math games, interactive strategy tools, printable practice sheets, and classroom board widgets. This assessment covers the learner profiles and progress system introduced in June 2026 — per-child profiles, a “who's playing?” picker, per-learner progress views, printable summaries, and the classroom roster features it links to — together with the pre-existing account and billing system it sits beside.
The central design decision under assessment: all data about children is stored exclusively on the user's own device (browser IndexedDB/localStorage) and is never transmitted to, or held by, the operator.
One adjacent, adult-owned store is in scope because teachers use it in the classroom: board layouts and widget settings sync to the teacher's own account so a board opens on another device. That record is authored by the teacher, not by or about a child — class rosters, status assignments and whiteboard strokes stay on the device — but a free-text widget could hold anything a teacher types, so it is inventoried in §2, and the privacy policy tells teachers to keep student names out of widget text.
2. Data inventory
| Data | Elements | Where it lives | Why | Retention |
|---|---|---|---|---|
| Child: learner profile | First name, optional last initial, cartoon avatar choice, optional school grade (K–5), created/updated timestamps, random local ID | User's device only (browser IndexedDB) | Let a family or class see per-child progress, framed against the right grade's curriculum | Until the user deletes it or clears browser storage; export and full delete available in-app |
| Child: game play history | Game played, timestamps, duration, in-game events (e.g. question “7+5” answered correctly), local profile ID, seat tags for two-player games | User's device only (browser IndexedDB); the newest 200 sessions per learner and 100 unattributed sessions are kept, up to 1500 on the device | Progress views, practice suggestions, printable summary | Rolling per-learner cap (200 each, 100 unattributed, 1500 device-wide); deletable per learner in-app |
| Child: class rosters & board activity | Student first names + optional initials in teacher-made rosters; whiteboard strokes; status-board assignments; name-picker history | Teacher's device only (browser IndexedDB/localStorage) — a synced board stores only the roster's local ID, never its names | Classroom board widgets (name picker, groups, status row) | Until the teacher deletes them or clears browser storage |
| Teacher: board layouts & widget settings | Board name; which widgets are placed, their position and size; each widget's settings — including free text typed into a Text widget, Spinner wedge labels, status-symbol labels, and QR-code URLs and labels | Operator's database (Azure Cosmos DB, Canada East region), under the teacher's account; each device that opens a board also keeps an offline copy in its own browser, under a key namespaced to that account | So a board built on one device opens on the same account on another | Until the teacher deletes the board or the account |
| Adult: account | Name, email, the profile picture supplied by the sign-in provider, OAuth provider and account ID, role, timestamps | Operator's database (Azure Cosmos DB, Canada East region) | Sign-in and access control | Life of the account; deleted on request |
| Adult: billing | Stripe customer/subscription IDs, subscription status, redeemed access codes. Card details go to Stripe directly and are never seen by the operator | Operator's database (Canada East) + Stripe | Memberships and promotional access | Life of the account / Stripe's regulatory retention |
| Adult: feedback & teacher-code requests | In-product feedback: adult email, account role, the page and page title, viewport, browser user-agent, and the message. Teacher-code request: teacher name, school, school email, class size, and the message. The message is free text: nothing about a child is requested and none is attached automatically, but an adult could type a child's name into it — see the risk row in §6 | Filed as a private issue in the operator's development tracker at GitHub (United States); not stored in the operator's own database | Triage of bug reports and approval of classroom access codes | Life of the issue; closed issues are deleted on request |
| Technical logs | Platform logs and structured server-failure codes (Azure Container Apps); no browser error collector or session recording | Azure, Canada East | Service operation and security | 30 days; operational only |
Deliberately absent: child accounts, birthdays, photos, genders, school names, free-text notes about children in learner profiles or rosters, advertising identifiers, analytics SDKs (the codebase contains none), cross-device identifiers, and any server-side record of gameplay.
3. Data flows
What crosses the network: adult sign-in (to Google or Microsoft and back), billing (to Stripe), ordinary content delivery (the games and pages themselves), the teacher's own board layout and widget settings (to the operator's database), and — only when an adult submits one — a feedback note or teacher-code request (to GitHub). Game content is served to signed-in members; serving a game involves no child-specific data.
One further outbound request is automatic and is called out here because §5 claims no third-party calls: the four adult-facing strategy pages embed Mr. Aube's own teaching videos from YouTube, served in YouTube's privacy-enhanced no-cookie mode (youtube-nocookie.com). Loading one of those four pages therefore contacts Google. This is the only automatically-loaded third-party subresource anywhere in the product: no game, interactive tool, worksheet, classroom board, member-area page — or the strategies index itself, whose video thumbnails are served from our own origin — loads anything from a third party, and no child-facing surface contains an embed. The player embed is expected to stay.
What never crosses the network: learner profiles, rosters, and play history. Games run inside the page and report events (e.g. “answer correct”) to the surrounding page, which writes them to the browser's own storage. There is no endpoint on the server that accepts a learner profile, a roster, or a play-history record — the no-transmission property is architectural, not a policy choice that could silently drift. The board endpoint accepts only the teacher's layout and widget settings, and rosters are referenced there by local ID alone. Telemetry payloads are forbidden by protocol from containing student names; profiles attach to sessions only as random local IDs, on the device.
A practical consequence we communicate honestly in-product: progress does not sync between devices, and clearing browser data deletes it. Families can export a learner's history to a file themselves.
4. Legal analysis
PIPEDA (operator). The operator collects, uses, and discloses personal information only for adult accounts and billing, described above — that activity remains fully within PIPEDA's scope and is handled with minimal collection, Canadian data residency for the operator's own store, and no secondary use. Children's information is not collected by the operator at all: it is created and held by the parent or teacher on their own device. The strongest protection PIPEDA contemplates — not collecting — is the default and only mode in this release.
Parental consent for children under 13. The Office of the Privacy Commissioner's settled position is that consent for children under 13 must come from parents or guardians. This release is designed so the question of a child consenting to vendor collection never arises: there is no vendor collection. Any future cloud-sync feature will be opt-in, gated on express parental consent, preceded by legal review, and reflected in an updated version of this assessment before launch.
New Brunswick schools (RTIPPA / district review). Teachers and districts are bound by RTIPPA when student personal information is used or disclosed. With this product, classroom use of rosters and learner profiles does not disclose student personal information to the vendor — names never leave the teacher's device, and the vendor holds no student records. This document is published partly to make district privacy review straightforward; we will gladly answer district information-security questionnaires.
5. Alignment with the 2025 commissioners' resolution
| Expectation (Oct 2025 resolution) | How this product meets it |
|---|---|
| Most privacy-protective settings by default | The most protective setting — no collection of children's data — is the only mode. Nothing to configure, nothing to opt out of. |
| Data minimization; necessary and proportionate | Child profiles are first name + initial + cartoon avatar, full stop. Play history is capped on-device — 200 sessions per learner, 100 unattributed, 1500 in all — and older sessions are pruned automatically. Adult records hold only what sign-in and billing require. |
| No tracking of children | No analytics or tracking code exists anywhere in the product; games, tools, worksheets and the member area contain no third-party calls; no behavioural profiles are built. The one automatic third-party request in the product is the YouTube video embed on the four adult-facing strategy pages (§3), which no child-facing surface carries. |
| No manipulative / deceptive design | Child-facing surfaces contain no upsells, no locked-content teasers, no loss-based streaks, no decaying scores, no social comparison, and no guilt mechanics. The public classroom tools count only what a learner has solved: a wrong answer never takes a count away, and no 'best score' is kept between visits. The child-visible progress surface is celebration-only ('I can…' statements and earned trophies); evaluative data appears only on adult-facing views, framed around evidence rather than grades. |
| No secondary use of student data (marketing, product improvement, AI training) | Structurally impossible for children's data — the operator never receives it. The operator also commits to no AI-training use of any user data. |
| Clear, child-comprehensible communication | The picker speaks at a child's level ('Who's playing today?'); privacy notes appear in plain language on every relevant surface ('stays on this device'); the policy is written in plain language. |
| Conduct and publish privacy impact assessments | This document, published at a stable public URL and versioned. |
6. Risks and mitigations
| Risk | Assessment | Mitigation |
|---|---|---|
| Someone else using the same device/browser profile can view learner data | Most realistic exposure; impact limited by design (first name + initial + play history only) | Radical data minimization is the control (first name + optional initial, no contact details); per-learner delete is one click and removes the only copy. Shipped with v1.3: the Learners page carries a “Sharing a computer?” note saying in plain words that profiles live in this browser rather than in the account — so anyone who signs in here sees them, and signing out leaves them — alongside a one-click “clear this device’s learner data” control that erases every local store (profiles, play history, term baselines, trophies, rosters, status assignments, whiteboard drawings) and the who’s-playing choices. Shipped with v1.4: the board’s offline cache is namespaced by account (`mr-aube-board:<userId>:<boardId>`, previously `mr-aube-board:<boardId>`), so on a shared staff-room computer the second teacher to open a board no longer reads the first teacher’s cached copy of it — free-text widget content included — and a pre-namespace cache is migrated into the account that opens it once, with the old key deleted in the same step so a third account cannot inherit it |
| Device loss or theft | Same limited data exposure as above; no credentials or contact data in the learner store | Data minimization is the control: nothing in a learner record identifies a child beyond first name + initial |
| Data loss (browser storage cleared, device replaced, storage eviction) | Availability risk, not a confidentiality risk — and the honest cost of local-first | Clear in-product messaging; per-learner JSON export for family-controlled backup |
| Mis-attribution (session assigned to the wrong child) | Low impact; data stays within the same household/classroom device | Retroactive re-assignment controls on the Progress page |
| Scope drift in future releases (e.g. cloud sync quietly added) | The key long-term risk for any local-first promise | Public commitment: sync ships only as express parental opt-in after legal review and a republished PIA; the privacy policy promises express consent before any weakening |
| Third-party processors (Google/Microsoft sign-in, Stripe, GitHub, and YouTube for the strategy-page video embeds) handle adult data | Standard processor risk, adult data only. GitHub is in the United States and receives an adult's email, and for a teacher-code request their name, school and message | Reputable processors under their own compliance regimes; operator never stores card data, only processor reference IDs; feedback and code-request submissions are adult-initiated and disclosed in the policy — the teacher-code form names GitHub, the in-product feedback form does not yet — and nothing about a child is attached to either automatically |
| Embedded YouTube videos on the four adult-facing strategy pages contact Google when the page loads | The only automatically-loaded third-party subresource in the product. Marketing pages for adults; no game, tool, worksheet, board or member-area surface loads anything from a third party. Google can observe that a browser loaded the player, with the IP address and user-agent any request carries | The player uses youtube-nocookie.com, YouTube's privacy-enhanced mode, which sets no tracking cookie unless the visitor presses play, and nothing loads it until an adult opens one of the four pages; the strategies index that links to them serves its video thumbnails from our own origin. An automated third-party-reference test over every shipped file keeps this embed the only exception |
| An adult types something about a child into a free-text feedback or teacher-code message, which is filed at GitHub | Adult-initiated and requires a deliberate act; nothing in the form asks for it and nothing about a child is attached automatically | The privacy policy asks adults not to include a child's name or details, and the feedback form itself now carries that line under the message box, naming GitHub and linking the policy; the message is forwarded verbatim to a private issue and nothing is stored in the operator's own database; issues are deleted on request |
| A teacher types a student's name into a free-text board widget (Text, Spinner, status label, QR label), which syncs to the operator's database | The one path by which a student name could reach the operator. Requires a deliberate act by the teacher; nothing in the product asks for it | Roster-backed widgets (name picker, group maker, status row) keep names on the device and are the documented way to use names; the product and the policy both say so — each free-text widget shows the line “Saved to your account, not just this device — keep student names in a roster instead” beside its input, and the privacy policy tells teachers the same thing; the synced record is deletable with the board |
7. Conclusion
The learner-profiles release adds meaningful educational value — per-child progress, curriculum-aligned insight, and conference-ready summaries — while keeping the operator's holdings of children's personal information at zero. Residual risks concentrate on the physical device and shared-device use, are inherent to any on-device data, and are mitigated by radical data minimization. We assess the residual privacy risk as low, and materially lower than conventional cloud-based progress tracking.
8. Revision history
- v1.6 (September 26, 2026): mraube.ca becomes the first-party public domain, served by the existing Azure application. Cloudflare provides DNS only; visitor web traffic goes directly to Azure. No new tracker, third-party browser resource, collection or child-data transfer is introduced. The original Azure hostname remains available because browser storage is isolated by origin. Existing learner records stay at the old origin unless the adult exports and imports a device backup; there is no automatic migration or upload. The privacy scanner permits the exact new origin only in the canonical-origin definition and sitemap, retaining all other restrictions.
- v1.5 (September 6, 2026): documents the existing 30-day Azure technical-log retention and the new server-only structured failure codes. These reports omit request contents, concrete URLs, account identifiers, error messages and stacks. No browser error collection, session recording, new browser request or change to local learner data flows.
- v1.4 (September 6, 2026): two shared-device mitigations shipped and are credited in §6; no change to what is collected or where it goes. (1) The board's on-device cache is now namespaced by account — the localStorage key is `mr-aube-board:<userId>:<boardId>` where it used to be `mr-aube-board:<boardId>`, so on a staff-room computer the second teacher to open a board no longer reads the first teacher's cached copy of it, free-text widget content included. A cache written before the change is migrated into the account that opens it once and the pre-namespace key is deleted in the same step, so it cannot be adopted a second time by a different account. (2) Account export and deletion are self-serve at Settings → Your data, calling `GET /api/account/export` and `POST /api/account/delete`; “contact us” is now the alternative rather than the only route. Deletion refuses while a subscription is live unless the request also asks for it to be cancelled, so no plan ends by accident and no billed account is deleted out from under its payer. The plain-language policy gains a matching “Shared computers” section and is re-dated the same day.
- v1.3 (September 5, 2026): one correction, no change to collection or flows. The play-history retention figure still quoted the old device-wide cap of 300, which the product stopped using: pruning is per learner, keeping the newest 200 sessions for each named learner and the newest 100 unattributed ones, with an absolute device ceiling of 1500 sessions so a class roster cannot fill the browser's storage quota. §2 and §5 now state the shipped rule, and an automated test reads these three numbers back out of this page against the code so the figure cannot drift again. The shared-computer guidance v1.2 said was planned has now shipped: the Learners page explains that profiles live in the browser rather than the account, and a control there clears every local store on the device. §6 is updated accordingly.
- v1.2 (September 5, 2026): four corrections, no new collection. (1) Classroom board layouts and widget settings — including any text typed into Text, Spinner, status-row label and QR-code widgets — sync to the teacher's account in Cosmos DB (Canada East) so a board opens on another device; they were previously described as device-only. Class rosters, status assignments and whiteboard strokes remain device-only. (2) GitHub (United States) is named as a processor for in-product feedback and teacher-code requests. (3) The YouTube video embeds on the four adult-facing strategy pages — the product's only automatically-loaded third-party subresource — are now named in §3 and §6; the strategies index, which used to hot-link YouTube's thumbnail images, now serves those four pictures from our own origin, so nothing but the embedded player reaches a third party. (4) v1.1 credited the product with in-product shared-computer guidance that has not in fact shipped; the mitigation in §6 now says so. The account record does still retain the profile picture the sign-in provider supplies, exactly as v1.1 described: a draft of this revision claimed it had been dropped, which was wrong, and the claim was removed before publication rather than shipped ahead of the code. Two in-product notices ship alongside this revision and are credited in §6 accordingly: the feedback form now carries the “don't include a child's name” line and names GitHub, and each free-text board widget says its text is saved to the teacher's account.
- v1.1 (June 10, 2026): added an optional school grade (K–5) to the local learner profile so progress can be framed against the right grade's curriculum. No change to data flows — the profile remains device-only and is never transmitted.
- v1.0 (June 10, 2026): initial publication with the learner-profiles release.
9. Accountability and review
This assessment is maintained by the operator of Mr. Aube and Friends, reviewed at every feature release that touches personal information, and republished with a version bump when anything in it changes. Next scheduled review: before any cloud-sync feature ships, and no later than January 31, 2027. Contact: privacy@zaiphr.ai (district information-security questionnaires welcome), or via the Mr. Aube and Friends Facebook page.