What SurveyAll stores
SurveyAll is a live classroom polling tool. Students answer questions from their phones. This page describes exactly what is recorded when they do, what is not, and who can see it.
Last updated 28 September 2026.
The short version
- Polls, quizzes and every other activity store no student names. There is no field to put one in.
- The one exception is a conference board, where students give a first name and last initial so the instructor knows who to call up. That name is held only while the board runs and is erased when it ends. Details below.
- Students never create an account and never sign in. They enter a room code, which is not a password and identifies nobody.
- No emails, student IDs, or IP addresses are stored for anyone, student or instructor.
- No cookies, no analytics, no advertising, no third-party trackers.
- Answers are not linked to a person, and cannot be linked back to one after the fact.
- Instructors have accounts, holding a username and a password and nothing else. This is the only personal data in the system, and it belongs to staff, not students.
What a student's device sends
When a student joins a session, their device is given a random two-word nickname: “Amber Falcon”, “Teal Juniper”. Their answers are filed under that nickname. That is the entire record of who answered what.
The nickname:
- is generated at random by the server, not derived from anything about the device or the person;
- exists only inside one session, so the same student in your next class gets an unrelated nickname;
- cannot be joined across sessions, because no key exists that would connect them;
- is only shown to the student at all when the deck contains a scored quiz, so that a leaderboard can work.
Nothing else travels with an answer. Not a device identifier, not a browser fingerprint, not a location, not an IP address.
What is stored, in full
| Data | Why it exists | How long it is kept |
|---|---|---|
| The question text an instructor wrote, and the deck it sits in: its title, its question types and options, its theme and background choice | It's their teaching material | Until they delete it |
| Answers submitted, each tagged with a random session nickname | To show and export results | Until the instructor deletes the session |
| The nicknames already handed out in a session | So two phones in the same room can never be given the same one, which is what makes a quiz leaderboard add up. The row holds the nickname and the moment it was claimed, and nothing else: no device identifier, and nothing that says whose phone took it | Until the instructor deletes the session |
| Q&A questions typed by students | The backchannel feature | Until the instructor deletes the session |
| Session join codes, timestamps, and settings | To run and archive a session | Until the instructor deletes the session |
| Background images an instructor uploaded | Projector styling | 30 days after upload, unless the instructor pins the image to keep it. These are the one thing here with an expiry date, because they are stored inline and the database is finite |
| Instructor: a chosen username | To tell accounts apart | Until the account is deleted |
| Instructor: a password hash | To sign in | Until the account is deleted |
| Instructor: whether the account is an admin | Admins can reset a colleague's password and read the feedback inbox. The first account created becomes one | Until the account is deleted |
| Instructor: when the account was created, and when it was last used | So the operator can tell a live account from one nobody has touched since the term it was made. Two timestamps, no page history. Nothing records what was done, only that something was | Until the account is deleted |
| Instructor: a count of recent failed sign-ins | To slow down password guessing: each failure in a row makes the next attempt wait longer | Cleared on a successful sign-in; forgotten after a day |
| Feedback typed into the quill button, the page it was sent from, and the sender's username if they were signed in | So whoever runs this site hears what is broken. The button is not on the student view, and nothing is recorded that could be used to reply to a signed-out sender | Until the admin deletes it |
That is the complete list. Every table in worker/schema.sql is
represented above, and there is no other file, except
conference_boards, which holds an instructor’s board settings
and no student data. Conference boards are described in full
below. Some of those rows are
housekeeping about instructor accounts rather than anything a student
sends. They are listed because a page whose whole authority rests on
being exhaustive has to actually be exhaustive, not because they change
anything said above.
Conference boards: the one place a name is used
A conference board is for one-on-one writing conferences during class. Each student opens it on their phone and gives a first name and last initial (“Maya R.”), a one-line topic, where they are in the writing process, how it’s going, and, if they want a conference, what they want to talk about. When a conference ends, the student types their own next step. The instructor sees all of this on their own screen. It is never projected: the board’s projector view shows the join code and nothing about anyone.
This is handled differently from everything else on this page, on purpose:
- It never enters the database. Names and everything a student types on a board live only in that board’s own short-lived storage (a Cloudflare Durable Object), not in the database the table above describes. The database records only the board’s code, title, the instructor’s lists of stages and topics, and when it started and ended.
- It is erased when the board ends, or twelve hours after the board started if nobody ends it, whichever comes first. The erase is automatic and cannot be skipped.
- The only lasting copy is the instructor’s. Ending a board downloads a log (names, topics, conferences held, next steps) to the instructor’s own computer, where it sits with the rest of their course records. SurveyAll keeps nothing.
- Students see only their own card. A phone is never sent another student’s name or topic, its place in line, or whether it has been called up.
- Only the instructor who started the board can open it. Other instructors on this site cannot, the same as with sessions.
A student’s phone also remembers, on that phone only, its place on the current board (so a reload is the same student) and its last next step (so it is still there after the board is erased). It does not remember the student’s name for next time, so a shared lab computer never shows one student’s name to the next. Clearing the browser’s site data removes both.
Who can see what
- An instructor sees only their own decks, sessions, and results. Instructors sharing this site cannot see each other's material: every request is filtered by account, and asking for a colleague's session by its ID returns “not found”.
- Students see the current question and, when the presenter chooses to share them, aggregate results. A student can never retrieve raw answers, another student's answer, or a quiz answer key. Answer keys are stripped on the server before a question is sent to a phone.
- The operator, the person who runs this deployment, administers the database and can therefore read what is in it. This is true of any self-hosted application and it is stated here rather than glossed over. See below.
Things this page will not claim
A privacy notice is worth something only if it says the awkward parts too. These are the limits of what is above.
The data is not inaccessible. It is unidentified
Stored data is encrypted at rest by the hosting provider, but this is not end-to-end encryption, and the operator can read the database. The protection offered here is different and, for a classroom, stronger: the records contain no student identity to read in the first place. Someone with full database access still cannot tell you who said what.
A student can type their own name into an answer
Open-ended and Q&A questions accept free text, so a student can write their name, or something identifying, into one. No polling tool can prevent this. Instructors can delete any individual response, and should tell students not to include their names.
The hosting provider sees network traffic
SurveyAll is built to deploy on Cloudflare, so this site is served from Cloudflare's network. Serving any web page necessarily means that network handles the request, including the visitor's IP address, and it applies its own security logging. SurveyAll neither receives nor stores that. It is governed by the host's privacy terms, not by this page. If this deployment has been moved to another host, read that host's terms in Cloudflare's place.
The sign-up code is a gate, not a lock
Instructor accounts are created with a shared code. That keeps out automated sign-ups and passers-by; it is not a strong access control, and anyone who is given the code, or guesses it, can create an account. It can be changed at any time. No student ever needs or receives it.
Uploaded background images are served by unguessable link
Projector backdrops uploaded by an instructor are served at a random URL that does not require signing in, because browsers cannot authenticate an image request. Anyone holding that exact link can view that image. These are decorative slides already projected in front of a room; no student data is in them, and no listing of them is public.
Where this sits with your institution
This copy of SurveyAll is run independently by the instructor who operates it. It is not operated, endorsed, hosted, or reviewed by any university or college, it is not covered by an institution's own agreements with vendors, and it is offered to colleagues as-is.
That is a statement about who stands behind the tool, not about what it records: everything above about what is stored is true either way. A department with a formal software review process should route this through that process before adopting it for coursework. The design was built to survive that review, and every claim on this page is tied to a file you can read.
Deleting things
- A single response: an instructor can delete any individual answer from the results view.
- A whole session: deleting a session removes every answer and Q&A message in it.
- A deck: deleting a deck removes its questions and all of its sessions.
- An instructor account: ask the operator. Deleting an account removes its username and password hash.
Deletions are immediate and permanent. There is no recycle bin and no recovery, so be certain first.
Checking any of this yourself
The claims above are not assurances to take on trust. The source code is public, and each one corresponds to something specific you can go and read:
| Claim | Where to verify it |
|---|---|
| No column anywhere can hold a student name, email, ID, or IP | worker/schema.sql, the full database definition, about 340 lines |
| Quiz answer keys never reach a student's phone | sanitiseQuestion() in worker/index.js |
| Instructors cannot read each other's data | The ownership helpers in worker/index.js, and the isolation tests in tests/run-worker-tests.mjs. They drive the real routes as a second instructor and check both halves, that the owner still can and the stranger cannot |
| Students cannot read raw responses | participantRoute() in worker/index.js, the participant API in full |
| Failed sign-ins are counted without storing an IP | The auth_throttle notes in worker/schema.sql |
| Passwords are not recoverable from the database alone | The hashing section of worker/auth.js |
| No cookies or third-party requests | Any browser's network inspector, on any page of this site |
Who runs this, and how to reach them
This deployment is operated by the instructor who set it up, who controls the hosting account it runs on, administers the database, and is the person to contact about anything on this page: a deletion request, an account problem, or a question from a department reviewing the tool.
To reach them, use the feedback button, the quill in the corner of this page. It goes straight to the operator. Nothing is recorded about you when you use it beyond what you type and, if you happen to be signed in as an instructor, your username.
If this page and the software ever disagree, the software is what is true. Report the discrepancy and it will be corrected.