Security

Where the data lives

Google Cloud, region europe-west3 — Frankfurt. Encrypted at rest by the platform and in transit over TLS. Every institution is assigned a data-residency zone at creation, and at present every zone is the EU one.

Who can reach what

Access is enforced by database rules rather than by application code, which matters because a bug in the application cannot then widen it.

• A student has no access to the database at all. A private cue is kept private in what is sent: the teacher's iPad sends each Cue only its own view, and a Cue outside the cast never receives a beat.
• A teacher can read the sessions they taught. Not a colleague's.
• An institution owner can read usage figures, which contain no student, and cannot read session records at all.
• We reach institution data only through administrative tooling that writes an audit entry, and only when asked to look at something.

Authentication

Staff sign in with an email address and a password. Students do not sign in at all: a student holds a Cue, a device registered to the institution, which proves itself cryptographically — an Ed25519 key the Cue generates on its first start signs a per-session challenge. There are no student credentials in the system, so there is no student account-recovery channel to attack.

Every issued password must be replaced on first use, and until it is, the account can do nothing except change it.

Offline sessions

A Cue holds an Ed25519 private key generated on the device and stored in its own flash memory. It never leaves the device. To join a session it signs a challenge that binds three values — a single-use number, the session, and the device — so a captured signature cannot be replayed into another session or from another device.

The same verification code runs on the server and on the teacher's device. One implementation, so online and offline authentication cannot drift apart.

Deletion

Session records expire on the institution's schedule, twelve months by default. Deletion is performed by a job that runs daily, reports what it deleted, and raises an alert if anything past its window remains. A missed run alerts too — a job that does not run looks identical to a job that had nothing to do, so absence is monitored rather than only failure.

If something goes wrong

We will tell the affected institutions without undue delay and in any case within 72 hours of becoming aware, which is what Art. 33 GDPR requires of a processor's controller and what we hold ourselves to as the processor. You will be told what happened, what data was involved, what we have done, and what we recommend you do — in that order, and in plain language.

Report anything you find to hello@spontar.com. We do not currently run a bug bounty; we do read everything, and we will credit you if you want that.

What we do not claim

We hold no ISO 27001 or SOC 2 certification. We are a very small team, and buying an audit at our size would be theatre. What we can do is describe exactly how the system works and let you judge it — which is what the technical page and the sub-processor list are for.