Why Our Screen-Time App Has a Privacy Policy That Reads Itself

A privacy policy is the part of the app that nobody reads and that everybody copies. The default version, in 2026, is a 4,000-word document that starts with "we may collect" and ends with "we may share with partners", and the parts in between are written by lawyers to be the same as every other privacy policy on the Play Store. The user is supposed to read it, decide whether to trust it, and either install the app or not.

The user does not read it. The user installs the app.

The policy we wrote for StepShield Pro is shorter, and the difference is the thing we want to talk about. The short version is in the on-boarding screen, in plain language, and it is the only version of the policy that exists. The 1,200-word version on the web is the same text with a few legal terms added, and it links back to the on-boarding screen. The user can read either one and end up at the same place.

What the policy says

The policy is six sentences, and the six sentences are the entire document. Here they are, in order.

1. StepShield Pro runs on your phone. The phone is the only place your data lives.
2. The data the app uses is the step counter, the foreground app, and the package name of the app you are trying to open. The data is read, used to decide whether to show the gate, and forgotten when the gate closes.
3. The app does not have an account. The app does not ask for an email, a phone number, or a name. The app does not have a server.
4. The app does not send your data anywhere. There is no analytics SDK, no crash reporter, no advertising SDK, and no third-party service of any kind.
5. The data the app stores on the phone is the step counter history, the gate configuration, and the list of apps you have blocked. You can delete this data from the app settings, and the data is deleted when you uninstall the app.
6. If you find a way to send data out of the app, that is a bug, and we want to know about it. The contact email is in the on-boarding screen and in the app listing on Google Play.

That is the policy. There is no "we may collect" because the answer is "we do not". There is no "we may share" because the answer is "we cannot — we have no server". There is no "by using the app you agree" because the user does not have to agree — the on-boarding screen is informational, not a contract.

Why we wrote it this way

A privacy policy is a legal document, but it is also a marketing document. The user is deciding whether to trust the app with the data on their phone, and the policy is the only place the trust gets expressed. A 4,000-word document that says "we may collect, we may share" tells the user that the answer is "yes, sometimes, depending". A six-sentence document that says "we do not" tells the user the answer is "no, ever, and here is the proof".

The proof is the absence of a server. The app does not have an account, does not have a server, and does not have an analytics SDK. The proof is verifiable — a user with a network monitor can confirm the app makes no outbound calls. The proof is also falsifiable, which is the point: if the user can verify the policy, the policy is true, and the user does not have to take our word for it.

The GDPR angle

GDPR is the reason the policy has to be specific. The default position under GDPR is that the data processor (the app) is responsible for the data subject (the user), and the data processor has to be able to prove what data they have, where it is, and who can see it. A 4,000-word document that says "we may collect" is GDPR-non-compliant because the controller cannot prove what they have. A six-sentence document that says "we have no server" is GDPR-compliant because the controller can prove, by inspection, that they have nothing.

The point is not that GDPR requires short policies. The point is that GDPR requires verifiable policies, and a verifiable policy is shorter than a non-verifiable one, because the verifiable one is the only one that is true. A non-verifiable policy is the one that says "we may" because the author did not want to commit. A verifiable policy is the one that says "we do" because the author knows.

What we did not put in the policy

We did not put "we may share with service providers" because we have no service providers. We did not put "we may collect device identifiers" because we do not. We did not put "we may collect approximate location" because we do not. We did not put "we may collect usage data" because we do not.

The omission is the point. A privacy policy that does not list the things it does not do is a privacy policy that is making a positive claim, and the positive claim is the one that has to be true.

The full app is StepShield Pro on Google Play: https://play.google.com/store/apps/details?id=com.appblocker.screentime.pedometer.workout.fitness.coaching. The privacy policy is on the same page. The on-boarding screen is the first thing you see when you open the app, and the six sentences are the first thing you see on the on-boarding screen.