Class Attendance Monitor
Anti-proxy classroom attendance via randomized presence checkpoints
Manual and single-scan attendance methods — roll call, RFID taps, QR scans, one Bluetooth ping — verify presence at a single instant, not for a session's duration. That gap is easy to exploit: a student answers roll call for an absent classmate, or hands a friend their phone for a five-second check-in.
Sampling presence at several unpredictable moments across a class, instead of once, raises the cost of faking attendance from a five-second favor to coordinating detectable presence at times neither party can predict — closer to a real anti-proxy mechanism than a digital roll call. None of the individual pieces here are new: BLE, Wi-Fi, QR, geofencing and device binding have all been used for attendance before. The question this project actually asks is whether a specific combination of them — randomized, server-held checkpoints proven over a classroom-local network, in a browser — is a practical answer to the single-event problem the existing categories share.
- 01Designed a checkpoint-verification architecture: the server privately picks 3 random moments in a class session and marks a student present if at least 2 are confirmed — the schedule is never sent to any client, so it can't be gamed.
- 02Iterated through three candidate architectures end to end — native BLE, web + rotating QR, web + instructor-hosted local Wi-Fi — evaluating each against real platform constraints (iOS Bluetooth restrictions, browser mixed-content rules, QR forwarding) rather than picking one and hoping.
- 03Reviewed the existing categories of automated attendance first, and concluded the individual mechanisms are all well-established — so the project is framed around whether a particular combination closes a known gap, not around inventing anything.
- 04Not yet built — this is active design work, listed here deliberately as a concept rather than a shipped product.
- 01Iteration A — Native app + BLEFlutter app, instructor's device broadcasts a rotating BLE token. Ruled out: native iOS builds need Xcode, a Mac, and an Apple Developer account — none available for this project.
- 02Iteration B — Web + rotating QRPWA, checkpoint QR refreshed at random moments. Ruled out: no iOS browser supports Web Bluetooth at all (a WebKit-level restriction), and a QR code is just a photographable image — forwardable to someone off-site.
- 03Iteration C — Web + instructor-hosted local Wi-Fi (recommended)The instructor's laptop hosts the network; each checkpoint is confirmed by reaching a LAN-only endpoint. Closes the forwarding hole structurally — a screenshot has no network route to a private local IP.
- 3 server-randomized checkpoint moments per session, never disclosed to the client, so presence can't be gamed by learning the schedule
- 2-of-3 checkpoint threshold for a present mark — tunable, tolerant of normal Wi-Fi flakiness
- Manual instructor override on every session, with a required reason — treated as a first-class feature, not a fallback
- Standard WIFI: QR format for network join, recognized natively by the iOS and Android camera apps — no custom scanner needed
No iOS browser supports Web Bluetooth at all — a WebKit-level restriction, not a background-mode limitation
→ Dropped BLE entirely for the web path rather than building a platform-specific fallback; the local-Wi-Fi mechanism works identically on iOS and Android through one code path.
A photographed QR code can be forwarded to someone outside the room and redeemed remotely
→ Moved the checkpoint check to a LAN-only endpoint hosted on the instructor's device — a forwarded screenshot has no route to a private local IP, closing the hole structurally instead of patching it with geofencing.
A background fetch() from the app's HTTPS page to the instructor's plain-HTTP local server is silently blocked by mixed-content rules
→ Caught in design review before implementation: checkpoint confirmation is done as a full page navigation instead of a background request, since mixed-content restrictions apply to subresource fetches, not top-level navigation.
RFID / smart-card swipe — a card tapped against a reader on the way in.
→ A card is transferable: hand it to a classmate and the system records you as present. Presence here is tied to a device already bound to one account, and re-checked at moments neither party knows in advance.
Biometric — fingerprint or face at a fixed station.
→ Hard to fake, but needs dedicated hardware in every room, queues at high enrolment, and still only proves you were at the door once. This needs no hardware beyond a laptop, and samples across the session rather than at entry.
Static QR / barcode — one code displayed or posted, scanned once.
→ A code is just an image: photograph it, send it to a friend at home, and they redeem it. Confirmation here requires reaching an endpoint that only exists on the room's network, which a forwarded screenshot cannot route to.
GPS / geofencing — device location checked against a radius.
→ Indoor GPS drifts well beyond a single room and is spoofable with mock-location tooling. Network reachability is a coarser signal about the world, but a much harder one to fake from a bedroom.
Single-ping Bluetooth or Wi-Fi check-in — one detection marks you present.
→ This is the closest relative, and the gap it leaves is the whole point: it detects arrival, not attendance. A device can be handed over or walked out the moment the ping lands. Repeated randomized checkpoints are what turn a single event into a sampled one.
Concept stage — three architectures designed and compared against the existing categories above. No code shipped yet, and no claim that any individual mechanism is novel; the open question is whether this particular combination measurably improves proxy resistance, which would take a built prototype and real testing to answer.