The breach check story: why we integrated HIBP into ARK

The moment we realised breach data was fragmented

Before ARK, checking if your email had been compromised meant visiting Have I Been Pwned manually. And that was it. You'd get yes or no. But what you really wanted to know was deeper: is my compromised email affecting my phone right now? Am I in multiple breaches? What's the risk profile across all my accounts?

We spent a month researching breach notification services. Most were either enterprise-only, too expensive, or sitting behind paywalls. Troy Hunt's HIBP was the exception. It's free, it's comprehensive, and it takes the breaches seriously. We reached out, got permission to integrate their API, and started building.

How the check actually works (and what you won't see)

When you enable the breach check in the Shield tier, ARK connects to HIBP. It sends your email address, but here's what matters: the lookup happens through their k-anonymity protocol. That means HIBP never sees your full email hash. Your phone queries HIBP for partial hashes, gets back a list of candidates, and matches locally. No full identifier leaves your device unnecessarily.

If you're in a known breach, ARK tells you which one, when it happened, and what data was exposed (email, passwords, names, phone numbers, payment cards, whatever the breach included). But ARK doesn't store the full breach report in the cloud. That lives on your device, encrypted in iOS SecureStore or Android EncryptedSharedPreferences. We treat your breach history the same way we treat your security score: as yours, not ours to analyse.

The data privacy tension we had to solve

Building this feature forced us to answer a hard question: if we're checking breaches, do we also store email addresses in the cloud to improve detection speed or historical tracking?

We said no. Even though it would have made our backend simpler and faster. Email addresses are PII. The moment we start storing them (even encrypted), we become a target. We'd need insurance, compliance audits, and a much heavier infrastructure. More importantly, it felt wrong. Users come to ARK because they're tired of apps hoovering their data.

So we built it properly: email is encrypted locally. Breach checks are on-demand. Historical breach data is versioned on your device, not synced to our servers. If you uninstall ARK, your breach history vanishes with it. That's the privacy-first choice, even if it costs us some convenience.

What happens after you're flagged

The breach check isn't just a notification. It's the start of a remediation chain. When ARK detects you're in a breach, it shows you the one-tap options relevant to that specific exposure. If the breach included passwords, we flag it. If payment cards were compromised, that's highlighted. Then there's a deep-link to change your password directly in the affected service (where possible) or to the platform's security page.

For people who've been in multiple breaches (which is more common than you'd think), ARK bundles them. You see the full picture. Then you can prioritise. The customer who emailed us was in four breaches. She didn't need a link for each one. She needed to see them all at once and decide whether to contact companies directly or move on.

Why HIBP and not a proprietary database

We could have built our own breach database. Scrape forums, aggregate leaks, maintain our own index. Venture capital would have loved that story. But we'd be a year behind HIBP, less accurate, and responsible for keeping it updated forever. That's not what we do.

Troy Hunt's work on HIBP is forensic and careful. He verifies breaches before they go live. He's transparent about sources. Using HIBP meant we could focus on the phone side of the problem: how do we make breach awareness useful and actionable on a device that most people carry without thinking about security at all?

It also meant we could be honest. If there's a gap in breach data, that's a limitation of the data source, not ARK. We don't have to pretend to have answers we don't have.