Recover stolen Chromebooks. Without surveilling the ones in use.
A kiosk Chrome App that launches only on a Chromebook a district administrator has marked stolen. It captures location and the kiosk’s own screen to support recovery, and stops the moment the device is marked recovered. It never runs on a device in normal use, and it never opens the webcam.
Districts lose Chromebooks every week. Most never come back.
For a 5,000-device district, even a 1% loss rate is 50 devices a year. The industry default is to deprovision and write off the loss, because the alternative was either an always-on agent on every device in the fleet, or no recovery at all. We built a third option: a tool that exists only on the device that has been reported stolen.
Sources: Chalkbeat Chicago and CBS Chicago on the CPS Inspector General’s FY2023 report, January 2024; WHYY, August 10, 2026. None of these figures are UserAuthGuard results.
How recovery works
Four steps. The district starts it, the district ends it, and every step is logged.
Admin marks stolen
From the device detail page in the UserAuthGuard dashboard. Records reason, reporter, optional police case number. Audit-logged.
Device moves to /StolenDevices
An OU with sign-in disabled and the kiosk app set to auto-launch. Effective on next reboot, usually within minutes.
Kiosk launches, captures begin
The district chooses the mode. In visible mode the screen shows a “return this device to school” banner with a phone number. In covert mode it shows a plain browser surface. In both, location and screenshots of that kiosk surface relay to your dashboard.
Recovery or purge
Real recovery: data archives for 30 days then purges. False positive ("kid borrowed it"): one click purges the captured data immediately.
What Theft Recovery never does
The privacy story is the product. Every restriction below is contractually committed in our Data Processing Agreement, Article 6.5.
No webcam capture
The kiosk’s manifest declares no camera or microphone permission, and the code calls no media-capture API. There is nothing to switch on.
No keystroke logging
No global keyboard hooks, no input event capture, no IME interception.
This kiosk app cannot reach a device in normal use
Google only auto-launches a kiosk app where the organizational unit’s policy says so, and that policy exists only on /StolenDevices. A device in normal use never loads it.
No persistent local storage of captures
Screenshots and location relay to your tenant in real time. No sensitive data is left on the device.
No retention beyond 30 days
Hard ceiling. Earlier purge on recovery confirmation, immediate purge on false-positive recovery.
No third-party data sharing
Captures live in your tenant only. We are a processor, not a controller. No analytics resale, no model training.
Already using GoGuardian Beacon?
You can reasonably do both. The honest comparison:
Where Theft Recovery is different
- Activates only on stolen-marked devices, not the whole fleet
- Webcam permission is not declared in the manifest
- 30-day retention ceiling, with a "purge on false positive" path
- Auditable in-product: every dispatch writes to your activity log
- Part of UserAuthGuard, so the device record, the audit log and the recovery live in one place
Built for the K-12 procurement gauntlet
Pre-signed paperwork. The same DPA covers the rest of UserAuthGuard, so legal review is one round, not three.
FERPA
Education records covered under §99.31 school official exception.
COPPA
School-consent provision (16 CFR 312.5(c)(3)). Captures are device-bound and session-bound; incidental captures of a non-thief are purged on false-positive confirmation and never used for discipline.
SDPC NDPA
Standard student data privacy addendum compatible.
State laws
Aligns with NY Ed Law 2-d, CA AB 1584, IL SOPPA, NJ NJSA 18A:36-35 et al.
Ready to stop writing off stolen devices?
Pilot rollouts run 30 days, no commitment, with white-glove setup of the /StolenDevices OU on your district's Google Workspace.