Why we built Evidence Locker with biometric lock
Three weeks after Hawk launched, a user emailed me with a problem I hadn't anticipated. His phone had been stolen from his car while the app was running. He got it back, but the thief had deleted his footage from an accident that morning. He could still prove the collision happened because of SHA-256 integrity hashes (we write one to every clip), but the moment was gone. He asked a simple question: what if someone steals my phone again?
The moment we realised physical security matters
That email stayed with me. Hawk's purpose is to protect drivers, but we'd built a system where the evidence itself was unprotected once someone had access to the phone. For rideshare drivers especially, whose phones are in the car all day, that's a real threat.
We'd already thought about privacy. The Evidence Locker was there from day one. You could mark clips as important, and they'd be separated from your daily recordings. But separation isn't security. If someone picks up your unlocked phone, they can delete the locker just as easily as they can delete any other folder.
The insight was simple: if evidence matters enough to keep, it matters enough to protect.
We looked at how secure facilities handle this. The best approach isn't a password (people write them down, reuse them, forget them). It's something you have with you always. Your fingerprint. Your face. Something that fails closed, not open.
Building fail-closed, not fail-open
The biometric lock we shipped for Evidence Locker was designed around one principle: if authentication fails, the locker stays locked. Full stop.
That sounds obvious, but it's not how many security features actually work in practice. Some apps will let you retry endlessly. Others have fallback methods (a PIN, a recovery code) that undermine the whole point. We didn't want that.
When you access Evidence Locker, your phone asks for your fingerprint or face. If it doesn't match, the locker doesn't open. There's no backdoor through the app settings. There's no override code. The footage inside stays encrypted and inaccessible without biometric confirmation. Full stop.
That design choice meant we couldn't offer a "forgot password" flow. But that's actually the point. The person who carries the phone is the person who accesses the evidence. No exceptions.
Why this matters for rideshare drivers
Rideshare drivers were the first people we thought about. They spend eight to twelve hours a day with their phone in the car. Their phone is visible to passengers. It's a target.
If someone takes your phone, even briefly, they can wipe your phone entirely. But if your accident footage is in Evidence Locker with biometric lock, it survives that. They can't delete it. They can't export it. They can't do anything with it.
That changes the math. It means footage from an incident where a passenger claims injury (when nothing happened), or where another driver fled the scene, stays safe even if your phone ends up in someone else's hands.
For Rideshare Pro users, this is more critical. Cabin camera footage is sensitive. Passengers trust you with their privacy. Biometric lock means that footage doesn't leak if someone steals your phone or if you lose it in a ride.
The engineering side: why it took longer than we thought
Biometric lock sounds simple. Your phone already knows how to check your fingerprint. Surely you just call that API and move on.
The complication was in the implementation. We needed the locked clips to stay encrypted at rest. That meant not just gating access with a fingerprint check, but ensuring that the files themselves couldn't be accessed, copied, or exported without that biometric confirmation. We couldn't rely on iOS or Android file permissions alone.
We also had to think about recovery. What happens if someone breaks their phone and gets a replacement? They wouldn't be able to unlock clips from the old device. So we built iCloud sync for locked Pro clips on iOS. Your Evidence Locker is tied to your Apple ID, not your device. If you switch phones, the clips are waiting for you. On Android, we use a similar pattern with account-based recovery.
The other detail nobody really thinks about: what if the biometric sensor breaks? Your phone becomes a brick for evidence access. We designed the system so you can still view clips from the device itself (the sensor works most of the time), but you can't export them. The export step requires biometric confirmation. That forces a decision: take it to a repair shop and mention this feature, or live with it. Neither is ideal, but both keep the evidence safe.
Evidence grade, not just a safety feature
The deepest reason we built this was about evidence integrity. Hawk's entire purpose is to give you footage that courts and insurance companies will actually accept.
That starts with SHA-256 hashes. Every clip is cryptographically signed. If someone tampers with the footage, the hash breaks. Evidence rejected.
But hashes only work if you can prove you didn't hand the phone to someone else and let them delete the clips. Biometric lock proves that. It shows intent. It shows you took reasonable steps to protect the evidence. That matters to a claims adjuster or a judge.
When you export a dispute to ZIP (one tap, with the SHA-256 manifest inside), that's your proof. You recorded it. You protected it. You didn't let it get deleted. The insurance company can verify the hashes. The police can review the GPS overlay and timestamp. The courts can see the manifest. Everything holds up.
The user who emailed me that first question got his phone back and never needed the Evidence Locker. But I think about what would have happened if someone else had picked it up. Your evidence is only as secure as the device you're holding. Shouldn't it be protected like evidence should be?