Four commitments

No student accounts

Students never create a profile, set a password, or hand over an email. A check-in is a roster number plus a rotating code — and that’s the entire identity surface.

Nothing computed is stored

Percentages, flags and the matrix are calculated on read from raw events. There’s no derived profile sitting in a table waiting to be breached or to drift out of date.

Not a fingerprint

The device cap uses a random tag in a signed cookie, scoped to one session. It can’t recognise a phone in another class, let alone across the web.

No trackers, no resale

No third-party analytics SDKs, no ad pixels, no data sale — by design, not by policy promise. There’s simply nothing wired up to leak.

What we hold — and what we refuse

What we hold
A per-course roster number
So a check-in can be attributed inside one course.
Raw check-in events
The single source of attendance truth, fully auditable.
Your teacher account
Email and a hashed password — yours, not your students’.
What we refuse
Student names or emails
Not required to take attendance, so not collected.
Location or GPS
A rotating code in the room does the anti-fraud job instead.
Device fingerprints
The session cookie is a cap, deliberately un-identifying.
Cross-course identity
Same student, two courses, two unlinked rows — clean deletion.

Retention you control

A scheduled job enforces your retention window and deletes per-course data cleanly when a course ends. Because a student is only ever a roster entry inside one course, removing them is a single, complete operation — no scattered profile to chase across the system.

Aligned with GDPR and the Swiss FADP. A plain-language data-processing description ships with the product so your DPO has something real to read.