Where should the scan live? The architecture choice that shaped ARK

The privacy rule we built first

Before we wrote a single line of scanning code, we made a promise to ourselves: privacy-first meant on-device whenever technically possible. That's not marketing language. It meant real constraints on how we'd build.

The stalkerware detector became our first proof of concept. It examines installed apps, permission grants, and system behaviours that indicate surveillance software. All of that data lives on your phone already. Asking a server to do that work was slower, less private, and unnecessary. So it stays local, runs instantly, and never leaves your device even on the free tier.

But here's where it got complicated. Your breach history. Whether your email has surfaced on the dark web. Whether your credentials leaked in a specific incident. To answer those questions, we need to compare your data against global breach databases. You can't do that locally without downloading gigabytes of breach records to every phone. The server became essential, not optional.

That became our framework: local first for data processing; server only for external lookups we can't replicate offline.

The scans that forced us to choose

The Wi-Fi analyser lives in Shield for a reason. Your phone can see every wireless network within range, their security standards, whether they're broadcasting their name. That's all local data. We analyse it, score it, explain the risks. None of it needs a server request. We run it, return the result, done.

The password health check was trickier. We can't see your passwords (we don't ask for them, don't store them, couldn't access your password manager anyway). What we can see: how many apps have permission to send passwords over unencrypted channels, whether your device has weak authentication patterns, if your autofill is using outdated protocols. That analysis runs on-device because it's about your phone's behaviour, not external data.

Then came the DNS leak test. We needed to know if your DNS queries were leaking outside your VPN, if you're using one. That requires sending a request through your actual connection and observing where it arrives. It has to contact our server, but we've designed it so we learn only what we need: whether the leak occurred, not which domains you visited.

The phishing scanner (QR codes and URLs) was the one that surprised us. You'd expect cloud processing for something so complex. But most phishing attempts follow patterns we can detect locally: certificate anomalies, homograph attacks, known malicious domains we've pre-loaded in smaller, compressed sets. We use the server only when we're genuinely uncertain, not by default.

What Fortress scans revealed about scale

When we built Fortress, we had to reckon with data-broker exposure checks and the GDPR Autopilot. These require matching your personal information against external databases and submitting formal requests to third parties. There's no way around the server here.

But we got deliberate about what data leaves your phone and when. Your email, your name, any PII you add: these live in your device's secure enclave (iOS SecureStore, Android EncryptedSharedPreferences). They never travel as plain text. They're encrypted in transit. The server receives only what's necessary to run the check, then we discard it after the result is returned.

The SDK X-Ray scan was interesting because it sits in the middle. We can see which third-party libraries your apps use. That's local. But to tell you which SDKs are tracking you, selling your data, or using dark patterns, we need to compare against our knowledge base. That lookup happens server-side, but your app list never leaves encrypted.

GDPR Autopilot is purely server-driven because it's orchestrating requests to external organisations on your behalf. Your phone can't do that. But again: we structure it so the server sees only the minimum (your request type, your email, your chosen data categories) and nothing about your device itself.

The customer who changed how we think about latency

A few weeks into beta, someone messaged us saying the security credit score was perfect except for one thing: it took six seconds to calculate. Not because of slow logic, but because we were waiting for two separate server calls to complete in sequence. They ran a small business and checked their team's devices every Friday morning. Every second mattered in their routine.

We restructured the score calculation to run local first: permissions check, installed apps scan, device security settings, stalkerware presence. That runs instantly. Then we fire off the server requests (breach check, network exposure lookup) in parallel and update the score once they return. The user sees their initial score in under half a second now, with a loading indicator telling them we're fetching deeper data.

That single piece of feedback reshaped how we think about on-device versus server. It's not a purity test. It's about the user's experience. Run what you can immediately. Show progress while you fetch what you must. Never make someone wait for something their phone already knows.

What we learned about the middle ground

The hardest part of building ARK wasn't choosing on-device or server. It was accepting that most scans live in the middle. The breach checker contacts HIBP, but we cache results locally for repeat lookups. The dark-web monitor runs server-side, but we compress alerts so you're not re-downloading the same incident data daily. The voice-clone risk detector (checking if your voice might be mimicked by synthetic audio tools) uses a hybrid model: initial assessment happens on your device, deeper analysis happens server-side if triggered.

What we didn't do is chase purity at the cost of usefulness. Some founders in the privacy space argue that any server contact is a compromise. We think that's backward. A scan that's fast, private by default, and actually catches real threats is better than a theoretically perfect scan that's too slow to run regularly.

The test came when we built the two-factor authentication audit. It checks which of your accounts have 2FA enabled and how strong the method is. Your phone can see your installed authenticator apps and their patterns, but it can't know whether you've enabled 2FA on your email, banking, or social accounts without checking those services. We had to go server-side, but only to orchestrate requests you'd authorise anyway. The audit happens; the server learns nothing except what's needed to generate a score.