“On-device” shows up in almost every privacy pitch now. Photos apps say it. Keyboards say it. Email clients, including STAMP, say it. The term is doing a lot of work, and most companies do not explain what it actually means or how you could check.
This post defines the term precisely, then gives you steps to verify it yourself, for any client, not just ours.
What “on-device” means
On-device processing means a computation happens on your Mac, using your Mac's CPU or Neural Engine, without sending the input data to a server first.
That is the whole definition. It is narrower than it sounds. A feature can be “on-device” and still be a privacy problem if:
- The output of that computation gets uploaded afterward (classify locally, then send the label and the email to a server anyway).
- The model itself was trained on data it should not have had.
- Some parts of a feature are on-device and others are not, with no clear line drawn between them.
So the term alone tells you less than it sounds like. What matters is the full data path, not just where one step of it runs.
The three questions to ask
When a company says “on-device,” ask:
- On-device for what, specifically? “AI features run on-device” is not an answer. Which features. All of them, or the fast ones only, with a cloud fallback for anything complex.
- Does anything leave the device afterward? The computation happening locally does not mean the result stays local. Check if analytics, logs, or a “quality improvement” pipeline uploads the output.
- What about the parts that are not classification? Search, sync, backup, and support tooling are often separate systems with separate rules. A client can be honest about on-device classification and still sync everything to a cloud backend for other reasons.
For STAMP specifically: classification (urgency, VIP sender, reply-needed, tone) runs on-device, full stop. Nothing about a message's content is sent to our servers for this or any other processing. We do not run a server-side index of your mail. There is no fallback that phones home for “hard” messages.
How to verify it yourself
You do not have to trust a claim on faith. Here is what you can actually check, in order of effort.
Read the privacy policy for specifics, not vibes. A policy that says “we care about your privacy” tells you nothing. A policy that says “email content is not transmitted to our servers for classification” is a falsifiable claim. Falsifiable claims are the ones worth trusting, because they are the ones you can catch a company breaking.
Run a network monitor while the app works. This is the most direct check. Tools like Little Snitch or the built-in Console.app + nettop combination let you watch every outbound connection a Mac app makes. Open your email client, let it classify a batch of new mail, and watch the traffic. If email content is leaving your machine, you will see connections to a classification API at the moment new mail arrives. If nothing fires during that window, that is real evidence, not marketing copy.
A rougher but free version: macOS's Activity Monitor has a Network tab showing sent and received bytes per process. It will not show you content, but a spike in outbound data exactly when mail is classified is a signal worth chasing with a proper monitor.
Check for a network-mode toggle or airplane-mode test. If a client claims classification is on-device, it should keep working (on already-synced mail) with wifi off. Turn off your network, open the app, and see if triage still functions on cached messages. If it breaks entirely, something about that pipeline needs a live connection, and that is worth asking the company about directly.
Look for a specific, falsifiable retraction promise. Companies that are confident in an on-device claim will say what happens if they are ever caught being wrong: a breach disclosure commitment, a bug bounty, a promise to notify users before any architecture change. Vague reassurance without a consequence attached is a yellow flag.
Ask what happens on your very first launch. Many “privacy-first” apps still send a batch of setup data (device info, account metadata) to a server during onboarding. That is normal and usually fine, but it is worth distinguishing from ongoing content processing. Watch network traffic during first launch too, and compare it to steady-state usage.
What honest transparency looks like
We think the standard is higher than a one-line claim. A company should:
- Say exactly which features are on-device and which are not, feature by feature.
- Publish what happens to model outputs after they are generated.
- Make it possible for a technical user to verify the claim with normal tools, not proprietary ones.
- Commit to notifying users if the architecture ever changes, before it ships.
We hold ourselves to this for STAMP's classification pipeline. Our changelog documents changes to how the app works, including anything touching data handling.
The honest caveat
Verification has limits. A network monitor shows you what leaves your Mac over the network it can see, not what happens inside a process, and a sufficiently determined bad actor could obfuscate traffic. What you are really evaluating is whether a company's incentives and public claims line up, and whether they have made it possible for you to check. That possibility, more than any single scan, is the real signal.
Where to go from here
For the deeper architecture behind our own classification pipeline, on-device email classification, explained. For what happens when you connect an account in the first place, IMAP, SMTP, OAuth, explained.
Verify, don't trust. hello@stamp.email