Privacy Policy

Last updated: 17 August 2026

1. Who this is for

This is a mixed audience application, built for tutors, teachers and students. It is not directed primarily at children.

Signing in with a Google Account is strictly optional, and every feature works without it. That matters beyond convenience: Google's API Services policy prohibits applications directed primarily at children from using Google Sign-In, and the optional-account architecture is what keeps this app correctly positioned as mixed audience.

If you are a student under 13, you do not need an account and should not create one. Nothing about taking part in a lesson requires you to sign in.

2. What stays on your device

By default, this is everything:

Deleting a quiz keeps a copy on your device for a little while, so that deleting the wrong one is not permanent. When you delete a quiz, the app holds a copy — its questions, its title, and where it sat — and offers to put it back from a line under your shelves. It exists because the alternative is a one-click action with no way back.

Three things about it, plainly:

• It never leaves the device. No network path, no server table, and it is not part of cloud sync even when sync is on. A deletion you made is a deletion everywhere; only the local copy remains, and only here.
• It is small and it forgets. The last 10 deleted quizzes, and fewer if they are large — there is a size ceiling too, and the oldest drops off first. It is an undo buffer, not an archive.
• You can empty it whenever you like. "Recently deleted" → Forget these, or MasterBank.forgetRecovery() in the console. Putting a quiz back also removes its copy. Nothing here survives clearing your browser storage.

There is deliberately no timer. A copy is not deleted on a day nobody chose; it is displaced when you delete more, or removed when you say so. That is the same bargain the annotation ring buffer makes, and it puts the decision with the person who made the deletion.

Group Jam results a teacher saves stay on the teacher's device. During a live Group Jam session, each student's score reaches the host's device directly over the peer-to-peer connection — that is how the game works, and our server is never in that path. When the session was launched from a class roster, the host can press "Save results" on the results screen. That is the only way a session's results persist, and what is kept is deliberately reduced: each student's total score, correct/incorrect counts, accuracy, a per-topic summary, and who was absent. The per-question answer log is discarded at the moment of saving and is never stored. Saved results live in the teacher's own browser storage, are never uploaded, have no table on our server, and are deletable one session at a time, per class, or by deleting the class. They are labelled — in the app and in any exported spreadsheet — as practice results reported by each student's own device, not invigilated grades. A session not launched from a class roster cannot be saved at all.

Assigned practice stays on your device until a lesson is already running. A teacher can hand out a link that carries a set of questions plus two study preferences — guided pathway and spaced review — and a due date. That link travels from teacher to student and contains no information about any student: no name, no class identifier, no roster entry, no teacher identity.

When you complete assigned practice, the result is written to your own browser storage and nowhere else. It is not uploaded, it has no table on our server, and it is not sent anywhere at the moment you finish. It waits. The next time you join that teacher's live session, it is handed over the same direct peer-to-peer connection the session already uses — so no new connection, no account, and no server are involved at any point. If you never join another session, it simply stays on your device and nothing is ever sent.

What is kept and handed over is the same reduced summary a live session produces: totals, correct and incorrect counts, accuracy, and a per-topic summary. The per-question answer log is discarded when the result is recorded and is never stored or sent. Results waiting to be handed in are visible to you in the app, and clearing this site's data removes them.

A diagnostic sends less about you than it knows. A skills check works out which topics you can already do, which one you are ready for next, and which are still out of reach. That full picture stays on your device. What is handed to your teacher is deliberately narrower: the topics you are ready to learn next, by name, because that is what a teacher acts on; counts only for how many topics you have already mastered and how many the check could not settle — numbers, never a list of names; and how many questions the check used, with the note explaining that the result is a position within your teacher's own material and not a grade level.

The list of topics you cannot do yet is never sent. It is the largest part of the result and it is the part a teacher cannot act on, so it stays on your device. The record of which individual questions you were asked, and how you answered them, is discarded when the result is recorded — exactly as for ordinary assigned practice. Diagnostic results travel by the same route and only by it: they wait on your device, and are handed over the direct connection the next live session already opens. Nothing is uploaded, and there is no table for them on our server.

On the teacher's side, a returned result is stored with that class's records at the moment it arrives — the deliberate acts here are assigning the work and opening a session for the class, so the hand-in completes without a further click, and the student's device is told it arrived so it can stop holding a copy. A session with no class attached refuses hand-ins entirely, and the work simply stays on the student's device. What the teacher's device stores is the same reduced summary, attributed to the class-register entry the student's typed name matched (or held under the typed name, visibly, when nothing matched — the app never guesses). It stays on the teacher's device until deleted — per assignment, or with the class — is never uploaded, and is labelled as self-reported practice in the app and in any exported spreadsheet, exactly like live session results.

"Your browser's local storage" means localStorage, and — once a profile approaches what localStorage allows — IndexedDB in the same browser. Both live only on your device: moving data between them changes which drawer it sits in, never whether it leaves the machine. The app also keeps a verified backup copy of your content in IndexedDB as protection against running out of space. Quota problems are reported on screen, to you, and nowhere else.

There is no telemetry, no analytics service, no crash reporter and no background upload. Signed out, this app never sends your content to a server The app counts a few things about itself, on your device, and sends none of them. Two small tallies exist so the people building this can tell a confusing first five minutes apart from a broken one: how far a new user got (opened it, looked for content, added content, ran a quiz) as counts and dates — never a record of what you added or teach — and whether live sessions actually connect. Both live in local storage and have no network path at all: no endpoint, no request, no identifier, no beacon, and no opt-out to forget to use, because there is nothing to opt out of. They are not analytics; an analytics system reports somewhere, and these have nowhere to report to. If you want to tell us how you got on, run Activation.report() in your browser console and read the result — it prints plain text, and you decide whether to send it..

3. What reaches our server, and only when

Our server receives data in exactly five situations, all of them optional.

When you sign in with Google

We store, for the account holder only: an opaque Google subject identifier, your email address, and your display name and chosen handle. We never receive your password, and we request no access to Gmail, Drive, Calendar, Contacts or any other Google service.

Sessions are stored as a hash of a random token, never the token itself, so a database disclosure does not hand anyone a working login. Sessions expire after 30 days.

When you turn on sync

Signed in and syncing, three kinds of content are uploaded so they reach your other devices: your whiteboards, your quiz libraries — the quizzes you have written or imported, their topic structure, and the order you have arranged them in — and your own practice score lines, described below. The first two also carry merge bookkeeping: per-item edit timestamps and a random per-device identifier, which is how two of your devices that both edited offline combine their changes without losing either side's work. The identifier is random characters with no connection to your account, your hardware, or you. The server stores all of it as opaque text and does not read the content of it — with one precise exception. When two of your devices edit the same library while offline, the server resolves the collision, so the outcome is the same whichever device syncs first. To do that it works with the structure of your library and its merge bookkeeping: which quiz and question entries exist (their identifiers), their order, and which side's edit timestamp is newer. The content of your questions — the text, the choices, the answers, anything you typed — is copied through as opaque units the server never parses, compares, or logs; an automated test fails our build if the merge code ever names a content field, or if replacing every piece of content could change any merge decision. The overwritten side of a collision is returned once to the device that synced, for its local restore list, and is kept nowhere on the server. Whiteboards are not merged this way; they remain fully opaque.

How often your device talks to the server, and what it says when it does. Syncing happens on its own: when the app opens, when you sign in, a few seconds after you change something, when you return to the tab, and — while the app is left open — on a timer you control, set to every 15 minutes by default. That timer only asks. It uploads nothing: it sends an empty list and the question "has anything changed since last time", and on the ordinary answer of "no" it receives an empty reply. Your content still goes up when you actually change something, which is the moment it should. The timer pauses while the tab is in the background, and can be set to 5 minutes, an hour, or off entirely in Settings → Sync. It carries no content of yours.

You can turn each kind off separately. Settings → Sync has a switch for libraries, for whiteboards, and for your own score lines. Your account mode sets the starting position of each, and a switch you change yourself overrides it — including turning something back on that your mode had off, in which case the app says so at the moment you do it rather than afterwards. Turning one off stops that kind of content leaving from then on; it does not by itself remove what is already on the server, which you can do at any time by deleting the content or the account.

K-12 classroom mode narrows this in code, not just in settings. With the mode on: whiteboards and practice score lines are not uploaded at all, short share links cannot be created (received links still open), and AI features run only on-device — no text reaches a hosted model. The one content path that remains is your own quiz libraries, with the warning above unchanged. These limits are enforced at the code paths themselves and asserted by automated tests on every build.

Your own practice history — a score line, and only yours. A quiz you took while signed in to this account syncs as a score line: which library and quiz, the quiz title, when you took it, and how many you got right, wrong and in total. That is the entire row. It exists so your own practice on a laptop shows up on your desktop.

What makes an attempt eligible is decided before anything is sent, and the rules are deliberately strict:

• An attempt syncs only if it carries the id of the account signed in right now.
• An attempt recorded while signed out, or before this feature existed, carries no such stamp and is never sent — not now, and not after a later sign-in. Unattributable history is treated as though it might be a student's, because on a tutor's laptop it might be. There is no backfill and no "claim these as mine" prompt: both amount to asking someone to vouch for records they cannot actually check, and a wrong answer would upload a child's performance record.
• Attempts from a Group Jam seat, a student portal session or a class register do not travel this path at all.
• If two people have used the same device, neither one's attempts are sent under the other's account.

There is no column on the server for a name, a per-question answer or a missed-question list, so no fault in the app can put one there.

What sync still never uploads. Which questions were missed, per-question answers, per-topic accuracy, item statistics, class registers, tutoring client records and session notes are not uploaded and have no table on the server. Anyone's results but your own stay on the device, in full. Syncing the questions is what makes a second device useful; the item-level record of how an identifiable learner performed is the most sensitive thing this app holds, and it stays where it was made.

When you create a short share link

Share links normally send nothing anywhere. A share link carries the quiz itself, compressed into the part of the web address after the # — and browsers never transmit that part to any server. Sharing a quiz that way is between you and the person you send it to, and it stays the default.

That breaks down for a large pack. A quiz with pasted diagrams produces a very long address, and mail clients wrap long addresses while course sites truncate them, so the link arrives broken. For those, you can choose to create a short link instead.

This is opt-in, one share at a time. Nothing is uploaded automatically because a pack got big. The long link is always built first and always offered; the short link is a separate button, shown only when the long one is at risk, next to a description of what it does. You must be signed in.

• What is uploaded: the quiz content — questions, answer options, explanations, hints, and any images pasted into questions. It is stored compressed, and the server does not read or interpret it.
• What is not: no scores, no attempt history, nothing about a student, and nothing identifying whoever opens the link.
• Anyone with the code can open it. There is no sign-in on the reading side, deliberately — the person you are sharing with may not have an account. The ten-character code is the secret, and it is random.
• It expires after 30 days, automatically. You can revoke it sooner from the same panel, and deleting your account deletes every short link you have made straight away.

When you start a live session

Live tutoring is peer-to-peer. Ink, everything drawn during a session, and any quiz the participants share or edit together travels directly between browsers and never passes through our server. Shared editing of a quiz is off until the quiz's owner offers it and the other person explicitly accepts; accepting saves a copy of that quiz on the accepting device, which its owner keeps and can delete like anything else stored locally. Annotations from a session are saved on both devices, and that changed on 14 August 2026: the drawings kept with a saved attempt now include the other person's, so a student keeps the tutor's worked explanation for the question it was drawn on and a tutor keeps the student's working. They do not sync, ever — these drawings are held in local storage, and turning sync on does not upload them; the one way they can leave the device is inside a lesson summary you deliberately send, as a file or as an encrypted link whose key we never receive (below). They are not labelled with who drew them: the record of which participant made which stroke is deliberately discarded when the attempt is saved, and kept only while the session is live so the app can show you who is drawing. You can delete them like anything else stored locally. A lesson you never finish is saved too, from a few seconds after you start drawing on it — since 15 August 2026 — it used to be discarded unless you reached the results screen, which lost a whole lesson of annotation for anyone whose session simply ended, and that is what a tutoring hour normally does. It is saved while you work, not when you leave: the moments a browser gives an app on the way out are too short to compress a lesson of drawings, so waiting for one would mean losing the work of anyone whose tab was closed, crashed, or discarded by the browser. One record is kept per quiz and refreshed as you go. The same rules apply to it as to any other saved attempt, and it counts against the same bounded archive; finishing the quiz replaces it, so one lesson leaves one record. Reopening a saved attempt does not re-share it: drawings restored from your archive are shown to you and held back from anyone who joins a later session, because the app can no longer tell which of them were yours. Showing restored work to somebody takes a deliberate action. A saved attempt can become a lesson summary PDF: the summary — the score (or how far an unfinished session got), the questions to revisit, what to practise, and the worked pages — is composed entirely on your device and saved as a file there. Creating one sends nothing to any server; sending the file — an email to your student, a print-out — is between you and them, through tools of your own choosing. If you would rather send a link, the next section describes the one way a lesson summary can touch our server: encrypted on your device first, with a key we never receive. Because saved drawings are not labelled with who drew them, the summary shows the lesson's working without saying who wrote which stroke. What the server holds briefly is the connection handshake: a short room code, WebRTC connection descriptors, the host's display name, and — in a group room — the name each student types when joining.

Student names entered to join a room are limited to 40 characters and are automatically deleted 30 minutes after the room is created by an expiry sweep on the server. They exist only so a host can tell participants apart during the lesson. Students can join with an initial or a nickname; nothing verifies or requires a real name.

When you send a lesson summary as a secure link

A lesson summary is composed on your device and saved as a file — that stays true and stays the default, forever. If you are signed in, you can additionally send one as a secure link. Because the summary's worked pages can contain a student's handwriting, this is the one place student work can touch our server — so it is engineered to arrive unreadable. It is encrypted before it leaves: the PDF is encrypted on your device with AES-256-GCM, using your browser's built-in WebCrypto, before anything is sent; what our server stores is ciphertext. We never hold the key: the decryption key is placed in the link itself, after the # — the URL fragment — and a fragment is never transmitted to any server by any browser. When your student opens the link, their browser fetches the encrypted copy and decrypts it locally, on their device. We cannot read what we store, and there is nothing we could be compelled to hand over that would change that: we hold ciphertext and no key. It is opt-in, one record at a time: creating a summary uploads nothing, and the link is a second, separate step behind a confirmation that says all of this. It expires after 7 days, automatically — deliberately shorter than share links, because this is a lesson handout in transit, not an archive; you can revoke it sooner from Attempt history, and deleting your account deletes every lesson link immediately. Anyone with the full link can open it — the link carries both the lookup code and the key, so treat the link the way you would treat the file itself and send it directly to your student. What is stored in clear is the quiz title, so your own revoke list is readable, and the timestamps; there is no field for a student's name. K-12 classroom mode does not create these links at all — the same code-level switch that blocks pack short-links blocks this, encrypted or not.

4. AI features, and what leaves the device when you use them

Two features use an AI model: generating questions, and writing a study guide from a whiteboard. Both can be run from the text on a board, and both are the only features that send your content to a company other than us, so they get their own section.

You choose the backend, and the choice decides where the text goes:

Three things follow from that:

• Nothing routes through our server. The request goes from your browser to the model provider. We never see the prompt or the answer.
• With your own key it is your account and your agreement with Anthropic or Google that governs how they handle the text — not ours.
• Question generation shows you the prompt before sending it. The extracted board text is loaded into an editable box first. Read it, and delete anything you would not hand to a third party.
• The study guide has no editing step, because it summarises the board as a whole. It names the provider in the dialog before it runs, and prefers the on-device model automatically when that is the working backend.

The brand kit

Your logo and colours are stored on this device only. They are presentation, not account data, so they are never uploaded and never synced.

A logo pointed at a URL on someone else's server would let that server see your IP address on every page load. The app's security policy now blocks such a fetch outright, in every copy — the hosted site, the portable folder, and the desktop app all carry the same policy, so the image simply does not load. Use a data: URL, which embeds the image on your own device; it is both the private choice and the one that works. (This paragraph used to warn that the leak was possible in copies run off disk. Since 13 Aug 2026 the policy travels with the pages themselves, and the warning became a description of a blocked request.)

We never send anything to a model provider in the background, on a schedule, or without a deliberate action from you. There is no "improve our service by analysing your content" pathway of any kind.

Subprocessors

The complete list of third parties that can receive data through this app:

There are no others. No analytics provider, no advertising network, no data broker, no email marketing platform.

5. What we never do

• No targeted advertising. There is no advertising in this app at all.
• No commercial profiling. We do not build behavioural profiles of any user, and specifically not of students.
• No selling, renting, leasing or sharing of personal information. There is no "sale" or "share" as the CCPA defines it, so no "Do Not Sell or Share My Personal Information" mechanism is required. If that ever changed, this policy would change first and the link would appear.
• No third-party trackers. No analytics SDK, advertising pixel, social widget or session recorder.
• No use of student data for anything but the educational purpose it was provided for.

6. Data minimisation and retention

Deleting your account removes your user record, your sessions, all of your synced boards, all of your synced libraries, your practice score lines, every short share link and every encrypted lesson link you have created from the server in a single transaction.

7. Schools and FERPA

Where a school or district adopts this app, we act as a school official with a legitimate educational interest in the student data processed through it, under the direct control of the school with respect to the use and maintenance of that data. We use student data solely to provide the educational service, we do not re-disclose it, and we do not use it for any commercial purpose.

Schools requiring a signed Data Processing Agreement should request one before deploying the app to students. The local-first architecture means that in most tutoring use, no student record reaches our server at all.

Parents and eligible students may request review, correction or deletion of student data through the school. Requests made directly to us are answered within 45 days.

8. COPPA and children under 13

• The app collects no personal information from a child in its default, signed-out state. A student can be taught with it, take quizzes and draw on it without anything about them leaving the device.
• Where a school uses the app for a purely educational purpose and no commercial purpose, the school may consent on behalf of parents, as COPPA permits.
• Children should not create accounts. Google Sign-In is for the adult running the session.
• Parents may, through the school, review their child's data, have it deleted, and refuse further collection.

Written data retention policy

The amended COPPA Rule requires a written data retention policy, not merely a practice. This is it.

• Personal information is retained only as long as reasonably necessary to fulfil the specific educational purpose it was collected for.
• It is not retained indefinitely, and never for a secondary purpose such as analytics, model training or resale.
• Retention periods are the ones in the table above, and they are enforced in code rather than by policy alone: session-joining data carries a hard expiry timestamp and is deleted by a sweep that runs on the server, not by anyone remembering to run it.
• Data held only on your own device is under your control and is removed when you clear it.
• Account deletion removes the user record, all sessions, all synced boards, all synced libraries, all practice score lines and all share links in a single transaction.

Written information security program

Consistent with the amended COPPA Rule — effective 23 June 2025, with full compliance required from 22 April 2026 — we maintain a written information security program, scaled to the size and complexity of this service as the Rule permits. Its current commitments:

• Minimisation by architecture. Student-identifying data stays on the local device by default, and the server-side surface is deliberately small enough to audit in one sitting.
• Short retention. Session-joining data auto-expires in 30 minutes.
• Credential hygiene. Session tokens are stored hashed. No client secret exists in the client. Passwords are never handled by the app in plain text.
• Transport security. All server communication is over HTTPS.
• Input treated as hostile. Content arriving from another person — an imported quiz pack, a joining student's name, a peer's drawing — is escaped before display and filtered against an allowlist where it must remain markup.
• Risk review on change. Every feature that creates, moves or exposes data about an identifiable student is assessed before it ships.
• Periodic testing. Safeguards are re-tested when the data surface changes, in particular the injection filters and the expiry sweeps.
• Annual risk assessment. At least once a year, and additionally whenever a feature changes what leaves the device, we review the data surface end to end: what is collected, where it travels, how long it lives, and who can reach it.

A designated person is responsible for this program. For a service of this size that is the operator named in section 12.

9. Your rights and choices

• Use it without an account. The strongest privacy control in the app, and it costs you no functionality.
• Keep sync off. Your boards, libraries and scores stay on your device.
• Export everything. Any library or board exports as a plain JSON file you own outright.
• Delete your account. Removes your record, sessions, synced boards, synced libraries, your practice score lines and any live share links from the server.
• Clear local data. Clearing your browser's site data removes everything the app has stored.

Residents of California, Colorado, Connecticut, Virginia and other states with comprehensive privacy statutes have rights to access, correct, delete and port their personal information. Because we hold so little, most are satisfied by the export and delete controls in the app itself.

Those rights follow you, not us. State privacy laws attach to where the person is, so the list above applies regardless of where this service is operated from. We do not treat our own location as a reason to offer anyone less.

Where we operate, and the two Arizona laws that apply to us

Staples Education is a sole proprietorship operated by Adam Staples from Phoenix, Arizona, United States. Arizona has no comprehensive consumer privacy statute, which changes nothing about the rights above. Two Arizona laws do bind us directly:

• A.R.S. § 18-552 — breach notification. If unencrypted personal information we hold is breached, we must notify affected individuals within 45 days of determining it happened. Above 1,000 Arizona residents, the Attorney General and the credit bureaus are notified too.
• A.R.S. § 15-1046 — student data privacy. This binds operators of online services used for school purposes, and we are one. It prohibits targeted advertising built from information collected through school use, profiling a student for anything other than school purposes, and selling or renting student information. We comply with all three by construction rather than by policy — there is no advertising anywhere in this product, no profile is built about any student, and nothing about a student is sold or rented, because the answers do not leave the device to begin with.

10. Security incidents

If we become aware of a breach affecting personal information, we will notify affected users and, where student data is involved, the relevant school, without undue delay and consistent with applicable law.

11. Changes

Material changes are reflected in the date above and, where the change affects what leaves your device, surfaced in the app itself rather than only here.

12. Contact

Staples Education — [email protected]

For a Data Processing Agreement, a FERPA or COPPA question, or a data request, use the same address and say which it is.