Why we built breach check into ARK using HIBP

The breach question nobody was asking

Here's the thing about breaches: most people suspect they've been caught in one. The average person has been in at least two or three by the time they hit their thirties. But suspicion and certainty are different animals. We were building ARK to give people a real security score for their phone, and the question kept nagging us. What good is knowing your device is locked down if you don't know whether your personal data is already floating around on the dark web?

The customer who emailed us wasn't asking for much. She'd seen our early beta, liked the permission audits and the stalkerware detector, but she wanted one more thing: a way to check if her email address or phone number had been caught in known breaches. She'd reset her passwords after learning about the LastPass breach, but didn't know where else she might be exposed.

We realised we were only telling half the story.

Building vs borrowing: why we chose HIBP

The obvious path would have been to build our own breach database. We'd have the data, the control, and we could market it as proprietary. But that would have been foolish, for three reasons.

First, Have I Been Pwned already does this better than anyone else on earth. Troy Hunt's been maintaining that database since 2013. He verifies breaches, integrates new leaks, and has the trust of the security community. Competing with that seemed like reinventing the wheel while ignoring the fact that the wheel works.

Second, our strength isn't in scraping the internet for leaked datasets. It's in connecting the dots on your phone. Permissions, network exposure, app behaviour, stalkerware, phishing links. We're good at understanding what's happening on your device right now. HIBP is good at telling you what happened to your email address five years ago in a breach you've never heard of. Those are two different problems.

Third, and this mattered most, we wanted to keep your personal data off our servers. Privacy isn't a feature for us. It's a boundary. When you run a breach check in ARK, your email or phone number stays on your device. We hash it and send the hash to HIBP's API. Their system checks it against their database and returns a yes or no. We never see the plaintext. We never log it. Your sensitive information never leaves your phone unless you explicitly share it.

The integration that almost broke us

HIBP's API is elegant, but integrating it into a mobile app that wanted to be genuinely private created some real headaches. The obvious approach, checking your email every time the app opened, would have meant constant API calls and potentially logging activity on our backend that we wanted to avoid. We also needed to handle network failures, rate limits, and the case where a user is checking breaches on a device they share with family members.

We spent weeks thinking about what 'one-tap' really meant. It couldn't mean 'tap and wait three seconds while we hit an API and hope your connection holds'. It had to be instant. So we built local caching, offline functionality, and a smart refresh system that respects both your data plan and HIBP's limits. The first version was overengineered. The second version was too simple. The third version shipped, and we've been refining it ever since.

One of our early users caught a bug we'd missed entirely. They were checking their partner's device and got different results than on their own phone. Turned out we weren't handling cached hashes correctly across multiple profiles on the same device. That fix took a day, but it taught us something: breach checking isn't just a feature. For some people, it's an act of care.

What we learned about why people care

Before we launched breach check, we thought it was purely functional. You check, you learn you're in 47 breaches, you change your password. Done.

That's not how it actually works. We started reading support emails after launch, and a pattern emerged. People don't just want to know about their breaches. They want to understand them. They want to know which service screwed up. They want to know if the breach included their address, their phone number, their payment card, or just their email. They want a timeline.

The breach check in ARK sits inside the Shield tier, alongside dark-web monitoring, password health, and Wi-Fi analysis. It's not about giving you a single answer. It's about building a complete picture of your exposure. We score it. We explain it. Then we give you a deep-link to whatever you need to fix it. For most people, that's a password reset. For some, it's a fraud alert with their bank. For others, it's just the relief of knowing they're not in as many breaches as they feared.

The feature that started with one customer's email has become something people rely on to understand themselves better. That's worth the complexity.

Why third-party integrations matter more than you think

There's this belief in tech that everything worth doing should be built in-house. That bootstrapping and owning your stack makes you faster, stronger, independent. Sometimes that's true. But sometimes it makes you slower and worse.

We could have spent six months building our own breach database. We could have spun up a team to monitor leaks, verify datasets, and keep the information current. We'd own it. We'd have full control. And we'd probably have something 70% as good as HIBP, used by millions, maintained by a security expert who's dedicated his career to this single problem.

Using HIBP meant we could focus on the thing we're actually good at: making your phone transparent and understandable. It meant we could add breach checking to our roadmap without adding headcount. It meant we could integrate a service that billions of people already trust, rather than asking users to trust us to get it right.

Integration doesn't mean we're less serious about security. It means we're serious about your time and your data.