Privacy-first time tracking on a Mac: what to look for
· 6 min read
A privacy-first time tracker is one whose worst case is boring. That means it records the least it can (app names, not window titles or screenshots), asks for no macOS permissions, keeps its data in a file on your Mac that you can open and delete, needs no account, and has no way to send anything anywhere. You can check every one of those in ten minutes before you commit to the app, and this post shows how. Marketing that says “we respect your privacy” is not on the list; what the app does is.
Start from the worst case
“Privacy-first” is a claim about what an app does. The useful question is what could happen if the app, its developer, or whoever buys the developer later, turned out to be careless. A tracker that collected window titles and uploaded them to a dashboard has a bad worst case: a database somewhere holds every document name and site you had open for years. A tracker that records app names into a file on your Mac and cannot talk to the network has a worst case of “someone who already has your Mac can see you use a browser a lot”.
Every check below shrinks the worst case. Work through them in order; the first two rule out most of the field.
Check 1: what it records
Trackers sit on a spectrum. From least to most:
- Which app is in front, and for how long
- Plus window titles (document names, page titles, email subjects)
- Plus URLs from the browser
- Plus periodic screenshots
- Plus keystrokes and mouse activity, usually framed as “idle detection”
Find where the app sits. The product page will often say, and if it does not, the permissions it asks for will (check 2). App names alone are enough to answer “where did my day go”. Everything after that is for someone else’s question: a per-document bill, a manager’s report, a productivity score. Why most time trackers want your window titles, and what that means is about the second rung, which is where most trackers live.
Check 2: which permissions it asks for
On a Mac, the permissions are the honest signal, because the app cannot read titles, screens or keystrokes without them.
- Install the app and watch what it asks for on first run.
- Open System Settings, Privacy & Security.
- Look for the app under Accessibility, Screen Recording, Input Monitoring and Full Disk Access.
- If it appears under none of them, it can see app names and nothing more. If it appears under Accessibility, it can read titles and keystrokes. If it appears under Screen Recording, it can see your screen.
A tracker that asks for no permissions is not being modest; it has chosen a design that cannot see more than app names, and that design cannot quietly change in an update without a new prompt. What Mac apps can see about you, permission by permission is the full map.
Check 3: where the data lives and whether you can read it
Local-only is the baseline. Beyond that, look for a data file you can find, open and understand.
- Ask the product page where data is stored. A specific path is a good sign; “securely” with no path is not.
- Find the file. Most apps keep data under ~/Library/Application Support/, in a folder named after the app. In Finder, press Command-Shift-G and paste the path.
- Check the format. A SQLite database or plain files you can open with free tools mean the record is yours in practice, not just in the terms. An encrypted blob you cannot read is only private from you.
- Check for an export. CSV is the one that matters, because it outlives the app.
Where Mac apps keep your data and how to find it walks through this for any app.
Check 4: accounts, networking, and how you delete it
An account means a server holds something about you, even if it is only an email address and a license. A sync feature means the server holds the data too. Neither is a deal-breaker for every app, but for a tracker, both enlarge the worst case for no benefit to the question “where did my day go”.
The strongest version of this check is an app with no networking code at all. You can test for it: an app with no networking code, what that means and how to check shows how to look inside the app bundle for networking symbols, and how to check what an app sends over the network on a Mac shows how to watch for connections while it runs. An app that passes both cannot phone home, because there is nothing to phone with.
Privacy also includes the ending. Look for a delete-everything control inside the app, not a support email, and check that it actually empties the data file from check 3. An app that makes deletion easy is an app that does not consider your history an asset.
What this looks like in practice
Punchcard was built to pass all four checks, and you can verify each rather than take it on trust. It records app names only, never window titles, document names, URLs, keystrokes or screen contents. It asks for zero macOS permissions and appears in none of the Privacy & Security lists. Its data is one SQLite file at ~/Library/Application Support/Punchcard/punchcard.sqlite, exportable as CSV from Settings. There is no account, no cloud, no analytics and no crash reporting, and the app contains no networking code: the release build fails if a networking symbol appears, which is a stronger guarantee than a policy. “Burn the roll” in Settings deletes everything, with no undo.
What it gives up to get there is real. It cannot tell you which document or which site, so it has no per-project or per-client tracking, no billable rates, no invoicing, no team reporting and no sync between Macs. It prints a receipt of the day at your closing time, itemized by app, and that is the entire feature list. If the question is “where did my day go”, that is enough. If the question is “how do I bill this client per document”, a privacy-first tracker in this sense cannot answer it, and it is better to know that than to be sold otherwise.
The checklist, on one line: records app names only; asks for no permissions; stores data in a file you can find and read; needs no account and has no networking; deletes everything on request. Ten minutes, and the answer does not depend on anyone’s privacy policy. Reading a privacy policy for a Mac app: the six lines that matter is there for the cases where you still have to read one.
Questions
Is local-only storage enough to call a tracker privacy-first?
It is necessary, not sufficient. A local database of window titles and screenshots is still a detailed record of your work, and it is one stolen laptop away from being someone else’s. What the app records matters as much as where it puts it.
Can a privacy-first tracker still give me detailed reports?
At the app level, yes: time per app per day, week and month, exportable to a spreadsheet. At the document or site level, no, because that detail requires the permissions a privacy-first tracker refuses. That is the trade, and it is a fair one to decline if you need the detail.
How do I know the app will stay this way after an update?
You cannot know for certain, but the permission model helps: if an update started reading titles, macOS would prompt for Accessibility, and you would see it. An app with no networking code would also have to add some, which you can check for again with the same tools.