Back to Writing
January 15, 20268 min read

GPS-Locking & Anti-Spoofing: How We Verified Attendance in Class-io

An in-depth look at building spoof-resistant location verification systems on campus using averaged coordinate sampling, mock location detection, and network-time reconciliation.

Attendance verification software has a fundamental vulnerability: it assumes the device's location reports are honest. In a university environment, where students are highly motivated to find bypasses, standard location checks fail immediately. Students use mock-location developers tools, VPNs, or screenshotted QR codes to check in from their dorm rooms.

The Mock Location Problem

On Android and iOS, mock location APIs allow users to simulate GPS coordinates. Standard geolocation packages in Flutter or React Native will blindly report these simulated coordinates as the user's true location. To block this, we implemented direct native channel checks in Class-io to inspect the mock-provider flags at the operating system level, rejecting any request initiated while mock-providers are active.

Averaged Coordinate Sampling

A single GPS reading is highly susceptible to jitter and temporary spoofing. Class-io's checking protocol enforces a 5-second lock. During this period, the app collects multiple coordinate samples, calculates their variance, and computes the geometric mean. If the coordinate variance exceeds a set threshold, it indicates coordinates are jumping rapidly (often a sign of hardware spoofing tools), and the sign-in is blocked.

Rotational QR Timers

To prevent students from screenshotting the check-in screen and sharing it in group chats, Class-io employs a dynamic, rotating QR code that refreshes every 15 seconds. Each QR frame embeds a time-locked payload encrypted using AES-GCM. The server decrypts the token and checks the timestamp against NTP-synchronized network time. If the token is older than 20 seconds, the check-in is rejected, closing the loop on screenshot sharing.