OneKapisch GitHub Another Universe ↗

English · 7 min · By Kapisch Bhardwaj

Auf Deutsch lesen →

What Privacy-First Software Actually Means

A testable way to read product claims, with OneKapisch examples

Audience: people choosing software and builders writing privacy claims

Time: 7 minutes

Last verified: 2026-08-27

“Privacy-first” should describe a product boundary you can inspect. It should not be a mood, a lock icon, or a promise that quietly excludes the most important data flow.

At OneKapisch, the useful question is not “Is this app private?” It is: Which data stays where, which data leaves, why, and under whose control? The answer can differ by product and by feature.

The six boundaries of privacy-first software: processing, storage, network, accounts, diagnostics, and retention.
The six boundaries of privacy-first software: processing, storage, network, accounts, diagnostics, and retention.
Read the infographic as text
  1. Processing: identify whether each operation happens locally or on a server.
  2. Storage: identify whether data stays on the device, enters platform sync, or reaches a third party.
  3. Network: name which feature connects, where it connects, and why.
  4. Accounts: state whether an account is required and which identifiers it needs.
  5. Diagnostics: disclose crash reports, analytics, telemetry, consent, and identifiers.
  6. Retention: state how long data remains and how it can be deleted.
  7. Different products can have different boundaries. Minimizer, Tokens 4 Breakfast, and SkyLocation are not presented as one shared architecture.

The six questions behind a credible claim

1. Where does processing happen?

Local processing means a task is performed on your device. Server-assisted processing means some input leaves the device so a remote service can perform the task.

Neither phrase is enough on its own. A locally processed result may still be synchronized, backed up, or logged later. A server-assisted feature may send a narrow request and retain nothing beyond what is required. The complete workflow matters.

2. Where is data stored?

Storage is separate from processing. Ask whether data is kept:

A credible explanation also says what happens after deletion and whether backups or system-level synchronization are outside the app's direct control.

3. Which network calls are necessary?

“Works offline” can describe a core workflow while optional features still use the internet. An app might work without a connection for saved data, then contact a map, weather, payment, update, or AI provider when you request a connected feature.

The honest claim names the offline scope and the online exception.

4. Is an account required?

No-account software reduces one common source of identity and behavioral data. It does not prove that the app makes no network calls or stores nothing elsewhere.

If an account is required, the product should explain why, which identifiers it needs, and how deletion works.

5. What telemetry and analytics exist?

Telemetry can mean crash reports, performance diagnostics, feature events, or detailed behavior. “No ads” is not the same as “no analytics.” “No tracking” should identify the definition being used.

The most useful disclosure names the tools, the events, whether collection is optional, and whether identifiers are attached.

6. How long does data remain?

Retention and deletion complete the boundary. If a server receives data, ask how long it remains in active systems and backups, who can access it, and what the user can delete.

If those answers are not documented, a strong claim should wait.

Three different product boundaries

OneKapisch does not apply one architecture to every product. Current approved records show three different patterns.

Minimizer: the narrowest boundary

Minimizer is recorded as an audited no-network, no-telemetry, open-source product. That supports a specific claim: the documented product does not need a network connection or analytics service for its function. 4

The claim is narrow on purpose. It says nothing about the security of the whole Mac, operating-system backups, or future versions.

Tokens 4 Breakfast: local records, connected refreshes

Tokens 4 Breakfast keeps usage records on the Mac, while live provider refreshes connect to the selected provider services. 2

Calling the entire product “offline” would hide that dependency. Calling it “cloud-based” would hide the local storage model. The accurate description includes both.

SkyLocation: offline core, optional online maps

SkyLocation's core GPS and bundled offline place context can work without connectivity. Optional map tiles can still require an internet connection. 3

That boundary is useful to a traveler: the location workflow can keep functioning offline, while the richer map layer has a separate dependency.

Sometimes privacy-first means withholding the claim

The current claims policy blocks any “local-only” statement until server purpose, retention, and deletion paths are documented. 6

That is not a marketing weakness. It is how a verifiable standard should work. If a material part of the data path is unknown, the claim remains unpublished until the evidence exists.

A practical claim format

Use this structure instead of a broad badge:

What stays local: the data and operations that remain on the device.

What goes online: the exact feature, destination, and minimum data sent.

What is stored: local and remote retention, including user controls.

Accounts and identifiers: whether they are required and why.

Diagnostics: crash reporting, analytics, telemetry, and consent.

Known limits: platform services, backups, third parties, and unverified areas.

OneKapisch's editorial principles already separate local processing, local storage, online dependencies, telemetry, and accounts. 5 The next step is to make those boundaries visible beside every product claim.

How to evaluate another product in five minutes

  1. Read the privacy policy and the product page together.
  2. Search for account, analytics, crash reports, retention, subprocessors, and deletion.
  3. Check whether an offline claim includes optional online features.
  4. Separate developer-controlled servers from operating-system and third-party services.
  5. Look for a dated technical explanation, not only a slogan.
  6. Treat silence as unknown, not as proof of no collection.

A good product may still use a server. Privacy-first engineering is about reducing unnecessary exposure, stating necessary dependencies, and giving the user meaningful control.

Limitations and what this label does not guarantee

Primary sources and evidence

  1. 1Approved OneKapisch claims registry
  2. 2Tokens 4 Breakfast product boundary
  3. 3SkyLocation product boundary
  4. 4Minimizer product boundary
  5. 5OneKapisch privacy principles
  6. 6Withheld claims policy

Last verified: