What “no tracking” has to mean in 2026

“We don’t track you” has become decoration. It appears on sites that load four analytics libraries, on apps that ship an attribution SDK, and in privacy policies that describe the practice three paragraphs later. The phrase has no definition, so it can mean almost anything.

Here is the version we can actually be held to, applied to both the apps and this website.

Read it as a definition, because the shorthand is what gets abused. No tracking storage means there is no store of what you did: no event log, no persistent identifier, no profile accumulating on a server we control — and on this site, nothing written to your device either.

On this website

• No analytics. There is no Google Analytics, no Plausible, no Umami, no self-hosted counter. Page views are counted by the server’s access log and nothing else.
• No cookies, and therefore no consent banner. Nothing is stored on your device by the site. No local storage, no session storage, no fingerprinting canvas.
• No third-party requests. Fonts are served from this domain as self-hosted subsets. There are no CDNs, no embedded videos, no social widgets, no comment systems and no fonts loaded from Google. grep the page source: every request goes to prodevstudio.in.
• No ad or tracking pixels. Including the ones that come “free” with a font or an icon library.

That is a testable claim. Open devtools, filter by domain, and the network panel should show one origin.

In the apps

The apps go further, because they can:

• Analytics only behind a consent gate. ReelRoll and ScanLocker ship no analytics SDK. ScrollBreak’s free plan uses Google Firebase Analytics to understand which screens and challenges help and how the ads perform; collection is off until the advertising consent gate is answered, off after withdrawal, and never enabled on Pro. Event payloads carry no usage history, protected-app names, challenge content, moods or settings. Google Firebase Crashlytics provides crash stack traces and a few non-personal app-state keys on every plan. Neither is used for advertising or profiling.
• No account. There is no sign-up, so there is no profile, no email list, no password to breach.
• No cloud processing. ScrollBreak measures screen time with Android’s own UsageStatsManager. ReelRoll renders video with local FFmpeg. ScanLocker recognises text with on-device ML Kit. None of those need a server, so none of them talk to one.

The honest exceptions

Four of them, and none is hidden:

Billing. ScrollBreak Pro purchases are processed by Google Play and verified through RevenueCat. That means Google knows you bought something, and RevenueCat receives a purchase receipt and an app user identifier to validate it. No usage data, no content, no screen-time history — but it is a third party, and the privacy policy says so.

The Play Store itself. Installing and updating an app is a Play Store transaction. That is outside the app’s control and covered by Google’s policies, not ours.

Ads, in the ad-supported apps. ScrollBreak’s free plan carries one banner on the Challenges tab and an optional rewarded ad you choose to watch. ReelRoll and ScanLocker are free and ad-supported: native cards in list surfaces, plus a frequency-capped interstitial after an export or a completed scan flow. Ad requests carry no media, no document contents, no protected-app list and no screen-time history. ScrollBreak Pro makes no ad requests at all, because on Pro the ads SDK is never initialised. Every ad placement is behind a consent check and can be switched off remotely by the studio.

Telemetry, on ScrollBreak only. Crash diagnostics run on every plan so a crash can be fixed; free-plan product analytics runs only after the same consent gate as ads, and never on Pro. Both are described in the privacy policy (Section 10), both exclude the data the app exists to measure, and neither is used for advertising or profiling. If you want none of it, Pro is the switch.

Why this is a product decision and not marketing

Local processing is harder and slower. On-device OCR is a bigger download than an API call. A local render queue is a worse user experience than a farm of GPUs. Choosing local means choosing a worse benchmark and a better guarantee.

But there is a second-order benefit that is easy to miss: local-only removes whole categories of failure. There is no server to breach, no retention policy to misconfigure, no sub-processor list to keep current, no data-deletion request to fulfil. The data-safety form for these apps stays short — purchase history for ScrollBreak Pro, advertising/device identifiers for the free ad-supported apps, and ScrollBreak app interactions plus crash logs for the consent-gated analytics and diagnostics.

How to check a claim like this yourself

1. Read the network panel, not the privacy policy. Policy text describes intent; requests show behaviour.
2. Look for the consent banner. If a site asks for cookie consent, it is setting cookies.
3. Search the app’s APK for SDK names. unzip -l and a grep for firebase, crashlytics, adjust, appsflyer, facebook is crude and surprisingly effective. Finding Firebase in ScrollBreak is expected and disclosed; the question to ask is when it runs (only after consent, never on Pro) and what it carries (no usage history, no protected-app names, no challenge content).
4. Distrust “anonymised”. Aggregated telemetry is still telemetry, and the aggregation happens after collection.

A privacy claim should be a specification, not a mood. The specification for these products is short enough to read in a minute, and that is the point.