The 48-hour fix that changed how we store breach emails

Why a breach email is different from other app data

When you run a breach check in ARK, we pull your results from Have I Been Pwned and show you which of your accounts have been compromised. Straightforward. But here's the thing we'd overlooked: those email addresses, linked to specific breaches, are some of the most sensitive information a person can hand to their phone.

They're not just contact data. They're a map. Breach emails plus breach names tell someone exactly which services have exposed you, which means they know where you might have reused passwords, which platforms hold your financial data, your health records, your conversations. A single breached email connected to 23 different leaks is an instruction manual for targeted attacks.

We'd been storing this in AsyncStorage because it was convenient. Fast. Simple to query. The kind of decision that feels fine until it isn't. AsyncStorage on Android stores data unencrypted by default. On iOS, it gets some protection from the OS, but it's not the same as using the platform's built-in secure storage. A user with technical knowledge (or malware with system access) could extract those emails. Our Tuesday morning message proved someone was already thinking about it.

The moment we realised the shortcut had cost us

That user wasn't accusing us. They were testing. They'd found our code, looked at how we persisted data, and sent a message instead of a public disclosure. In a sense, they were giving us a gift: a private way to fix it before it became a problem.

What struck me wasn't the vulnerability itself. It was that we'd built ARK explicitly for people who'd been in data breaches, people who were already hyperaware of exposure risk, and we'd made a convenience decision that contradicted our entire product philosophy. We'd taken their breach history and stored it in the least secure place we could have chosen.

The security credit score ARK calculates is only useful if the app itself can be trusted with sensitive findings. You can't tell someone their device has a 65 score and that they need to audit their permissions if you're handling their own data carelessly. It's the equivalent of a doctor telling you to monitor your health while leaving your test results on a sticky note.

Moving to platform-native secure storage

We made a decision: breach emails, and any other personal identifiable information ARK collects during a scan, would move to iOS SecureStore and Android EncryptedSharedPreferences. These are the platforms' built-in secure storage solutions, designed specifically for this kind of data. Encrypted by default. Accessible only to ARK. Protected by the device's own security architecture.

The engineering work wasn't trivial. AsyncStorage had its hooks everywhere. Queries, cache logic, sync mechanisms. We had to trace through the breach detection flow, the results display, the remediation deep-links. But the timeline was the bit that mattered. We knew users deserved the fix immediately, not in a scheduled quarterly release. So we committed to 48 hours.

By Wednesday evening, our iOS build was ready. Android took a few extra hours for testing, but we had both platforms updated and rolled out to everyone by Friday morning. No maintenance window. Just a silent update that changed how your most sensitive breach data lived on your device.

What this meant for how we approach feature building

The whole thing taught us something we should have known already: convenience and trust are often direct trade-offs, and in a security product, trust always wins. It's easy to default to 'fast to implement' when you're shipping features. Harder to ask 'Is this the safest choice?' every single time.

Now we front-load that question. When a feature involves personal data, we start with the secure storage layer. We prototype against it. We don't treat encryption and platform-native storage as a 'nice-to-have' optimisation for later. It's part of the feature spec from day one.

For people using ARK's Shield tier (dark-web monitoring, breach checks, phishing scanning) and Fortress tier (data-broker exposure, GDPR Autopilot), this matters directly. You're trusting us with information about your digital exposure. Everything we learn from your scans stays on your device, encrypted by the platform. We don't build analytics into free-tier scans for exactly this reason: the information you're sharing with your phone shouldn't be shared with our servers unless you explicitly choose a paid tier that requires it.

The user who taught us to build better

We never found out who sent that Tuesday message. They didn't ask for anything, didn't request credit, didn't expect a reply. They just saw a shortcut and flagged it. That's the kind of person ARK is built for: someone who pays attention, who thinks about what data is where, who takes their own security seriously enough to help someone else get it right.

That's also the kind of person we need to be as a team. The kind that doesn't settle for 'it works' when 'it's secure' is possible. The 48-hour fix was fast, but only because we'd already decided that this wasn't the kind of problem worth optimising.