Reading a privacy policy for a Mac app: the six lines that matter

· 6 min read

You do not need to read a privacy policy; you need to find six sentences in it. What is collected, why, who it is shared with, where it is processed, how long it is kept and how to delete it, and what happens when the policy changes. Each is usually one line, often buried in a paragraph written to be skimmed past. Find those six, check them against what the app actually does on your Mac (its permissions, its network traffic, its files), and you know more than most people who read the whole thing.

Lines 1 and 2: what is collected, and why

Privacy policies are long because they are written for regulators, not for the person deciding whether to install an app. The same template serves a photo editor and an ad network, so it lists every category of data the law recognizes whether or not the app touches it. The six lines below are the ones that constrain behavior. Use your browser’s find command (Command-F) to jump to them; the search terms are included.

For the first line, search for “collect,” “information we,” “data we.”

You are looking for nouns: email address, name, device identifier, usage data, “content you create,” crash reports, IP address. The list is usually honest, because regulators check it. Two phrases deserve a pause:

  • “Usage data” or “analytics.” The app reports what you do inside it to a server. For a time tracker, this can mean the app that records your day also reports on how you use it.
  • “Content” or “user content.” The things you make in the app are collected, which for a note app, a tracker or a messaging app is the data you care about most.

If the line says the app collects nothing, keep reading; the later lines either confirm it or quietly contradict it.

For the second line, search for “purpose,” “use your,” “in order to.” The purposes tell you where the data goes next. “To provide the service” is the minimum and is fine. “To improve our products” usually means analytics. “To personalize” or “to communicate offers” means marketing. A purpose with no corresponding feature in the app is a data flow you cannot see.

Line 3: who else receives it

Search for “share,” “third part,” “service providers,” “partners.”

This is the line most people skip and the one that matters most. Every third party named here is another company with a copy of your data, under its own policy. Common entries:

  • Analytics and crash-reporting providers. The app bundles their code, and it runs on your Mac. The policy may not name them, which is why the network check in how-to-check-what-an-app-sends-over-the-network-on-a-mac.html is useful.
  • Hosting and cloud providers. Ordinary for any app with an account.
  • Payment processors. Ordinary for anything you buy.
  • “Advertising partners.” In a paid Mac app, this should not appear at all.

A policy that says “we do not share your data” and also lists analytics providers is contradicting itself. The list wins.

Line 4: where it is processed

Search for “stored,” “processed,” “servers,” “on your device,” “transfer.”

The question is whether the data leaves your Mac. Three answers:

  1. On device only. The policy says data is stored locally and not transmitted. This is the strongest position, and it is checkable: the app should have no account, and the network checks should show nothing.
  2. On the developer’s servers. Normal for sync and accounts. Look for which country, and whether it is encrypted in transit and at rest.
  3. On third-party servers. The data is wherever the providers from line 3 keep it.

For a tracker that holds a record of your workday, the difference between the first and the other two is the difference between data you can find and delete in ~/Library and data you have to request. time-tracker-data-where-it-lives-and-who-can-read-it.html goes deeper on this for trackers specifically.

Lines 5 and 6: retention, deletion, and what happens on change

For line 5, search for “retain,” “retention,” “delete,” “your rights,” “request.” Two things to find. First, the retention period: “as long as necessary” means indefinitely, “until you delete your account” is better, a stated number of days is best. Second, the deletion route: an in-app option, an account setting, or an email address. A policy with a deletion right but no mechanism is a right you will have to fight for.

Note what cannot be deleted. Analytics data is usually described as aggregated or anonymized, which in practice means it will not be removed on request. It is permanent, so it belongs in your decision before installing rather than after.

For line 6, search for “changes to this policy,” “update this policy,” “notify.” Every policy reserves the right to change. The line to find is whether you will be told: an email, an in-app notice, or merely “the date at the top of this page.” If the notice mechanism is the date on a page you will never revisit, the policy you read today is the policy for today only.

The contact line is usually next to this one: the email address for privacy questions and deletion requests. Copy it somewhere; it is the line you will need in a year.

Then check the policy against the app

A policy is a claim. Three checks on your Mac confirm or contradict it:

  1. Permissions. Open System Settings, Privacy & Security, and look for the app under Accessibility, Screen & System Audio Recording and Full Disk Access. A policy that says the app collects only “app usage” while the app holds a permission that reads window titles has left something out. what-mac-apps-can-see-about-you-permission-by-permission.html explains each one.
  2. Network. Watch the app in Activity Monitor’s Network tab for ten minutes of normal use. Line 4 said on device only? Sent Bytes should not move.
  3. Files. Find the app’s folder in ~/Library/Application Support or Containers and look at what it stores and in what format. Line 1 said app names only? The database should not contain document titles.

Where the policy and the Mac disagree, the Mac is right.

What a short policy can tell you

Punchcard is an app where the six lines collapse into a few facts, which is the point of building it that way. The app records app names and time per app, stores them in one SQLite file at ~/Library/Application Support/Punchcard/punchcard.sqlite, and contains no networking code, so nothing is transmitted, shared or retained anywhere but that file. There is no account to delete; “Burn the roll” in Settings deletes the file. The one place your information touches the internet is buying a license on the website, where an email address is needed to send the key, and that is a purchase transaction rather than anything the app does. You can verify each of those with the three checks above: zero permissions listed, zero bytes sent, a database with no window titles in it.

The limits are plain too: without a server there is no sync between Macs, no web dashboard, no team view. If those are what you need, you will be choosing an app with a longer policy, and the six lines are how to read it.

Questions

Is the App Store privacy label enough instead of the policy?

It is a self-reported summary of lines 1 and 3. It does not cover retention, location or deletion, and apps sold outside the App Store have no label. Read it first, then find the six lines.

What if the policy is for the developer’s website, not the app?

Common, and a warning sign. A policy about cookies and web forms that never mentions the app has not told you what the app does. Email the contact address and ask; the answer is itself information.

The policy says data is “anonymized.” Does that mean it is safe?

It means a direct identifier was removed. A minute-by-minute record of which apps you used is identifying on its own to anyone who knows you. Treat “anonymized activity data” as activity data.

How often should I re-read a policy?

When the app adds an account, a sync feature or a “help us improve” toggle, or when an update asks you to accept new terms. Otherwise the three checks on your Mac, repeated after major updates, catch changes faster than re-reading.