Privacy

Two very different groups of people, and it matters which you are, because almost nothing is the same for both.

People who join a session. You typed a code, or scanned one, and answered some questions. You have no account and you did not sign anything. Most of what follows is about you.

People who hold an account. Hosts, co-hosts, organisers and administrators, who signed in and who run the sessions.

When an organisation runs an event using BamzIQ, that organisation decides what to ask you for and what to do with the answers. The operator of BamzIQ provides the software that stores it. [to be completed before launch: which party is the controller for each purpose, in the terms of whichever regime applies]

Always, whether or not the organiser asks for anything else:

• The name you type. A nickname is enough. It is stored with your result and shown on the leaderboard in the room.
• Your answers, exactly as submitted. Including free text: anything you write into a word cloud, an open response or a brainstorm is stored verbatim. Do not type anything into those you would not want recorded.
• How you did. Your score, whether each answer was right, whether you answered at all, and how long you took. The timing is recorded because scoring credits how long you thought rather than how fast your connection is.
• Any question you ask the room. Audience questions carry your name to the moderator. They are held in the running session and written into the crash-recovery snapshot of that session.

Only if the organiser has turned it on for that event:

• An identifier. An email address, an employee ID, a ticket reference, or a field the organiser has defined. The screen tells you which, and whether it is required or optional, before you type it.
• Anything in the attendee list the organiser uploaded. If they imported a registration spreadsheet, every column of your row is kept against your record: company, dietary requirements, table number, whatever was in the file. BamzIQ does not read or interpret those columns; it stores them.

Identifiers are stored in plain text, not hashed. Twice, in fact: once exactly as you typed it, and once lowercased and trimmed so that joins across sessions can be matched to the same person. That is what makes one standing across a whole event possible, and it means an email address you give at the door is readable by anyone with access to the organiser’s data.

While you are in a session your browser also holds a short-lived signed ticket proving which participant you are. It contains the identifier you gave. It is signed rather than encrypted, it never leaves your browser except back to the same server, and it is cleared when it is used or when you close the tab.

An organiser can mark a session anonymous. Here that changes what is written, not what is displayed, which is the difference between a promise and a mechanism:

• Your name is not written against your answers; the field is left empty.
• The answer rows are shuffled before they are stored, so their order cannot be used to work out who answered when.
• No final standing row is written, and no participant record is created at all.
• Your identifier is dropped at the door rather than resolved and then discarded, so it never reaches storage.
• Results are withheld entirely below five respondents, because an average of three answers in a team of four is not anonymous however it is stored.
• Only the average response time is reported, never yours. In a small room, timings identify people.

Two limits, stated because they are easy to assume away. It is off unless the organiser turns it on, and it applies per session rather than per event. And it exists for sessions inside an event; a standalone game does not have the switch. If anonymity matters to you, ask the organiser before you answer.

• Your email address, a display name, and your role in the workspace.
• A hash of your password, using scrypt with a per-account salt. The password itself is never stored and cannot be recovered from the hash.
• Sign-in sessions: when each began, when it was last used, when it expires, and a hash of the session token, never the token itself, so a stored session cannot be used to impersonate you even by somebody reading the database.
• The content you make: quizzes, events, assignments, images you upload, reports.
• If you connect an AI provider, the API key you supply, encrypted at rest, never returned to the browser, and never written to a log. Only the last four characters are kept readable, so you can tell which key is connected.
• A record of which AI features you switched on or off, and when. It is append-only, which means turning a feature off adds a row rather than erasing the earlier one.

Your IP address is read from the incoming request to rate-limit failed sign-in attempts. It is held in memory, swept every few minutes, and written to no table.

A list rather than a summary, because “we hold your data securely” is not an answer to “where is it?”, and because the erasure section below can only be read against it. This is every table that holds something about a person, what it holds, and, crucially, what identifies the person in it. That last column is the whole difference between data that can be found on request and data that cannot.

Things with an identifier you could be looked up by

• Accounts. Your email address, display name, workspace role, password hash and sign-in times. Alongside it: your open sign-in sessions (as token hashes), any password-reset tickets, any invitation sent to your address, your AI provider settings including an encrypted API key, and an append-only log of which AI features you switched on and when. Identified by your account id, and by your email.
• Event participants. If an organiser asked who you were, the identifier you typed is stored twice (as you typed it, and lowercased so joins across sessions match the same person) with your most recent display name and how many times you were seen. Identified by that normalised identifier, within one event.
• Registration rows. If an organiser imported an attendee spreadsheet, your entire row is kept verbatim: company, dietary requirements, table number, whatever their file contained. Identified the same way.
• Event standings. What you scored in each session of an event, with the figures the standing was normalised against frozen at the time. Identified by a link to your participant record. Nothing is written here at all for an anonymous session.
• Game reports, when you joined through an event’s identity link. Your final standing and your per-question rows also record which participant you were, which is what makes them findable on request. This is recent: for a long time the link was recorded against the event standing and thrown away before the report. Rows written before that cannot be given the link retrospectively: it was never recorded, and nothing else in the row implies it, so they stay in the category below. Nothing is written here at all for an anonymous session.
• Assignment attempts and answers. The name you typed for a piece of homework, your marks, when you started and finished, and each answer you gave. Identified by two hashes of tokens your own browser holds: one that resumes the attempt, and one that is the same across every assignment you do in that browser.
• Revision cards. One per question you got wrong, carrying your typed name, which box the card is in and when it is next due. Identified by that same per-browser hash.
• Group members. A name and optional email, if a teacher listed you in a class. Not an account, and not linked to one.
• Uploaded images. The bytes, in the same database, owned by the account that uploaded them.

Things with no identifier at all: the name is the only handle

• Game reports, for everybody else. Your final standing in a live game, and one row per question you answered: whether you were right, whether you answered at all, how long you took, and exactly what you submitted. When you joined by typing a nickname (the ordinary way to play), these carry that nickname and nothing else. No account, no participant link, no identifier of any kind. The same is true of every row written before the participant link existed. This is the single most important fact on this page for what follows.
• Session records. Which quiz ran, when, its game code, how many played, and which account hosted it. The quiz title is copied in at play time on purpose, so renaming or deleting a quiz cannot rewrite what last term’s session was called.

Things that are temporary by construction

• The crash-recovery snapshot of a running game. While a game is live, its whole state is written to one row every couple of seconds so a crash or a deploy does not vaporise the room. That includes every player’s name, their score, any identity they arrived with, every audience question with the name of whoever asked it, and (held server-side only, never sent to the room) who upvoted which question. The row is deleted when the game ends, and any left behind is swept after six hours. Audience questions and their voters are stored nowhere else: no table, no report.

Things people reasonably assume exist here and do not

• No analytics tables. Every reporting figure is computed on demand from the rows above. There is no separate store of behaviour, no event stream and no profile.
• No record of anything sent to an AI provider. Prompts, uploaded source material and generated drafts are not written to any table or to disk. What is stored is only which provider a host connected, an encrypted key, and when they switched a feature on.
• No IP addresses in any table. They are read to rate-limit sign-ins and joins, held in memory, and swept.
• No personal data in the server logs. Log lines carry game and session identifiers, not names.

BamzIQ contains no third-party analytics, advertising or tracking of any kind. Not a tag manager, not a product-analytics SDK, not an error reporter, not a pixel. The web application’s entire dependency list is the framework, the rendering library and BamzIQ’s own packages. Nothing profiles you across sites, because nothing here is capable of it.

One cookie is set, and only if you sign in. It holds a session token, and it is first-party, HTTP-only so scripts cannot read it, marked SameSite=Lax, and marked Secure outside local development. Playing a game sets no cookie at all, which is why there is no consent banner: there is nothing to consent to.

Some things are held in your own browser and are never sent anywhere on their own:

• Your identity ticket for a session, in tab storage, cleared when it is used.
• A resume token for a self-paced assignment, so you can come back to it.
• A host’s control grant, notes and moderation annotations, for that tab only.
• A service worker cache of the application shell and hashed assets, so the app opens on bad conference wifi. Live session data is deliberately never cached.

Clearing your browser storage removes all of these.

By default, nowhere but the servers running BamzIQ. There is no email provider, no object storage, no payment processor and no analytics vendor in the path: uploaded images are stored in the same database as everything else, and no payment is taken anywhere in the product. Three exceptions, each of which somebody has to switch on:

• An AI provider, if a host connects one. Under the host’s own account with their own key, feature by feature. Report insight sends question text, accuracy and the distribution of chosen options, never a participant list. Idea grouping sends the submitted brainstorm text, which is written by attendees. Generation sends whatever material the host supplied.
• Your identity provider, if single sign-on is configured. The usual OpenID Connect exchange: BamzIQ learns the account’s identifier, email and name, and nothing else.
• The hosting providers. The servers and the database run on infrastructure operated by third parties, who necessarily hold the data at rest. [to be completed before launch: the providers named, with their regions and the transfer position that follows]

Nothing you enter is used to train any model. Nothing is sold, and nothing is shared for advertising.

Honestly: today, almost nothing is deleted automatically. This is the weakest part of the product’s privacy posture and it is stated plainly rather than dressed up.

• Crash-recovery snapshots of live sessions are removed when the session ends, and any left behind are swept after six hours. This is the only age-based deletion that actually runs.
• Reports, results and answers are kept until somebody deletes them. There is no expiry.
• Participant and registration records are kept for as long as the event exists. Deleting an event today moves it to a Trash from which nothing is yet purged, so those records persist.
• Quizzes can be deleted permanently by their owner. Doing so does not remove past reports: a report deliberately keeps its own copy of the quiz title so that renaming or deleting a quiz cannot rewrite last term’s session.
• Expired sign-in sessions stop working at their expiry, but the rows are not yet swept.

An erasure request, described below, is therefore the mechanism that removes data, not a schedule. Nothing goes on its own.

[to be completed before launch: a retention schedule, and something that enforces it: a period per category of data, and a job that actually removes it]

There is still no self-service deletion. No button on a screen you can reach, and no export. What exists now is a mechanism the organisation that collected your data can run on your behalf, and this is what to do:

• If you joined somebody’s event or class, ask the organisation that ran it. They hold the workspace, they decided what to collect, and they are the ones who can act. If you do not know who they are, the event or session name is enough for the operator to route the request.
• If you hold an account, an administrator of your workspace can erase it, or delete it outright. Those are different acts and the section below explains how.
• Otherwise, write to the operator. [to be completed before launch: a monitored contact address for privacy requests, and the response time committed to]

[to be completed before launch: the rights that apply (access, correction, erasure, portability, objection) under whichever regime governs, and the supervisory authority a complaint goes to]

The mechanism is a single operation an administrator (or, for their own class or event, the person who ran it) carries out against the database. It can be previewed first: the preview runs the whole thing and rolls it back, so the counts it reports are the counts the real run will produce.

Its default is to remove what identifies you and keep the record. That needs saying plainly, because it is not what “delete” sounds like. A game report, a tournament standing and a set of homework marks are records an organisation holds about an event; your name on the row is what makes them about you. Removing the name and leaving the row means the organisation keeps a true record of its own event and the row stops being about an identifiable person. Deleting the row instead would change a published leaderboard, alter a class average, and put a gap in a set of results that other people are also in. Deletion is used only where the entire row is one person and nothing else.

If you hold an account

• Your email address, display name and last sign-in time are replaced with placeholders, and your password hash is removed. The account row itself stays, disabled, naming nobody, because content you made, sessions you hosted and purchases you recorded all point at it, and deleting it would silently detach every one of them from any owner without removing anybody’s name from any report.
• Deleted outright: every open sign-in session, every password-reset ticket, and your AI provider settings including the encrypted key. These are live credentials, not records.
• Kept: quizzes, events, assignments, courses, groups and images you made; the sessions you hosted; and your purchase records. They now belong to an account that names nobody. Erasing a person is not the same request as destroying an organisation’s material. An administrator can separately delete an account and choose whether its content is transferred or removed.
• Kept, and flagged for legal review: the log of when you switched an AI feature on or off, and your purchase records. [to be completed before launch: whether a consent log and a financial record survive an erasure request, and under which retention obligation]

If you gave an identifier at an event

• Your participant record keeps its place but loses everything that names you: the identifier you typed, its normalised form, your display name and the link to the attendee list.
• Deleted outright: your row from the attendee spreadsheet the organiser imported: company, dietary requirements, table number, every column of it.
• Kept: what you scored in each session, now attached to nobody. Deleting those rows would delete the event’s own record of itself; the figures each row is normalised against are frozen, so removing yours would not have moved anybody else’s position either way.
• The game reports of the sessions you played are reached too, when you joined them through the event’s identity link. The nickname on your row is replaced with a placeholder (a different one in each session, so two games are not joinable through it), and the link to your participant record is removed with it. Your rows are found by that link and never by matching the nickname, so somebody else in the room who happened to type the same one is not touched. Every score, rank, timing and answer stays exactly as it was.

If you did an assignment

• Your attempt keeps its marks and loses your name and both of the browser tokens tied to it: the one that resumes the attempt and the one that links every assignment you did in that browser.
• Deleted outright: your revision cards. A revision schedule is one person’s and nobody else’s, and an anonymised card would be a schedule for a deck nobody can ever open.
• Kept: the answers within the attempt, which carry no identifier of their own.

And the case that genuinely does not work

If you joined a live game by typing a nickname and nothing else (which is the ordinary way to play), there is nothing in the system that links that nickname to you. The report rows carry the string you typed and no identifier at all.

This is now the narrower claim it should always have been. If the event knew who you were and you joined through its identity link, your game report rows can be erased: they record which participant you were, and the erasure above uses that. What has no handle is a nickname typed by somebody the system never identified.

Two honest caveats. Rows recorded before that link was stored do not have it, and it cannot be added retrospectively: the information was never recorded and there is nothing to work it out from, so those sessions are in the same position as a typed nickname. And a session run anonymously records neither your name nor your participant record (not even when everybody in the room joined with an identity), so there is nothing in it to erase, which is the promise that mode makes rather than a limitation of this one.

For everything left, an erasure cannot find your rows. What it can do instead is replace a nickname in named sessions, and the operator has to confirm they understand the consequences: it matches a free-typed string, so in a large room it may catch more than one person, and it cannot be shown to have caught the right one. Every score, rank, timing and answer is left exactly as it was; only the label changes, to a different placeholder in each session so that two games are not joinable through it.

[to be completed before launch: what is owed to somebody whose only trace is a free-typed nickname: whether replacing a matching string on request is an adequate response, whether the data is personal data at all when nothing links it to a person, and whether the join screen should warn people not to type their real name]

What an erasure cannot reach, at all

• Anything you wrote into an answer. Word clouds, open responses and brainstorms are stored exactly as submitted. If you typed identifying details into one, nothing can find them automatically: the row is not about a person, its contents are.
• Audience questions in a game that is still running. They exist only in that game’s memory and its crash-recovery snapshot, and are removed when it ends. Removing one mid-game would break crash recovery for everybody in the room.
• Backups. An erasure changes the live database. Whatever backups the deployment holds still contain the rows as they were. [to be completed before launch: a backup retention period, and a position on whether erasure must propagate into backups or is satisfied by them expiring]
• Anything already exported. A CSV a host downloaded, a report printed for a client, the spreadsheet an organiser imported from and still holds. Those left the system before the request arrived.

What is recorded about the erasure itself. That one happened, when, by which administrator, against which kind of subject, and how many rows in each table were removed or anonymised. Deliberately not who it was about: a log saying “we erased everything about this address” is a permanent record containing that address, which would outlive everything the erasure removed. A one-way hash would be no better, because anybody holding a guess could confirm it. An external ticket reference can be attached instead, and the request’s own system is where your identity belongs.

Previews are logged too, on the same reasoning: looking at somebody’s data to find out what an erasure would touch is still looking at it.

BamzIQ is used in classrooms, and it has no age gate and no children’s-data controls of any kind. It does not ask for a date of birth, it has no parental-consent flow, and it does not behave differently for a young participant. Players deliberately need no account (a class of eleven-year-olds has no business holding credentials), which means BamzIQ also has no way to know how old anybody is.

If you are a school or a provider of services to children, that determination and any consent required is yours to make before you use this. [to be completed before launch: a children’s-data position, and whether any age-based restriction should be built rather than documented]

The measures that exist are described where they are tested rather than asserted here: passwords are hashed with scrypt and verified in constant time, session tokens are stored only as hashes, controller roles require a signed grant bound to a single room so that a published game code cannot end somebody’s keynote, the answer key is never sent to a player’s device, a pending audience question is never sent to a player, and outbound fetches on behalf of AI features are checked against internal network addresses on every redirect.

No security or privacy certification is claimed. There is no SOC 2 report, no ISO certification, and no compliance attestation of any kind. There is no uptime commitment. See the terms.

The date at the top is when this was last written. Because it is a draft, it will change substantially before launch, most obviously in the places marked as outstanding. [to be completed before launch: how material changes will be notified, and to whom]