Privacy Policy

Last updated: 1 October 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.

Typed answers are numbers, and the app cannot accept anything else. Since 23 August 2026 a question may ask you to type a number rather than pick an option. What you type is treated exactly as a picked option already was: it stays on your device, it is discarded with the rest of the per-question log whenever a result is recorded, and there is no column for it on our server — a synced score line carries totals only, never what you answered. In a live session it crosses the same direct peer-to-peer connection a picked option does, and our server is not in that path either.

The reason this box is safe to have at all is that it is not a text field. What it accepts is a closed grammar — digits, at most one decimal point or one fraction bar, an optional leading sign, and a short length limit. A name, a sentence, an email address or a web address cannot be entered, so an answer box cannot become somewhere a student's identity ends up by accident. That is a deliberate design constraint rather than a side effect, and it is enforced by the same code that decides whether the answer is right.

In a live lesson, the other screen can also see what is being considered before it is submitted (added 29 August 2026): the ticks made on a select-all question, for a typed answer the draft number, shown as a faint “considering” note, and — on a put-in-order question (added 25 September 2026) — the order the steps are in, as they are moved. That arrangement is only a sequence of step numbers, the same thing the answer itself is once submitted. This travels over the same direct peer-to-peer connection everything else in a lesson does; our server never sees it, and nothing about it is stored anywhere. The closed-grammar rule above still holds with no exception: a half-typed entry that does not yet form a valid number is never transmitted — the other screen is told only that typing is happening, not what the characters are. These signals exist only during the live connection, expire within seconds (an arrangement within a minute), and are discarded, not recorded.

Flashcards can be followed in a live lesson (added 26 September 2026). When a student opens flashcards during a lesson, the tutor's screen shows the same card and whether it is turned over. What travels is the card itself — words from the quiz or the vocabulary deck, never anything the student wrote — plus its position in the deck. How the student rated a card (Again, Hard, Good or Easy) is not sent: that self-assessment stays in the student’s own browser, in the review schedule it feeds. It goes one way only: nothing on the tutor’s screen can turn the student’s cards. It crosses the same direct peer-to-peer connection as the rest of the lesson, our server never sees it, and nothing about it is stored on either side.

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.

A quiz run as an assessment records LESS, not more. A quiz opened as a test — the link carries assess=1 — behaves the same way in every respect this policy describes, with two subtractions. It writes no entry to the spaced-repetition review schedule on your device, even if that feature is switched on, and it creates no in-session re-insertion state. Your score, the questions you missed and your topic totals are recorded exactly as they are for ordinary practice, and go exactly as far — which is to say, no further than they already did. Nothing about a test is sent anywhere that ordinary practice is not, and no new record exists because of this mode.

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 of your content and no background upload — and no crash reporter unless you turn one on: an anonymous, scrubbed error report you can opt into is described in section 3, and it is off by default in every mode. Signed out, this app never sends your content to a server. The one thing the website sends without being asked is the anonymous usage counts described in section 3 — counts of what was used, never content, and never from the desktop app or a USB copy.

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.

Since 22 August 2026 there is a button for the live-session half of that. The session panel offers Copy diagnostic — in the notice shown when a session ends, and in the panel footer while one is running. It puts the connection timings from your device on your clipboard so you can paste them to the person you were connected to, which is almost always a tutor asking why the lesson would not connect. The button sends nothing itself: there is still no request and no endpoint, and nothing moves anywhere unless you choose to paste it. What that text can carry is deliberately narrow, and the narrowness is enforced in code rather than promised here. It carries the stage names and millisecond timings of each connection attempt, which family of browser and operating system you are using, and the running count of attempts and successes. It carries no session code — a session code is a live key to a room that is still joinable, so it is removed — and no name, no email address, no web address, no question and no answer. Fields are permitted by a short list rather than blocked by one, so a field added later cannot escape by being forgotten; the build searches the finished text for each of those things and fails if one appears.

Since 21 September 2026 the same report is one tap away wherever you are, not only inside the session panel: Copy diagnostic report sits under the ink toolbar's Settings and in the header's tools menu on every page. It puts the text above on your clipboard together with a few facts about the device and the app's own state that a tutor needs to make sense of a problem: which family of browser and operating system, the size of the screen and of the visible area, the pixel density, whether the pointer is a finger, whether the app is installed, the name of the page (never its address, and never anything after it — a share link or a session code can live there), the colour theme, the role you hold in a live session if any, whether a whiteboard tab is open and what the ink layer reports about itself, and the storage adapter's state: its mode, whether it has finished loading, its pressure level, and how many entries have moved to the browser's larger store — a count, because the entries' names carry your library identifiers and those stay home. Your library names, quiz titles, questions, answers, storage entry names and the raw browser string are none of them in the text, and the build checks each of those absences against the finished report. It sends nothing: there is still no request and no endpoint, and the text moves only when you paste it.

3. What reaches our server, and only when

Our server receives data only in the situations below, 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.

On the website (not the desktop or USB app), staying signed in uses one strictly-necessary cookie, named quiz_refresh and scoped to interactivequizapp.com. It holds only that opaque session token — never your name, email or any content — is marked HttpOnly so no script on the page can read it and Secure so it travels only over HTTPS, and is used for nothing but keeping you signed in. It is not a tracking cookie, sets no advertising or analytics identifier, and lasts 30 days or until you sign out. The desktop and USB copies cannot use a cookie and keep the token in the app’s own storage instead.

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, the order you have arranged them in, and a library's mark (the single letter or emoji beside its name, capped so short it cannot hold a name) — 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.

A library’s description is not uploaded unless you ask for it. When you create or edit a library you may write a short description of what it is for. That text stays on your device. It is free text, so it could easily name a student — “Jimmy’s algebra remediation” — and we will not make that decision for you. If you want descriptions on your other devices, there is a switch: Settings → Privacy → Library descriptions, off in every account mode, including on a device set to “Independent tutor”. Turning it on uploads the description of every library to your account from then on, and the app says so in those words before you do. Turning it back off stops descriptions leaving from that moment; like every other sync switch, it does not reach back and delete what is already in the cloud — clear the description text itself, or delete the library, to do that. While the switch is off your device neither sends descriptions nor accepts one that arrives from somewhere else, so there is no state in which you have turned this off and a description still appears.

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.

Everything else that can send anything is on Settings → Privacy (since 19 August 2026), so the whole answer to "what leaves my device, and how do I stop it" lives on two adjacent tabs: the account mode that sets the defaults, a switch for share-link uploads (off: the Share buttons refuse to upload; opening links other people send you still works), and a switch for hosted AI (off: only the on-device model remains). Every switch on both tabs resolves through the same single policy the sending code reads, so the panel cannot say one thing while the app does another. The same tab shows what is using your device's storage and carries the export, recently-deleted, and delete-cloud-copy actions.

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.

Vocabulary practice links work the same way, and have no short form. “Copy practice link” puts a deck’s words and definitions — and the ids of the course units each card belongs to, so the drill keeps topics apart — in the part of the address after the #, so a student who opens it plays the vocabulary drill without an account, without a copy of the library, and without anything being uploaded — there is no server copy, no expiry and nothing to revoke. The address names the library and quiz ids so the drill can file its review schedule in a library the student’s device already holds; on a device that does not hold it, nothing about the round is kept beyond the tab. Our anonymous usage counts record the page’s path only, never its query or # part, so the words cannot reach them either.

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 30 days from the last time you share it, automatically. Sharing the same pack again gives you the same link rather than a second copy, and starts its 30 days again (since 26 September 2026).
• There is a limit of 50 live short links per account. When you create one past it, your least recently shared link is removed to make room, and the app names each one removed. Nothing about who opens a link is recorded to decide this: the order is by when you last shared each one.
• You can review and revoke them under Share & collaborate › Your short links: one at a time, a selection, or everything made more than 14 or 30 days ago. 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. A chat travels the same way, since 16 September 2026: a live session has a small chat beside the lesson — typed messages, a few quick reactions, and pictures you choose to send. Everything in it goes directly to the other person's browser over the same peer-to-peer connection as the drawing, never to our server, and it is not saved anywhere: the conversation lives in the browser tab and is gone when the tab closes or the session ends; a picture is shrunk on your own device before it is sent. A web address you type becomes a clickable link on the other person’s screen, and the link’s text is always the address itself — there is no way to write a link that says one thing and goes somewhere else, so what the other person reads is where they go. Links open in a new tab with the referrer suppressed, so the site you link to is not told which page of this app the click came from; our page addresses carry library and quiz identifiers, and this keeps them from leaking to a third party. Only ordinary web links (http and https) are made clickable; anything else stays as plain text. Your own drawings on a quiz a tutor is showing you stay on your device, and do not outlive the lesson (16 September 2026): when a tutor moves the lesson to another quiz your page is replaced and then brought back, and your own working used to be lost each time. The app now keeps a copy of your in-progress working so it is still there when you return — held in your browser tab’s own temporary storage, never sent anywhere, never written into any library, and discarded by the browser when the tab closes. Retention here is a property of where the copy is kept rather than of a clean-up step that has to run. Connection timings travel the same way, since 1 September 2026: when a student's browser connects, it sends the tutor's browser a small record of how its last few connection attempts went (since 1 October 2026, also the most recent attempt that did not connect, even when later successful ones have pushed it out of that window), and of any mid-lesson interruption it recovered from — how long each step took, whether it connected or reconnected, and the browser family and platform (for example "chrome, android"). It carries no name, no room code, no answer and no lesson content, and it goes directly to the tutor's browser over the same peer-to-peer connection, never to our server. It exists so a tutor can see why a session failed to connect without asking the student to dig for it; it is kept in the tutor's browser tab only, is discarded when the tab closes or the next session starts, and leaves that tab only if the tutor chooses to copy the diagnostic and paste it somewhere. Since 25 September 2026 the record also says how the student’s page came to exist — whether it was opened, reloaded or reached with back/forward, how long it had been open, and whether the page before it in the same tab closed normally or was shut down by the browser — so a tutor can tell a browser that reset the student’s page from a network drop. The last of those is answered by a one-character marker the app keeps in the tab’s own temporary storage; it never leaves the device by itself, holds nothing about the person, and is discarded when the tab closes. 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; in a group room that means every participant's — the host's saved attempt holds each student's drawings, and a student who runs the quiz from their own library keeps the host's and their classmates'. 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. A live session’s handwriting is recorded on your device, and only there, since 20 September 2026. While a session is connected the app keeps the strokes drawn on each question — yours and the other person’s — with the moments they were drawn, so either of you can watch the working back afterwards, stroke by stroke, at normal or double speed, and export the questions you choose as a file. What is kept is vector strokes only: no voice, no camera, no names, no account or peer identifiers, no room code, no typed text, no pasted pictures, and no answers. Text boxes and images are deliberately not recorded, because a text box is where a name gets typed and a picture can hold anything. Erasures and undo are recorded (since 20 September 2026), as the removal of strokes the recording already holds — nothing more than “these strokes went, at this moment” — so a replay shows what was actually on the board at each moment rather than a stroke its author had rubbed out. Only questions that were actually drawn on appear, and a session with no drawing leaves nothing. Each recording is stored in your browser’s IndexedDB with an expiry 30 days after the session and is deleted automatically by a sweep that runs when the app starts, when a new session begins and when the review screen opens; you can delete any recording, or all of them, sooner from that screen. Recordings never sync and have no server table, no endpoint and no sync path: the one way one leaves the device is the export button, which writes a file you choose to save. The moment a session ends, the panel tells you what was kept and offers to show or delete it. Since 22 September 2026 a recording also keeps where each stroke sat on the question — the position and width of the question column on the screen it was drawn on, three numbers per stroke, which describe a layout and nobody’s identity — so the replay can lay the strokes over the question itself. The question shown under them comes from a quiz or library already on your device; nothing is looked up anywhere else. A replay can also be saved as a video clip of one question or as a review sheet — a PDF of each question with its finished working — both made on your device and saved as files you choose, never sent anywhere. And a recording file exported earlier can be opened in the review screen, and paired with a quiz pack file when its questions are not on this device: both files are read in memory only and nothing from either is stored. 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 student joins 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.

That 30 minutes is a hard limit for a student’s name, and renewing a session does not extend it. While a lesson is actually connected, the host’s device tells the server every ten minutes that the session is still live, so the room code and its connection descriptors survive a long lesson instead of expiring under it — up to a hard maximum of 4 hours from when the room was opened, after which the room is deleted no matter what. (Until 9 September 2026 only one-to-one rooms were renewed; a group room’s code went at 30 minutes.) A student’s typed name is deliberately excluded from any renewal and still goes at 30 minutes. The name runs on its own clock, and nothing can extend or restart it.

A student’s own connection record (their seat) is renewed the same way as the room when they change page, and — since 24 September 2026 — while they are still connected: the host’s device tells the server which students are connected right now, and only those records are renewed, so a student who works quietly on one problem for half an hour is not dropped on their next reconnect. A student who has left is not renewed. Either way it is never past the room’s own expiry and so never past the 4-hour maximum. The name inside that record is not renewed with it: 30 minutes after the student joined, their name — and the account handle, if the room required sign-in — is removed from the record while the connection details stay, and from that moment it is never served back to anyone, even before the sweep reaches the row.

A correction, 24 September 2026. Until that day the code did not do what the two paragraphs above say. When a student in a group room changed page, their name was renewed along with their connection details, so it stayed on the server for as long as the lesson ran — never past the 4-hour maximum, but well past 30 minutes. Separately, a tutor changing page in a one-to-one lesson could extend that room past its 4-hour maximum. Both were found in a code review, corrected the same day, and are now checked on every build by a test that runs the server’s real code against a real database and reads back what it stored.

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.

When you turn on anonymous error reports (off by default)

If the app hits a bug — a script error, a connection failure — it can send us a small crash report so we can fix it. This is off until you turn it on (Settings → Privacy → “Anonymous error reports”), in every mode, always.

What a report contains is a fixed list, not “whatever we find useful”: which build of the app was running; your browser family and major version (for example “chrome 128”) — never the full browser identification string; the error’s kind and its message after a scrubbing pass that removes web addresses, codes, keys, coordinates, and any quoted text that is not a code identifier; which of our own files and lines the error passed through — a frame from any other origin (a browser extension, another site) is recorded only as the word “external”; and, for connection failures, the names and timings of the connection steps reached — never the details inside them.

What a report can never contain: your name or anyone else’s, a student’s anything, your email, your IP address (used only to rate-limit the endpoint, never stored), the address of the page you were on, anything you typed, drew or imported, and any identifier that could link the report to you or your account. Reports are anonymous by construction — the table they land in has no owner column, which also means we could not look up “your” reports even if you asked: nothing connects them to you. The scrubbing is enforced by an automated test that plants a room code, a link key, a student’s name and drawing coordinates into constructed errors and fails our build if any of them would reach the wire.

Reports are deleted automatically after 30 days. Turning the switch off stops the very next report; at most five reports leave in any hour.

We ask once, and only on the website (since 25 September 2026). On your first visit to interactivequizapp.com, a small notice in the corner asks: “Help improve Interactive Quiz App — Automatically send crash and connection reports so we can make live lessons more reliable”, with Turn on and No thanks. Nothing is sent while the notice is showing, and nothing is sent if you ignore it or close the page: silence is a no (the notice comes back on a later visit until you answer). Your answer is kept on your device, in the browser’s storage as telemetryOptIn (“true” or “false”). It is the same setting as the switch in Settings → Privacy, so changing one changes the other, and once you have answered either way you are not asked again. The notice is never shown in K-12 classroom mode (a teacher can still turn reports on in Settings for their own device), when your browser sends Global Privacy Control or Do Not Track, in the desktop app, or in any copy of the app not served from interactivequizapp.com. Crash reports never go to the usage-count service below, whatever you answer.

Anonymous usage counts (on by default on the website; off in K-12 mode)

Since 23 September 2026, the website counts a few things so we can see what people actually use: a page opening, a quiz starting, a quiz’s first answer, a quiz being finished, and a hint being opened. (The first answer and the finish were added on 25 September 2026, so we can tell a quiz that is abandoned before the first question from one that is abandoned near the end. They say that it happened, and nothing else: not which quiz, not which question, not whether the answer was right, and not a score.) The counts go to PostHog, an analytics service, on its EU servers. The code that sends them is a copy we host ourselves and have stripped to the minimum: it cannot record your screen or your clicks, cannot load anything else from PostHog, and every event passes an allowlist before it leaves.

What one event contains — the whole list:

• which of those five things happened;
• which page it happened on, as its address without anything after a ? or a # — so never a library, a quiz, a share link or a lesson key;
• your browser family and version, operating system, and whether it is a phone, tablet or computer — never the full browser identification string, and never your screen size;
• a random number made up when the page opened, which is forgotten the moment you leave or reload it. It is the only id, and it cannot link one visit to the next;
• the time, and the version of the counting code.

What it never contains: your name, your email, your account, a student’s anything, what you typed, drew or imported, your questions or your scores, where you came from, and no cookie — nothing is stored on your device for this at all. Your IP address is part of any connection to any server and cannot be hidden, so the PostHog project is set to discard it, and to not use it to work out a location.

When it does not run, and nothing is even downloaded:

• in K-12 mode (Settings → Privacy → account mode) — the mode for a class of minors;
• when your browser sends Global Privacy Control or Do Not Track — we honour both without asking you again;
• when you turn off Settings → Privacy → “Anonymous usage counts”;
• in the desktop app, a USB copy, a test copy, or any copy of the app not served from interactivequizapp.com.

Why we do this, and the legal basis. To find out which parts of a free tool are used and which are not, so the effort goes where it helps. Under the GDPR and UK GDPR we rely on legitimate interests (Article 6(1)(f)): the counts are aggregate, identify nobody, and one switch stops them. You can object at any time with that switch or your browser’s privacy signal. For children, the counts carry no persistent identifier and no information about the child, and K-12 mode turns them off entirely (section 8).

PostHog keeps the events for the retention period of our PostHog plan — 1 year on the free plan, up to 7 years on a paid one — and a shorter period cannot be set. Because the events carry nothing that identifies anyone, there is also nothing we could find, export or delete for you individually; that is the design rather than an obstacle.

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

Three features use an AI model: generating questions, writing a study guide from a whiteboard, and checking questions for contradictions. All three are the only features that send your content to a company other than us, so they get their own section.

“Read aloud” is not one of them, deliberately. The speaker button beside a question uses the speech built into your browser, and it will only use a voice that runs on your device. Some browsers also offer network voices — Chrome’s “Google …” voices send the text to Google and send audio back — and this app will not use one. If your device has no local voice installed, the button tells you so and stays silent rather than sending the question anywhere. Nothing about reading aloud reaches us or anyone else.

Checking questions (“Check questions”, added 25 August 2026) is the newest of the three and is worth describing precisely, because it is the one that reads material you have already saved:

• It runs only when you press the button. There is no timer, no background sweep, and nothing is checked while you are away. If that ever changes it will be a separate, clearly-worded opt-in, because it would be a different promise from this one.
• Anything sent needs a second press, and that press names a number. The device-only checks below run first, on their own, and stop. Only then does the app ask whether to send anything, and the button says how many questions that is — “Send 12 questions to …”. Nothing has left the device at the point you are asked. Choosing to stop there keeps everything the device already found. If your backend is the on-device model, you are not asked at all, because nothing would leave.
• The app may notice that a library has not been checked in a while, and say so on the button. It works this out when you open a quiz — that is, when you are already here — and the only thing it does with the answer is print a sentence. Nothing is sent, nothing is scheduled, and no check starts on its own. A device nobody is using makes no requests, because nothing is running on it to make them.
• What it remembers, it remembers on your device only. Three small records, in your browser’s local storage, never synced and never sent: which flags you have marked as fine, a short fingerprint of the question text each of those decisions was made about (so a flag comes back if you later edit that question, and stays down if you do not), and the date a check last finished. The fingerprint is a short code derived from the text — it is not the text, and it is not reversible back into it.
• It is scoped to one quiz at a time, never a whole library.
• Most of it never leaves the device. Duplicate choices, two choices that are the same number written differently, arithmetic that does not come out, questions whose parts do not line up, and questions where more than one answer can be defended (an equation with two roots, both offered) are all decided in your browser by an algebra engine that runs there. No part of that pass involves a model or a network. Only one check needs a model — whether an explanation argues for a different answer than the one marked correct — and only the questions that check runs on are sent.
• What is sent for that check is the question text, its choices and its explanations, and nothing else: no topic, no difficulty, no provenance marking, no library or quiz name, nothing about you.
• The panel tells you how many questions were sent before you close it. When the answer is none, it says so.

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, Google or OpenAI that governs how they handle the text — not ours. That includes whether they train on it: each states its own position for API traffic, and it is the one you agreed to when you made the key.
• Checking a key does not send your content. “Test & validate” beside the OpenAI key asks that provider which models the key can reach — the key, no prompt, no board text — and only when you press it.
• 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 advertising network, no data broker, no email marketing platform.

Which providers this app can reach at all is a fixed list, enforced by the browser security policy shipped in every copy — hosted, portable and desktop. A request to anywhere else fails outright rather than being trusted not to happen, so adding a provider is a deliberate change to that policy, disclosed here in the same change.

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 tracking of people. No advertising pixel, no social widget, no session recorder, and no identifier that follows you from one visit to the next or from this site to any other. The one analytics component is the anonymous usage counting in section 3, which stores nothing on your device. The website sets exactly one cookie, quiz_refresh, and only to keep a signed-in user signed in; it is strictly necessary, carries no identifier, and is absent entirely when you are signed out.
• 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 and their earlier versions, 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. On the website, the anonymous usage counts in section 3 do leave the device, and we have designed them to fall outside what COPPA calls personal information: no name, no contact detail, no content, and no persistent identifier — the only id is a random number that dies with the page, and nothing is stored on the device to recognise it again. They are used only to understand and improve the app, never for advertising or to profile anyone. K-12 mode turns them off entirely, and that is the mode a school should use with a class.
• 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 and their stored earlier versions, 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; a student’s typed name is never renewed past it.
• 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.
• Limits against abuse, and no untested deploy (since 25 September 2026). Every signed-in write is rate-limited per account, and every account has a storage ceiling for share links, lesson links and synced whiteboards, so one account cannot exhaust the service for everyone. The expiry sweeps run as independent steps, so one failure cannot stop the others. The site is not published unless the full automated test suite, including the tests that check these safeguards, passes on the exact build being deployed.

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.
• Turn off the usage counts. Settings → Privacy → “Anonymous usage counts”, or send Global Privacy Control / Do Not Track from your browser. Either stops them on that device before anything is downloaded.
• 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 — provided the clear covers both stores. Your content lives in localStorage and, as a verified backup and once a profile outgrows the smaller store, in IndexedDB. Some cleaning tools and privacy extensions clear only the first. When the app finds its localStorage empty and that backup still present, it restores your libraries automatically and tells you it has done so — because the overwhelmingly common cause is a tutor losing work they never meant to touch. Nothing is sent anywhere at any point; the restore is one drawer on your device refilling another. If you mean to erase your work, delete the libraries inside the app, or clear this site's data with site data/IndexedDB included. Deleting a library for good takes everything filed under it — its quizzes, scores, per-question statistics, mastery, review schedule, the whiteboard ink archived against its quizzes, and the saved state of any quiz started and never finished (which can include a student's handwriting). A library in Recently Deleted is not yet deleted for good: it keeps all of this so restoring it is lossless, and loses it when the 30 days run out or you empty the trash yourself.

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.