Privacy by default

A play link is not a student profile.

This page describes the current Math Garden starter release. Ordinary learner play is anonymous: no child account, name, email, birthdate, IEP information, disability label, chat, advertising identifier, or persistent learner profile is required.

Learner play

The server provides a published game configuration. Questions are generated and checked in the browser.

Answers, raw response text, attempts, hints, and the end-of-round summary are not sent to a Math Garden learner-progress service.
Refresh recovery uses per-tab browser storage for the published version seed and anonymous attempt markers. It excludes raw response text and is cleared when the round completes or a new practice starts; closing the tab or clearing site data also removes it.
Accessibility preferences are kept in browser storage under a non-identifying key. A teacher’s unsaved editor recovery copy can include teacher-authored content and is removed after a successful save; clearing site storage removes it at any time.

What the service stores

The current database is for adult authoring, released content, security controls, and operational history. It is not a learner record system.

Teacher account

The service stores an adult teacher email address, a password hash (never the plain-text password), role, and account timestamps.

Teacher-authored content

A game can include its title, unguessable share slug, selected template, math settings, lesson metadata, visibility, status, and created/updated/archive timestamps. Teachers should never enter a learner name, IEP information, disability label, or other sensitive learner detail in those fields.

Published versions and audit history

Published snapshots retain their title, configuration, version, content hash, publication time, publishing adult, and adult editorial actions such as validation, review, publication, rollback, duplication, and archive. Audit metadata is not a learner response record.

Unlisted links

Unlisted game API responses are marked private and no-store. They are still shareable by anyone who has the unguessable link, but the application does not place them in an intermediary cache or the public library.

Assignment links and class codes

A teacher may create a random-token assignment link pinned to a published game version, choose an expiry, and revoke it later. The teacher can also share a generated six-character code that opens the same pinned version from the student library. These records contain no learner name, response, or class roster, and code attempts are rate limited.

Security and hosting data

A signed, HTTP-only teacher cookie lasts up to eight hours. When a trusted proxy is enabled, sign-in rate limiting keeps a short-lived bucket keyed by a one-way digest of the configured client address; the raw address is not stored in that table. The hosting provider may also process ordinary request, error, and backup metadata; each deployment must set its own log and backup retention.

Retention in this release

There is no automatic database purge scheduler or self-service account deletion/export flow. Persistent teacher records therefore remain until a deployment administrator carries out an approved procedure. The repository includes guarded operator commands for adult-account export/deletion and a dry-run-first purge for expired assignment links and stale rate-limit buckets, but each deployment still needs an approved schedule, requester verification, access controls, and recovery handling. That is an open production readiness gate, not a promise to retain data indefinitely.

Teacher session cookie: expires after at most eight hours and is cleared by sign-out; it is not a server-side session row.
Rate-limit buckets: expire after their short sign-in window; production cleanup removes buckets older than one day on a best-effort background path. An approved operator may also use the dry-run-first purge command for an explicitly selected retention window.
Assignment links: expired or revoked links can be removed by the approved operator purge after the selected retention window. The purge does not remove audit events, authored content, teacher accounts, or learner/browser state.
Browser copies: learner recovery is per-tab and temporary; accessibility preferences may remain until site data is cleared; abandoned editor recovery may remain until it is saved or cleared.
Teacher content, versions, and audit events: retained until an approved operator lifecycle action or a district-approved schedule. Hosting logs and backups follow the deployment provider’s configured schedule.

Deletion and export

Browser data: a learner or teacher can clear this site’s storage in browser settings. Signing out clears the teacher session cookie.
Teacher account or game: there is no self-service delete or export button. Use the deployment owner’s published privacy contact to request a verified, operator-run action. The guarded deletion command requires an exact confirmation email, an explicit confirmation flag, and a production approval flag; it refuses unresolved cross-owner publication dependencies and deletes owned account data transactionally. Deleting a game by archiving it is not the same as hard deletion. Archive removes an unpinned game from discovery, while an existing pinned version link may continue to work.
Export: the current release has no learner export because it creates no server-side learner record. A production operator may run the guarded export command to create an approved structured export of an adult account’s content, immutable versions, assignment metadata, and editorial metadata. Password hashes and session secrets are excluded; the resulting file still requires secure handling under the deployment’s policy.

Contact, incidents, and legal review

Privacy contact: the deployment owner must publish a monitored email address or request URL before classroom use. This starter release does not provide a service-wide privacy inbox. Suspected incidents should follow the deployment’s incident-response runbook; do not send child information through a public issue tracker.

COPPA and FERPA obligations depend on the deployment, school relationship, data flows, authorization, and applicable law. Math Garden makes no COPPA or FERPA compliance claim. Before production use, complete district privacy, security, data-processing, retention/deletion, consent, administrator-access, and incident-contact review.