A Notification History Is the Most Sensitive File on Your Phone

Open your notification history for a single week and you are looking at more than alerts. There is the pharmacy confirming a prescription, the bank naming the amount of a transfer, a delivery app with your address in the preview line, a message from someone you have not told your family about yet, and a two-factor code that still works if someone reads it fast enough. None of that was written for an audience. It was written to reach you for a second and then disappear. A history app keeps it instead, which is exactly why notification history privacy is not a footnote to the feature, it is the feature.

Most of the attention around notification apps goes to what they can resend or how far back they search. The harder question is where that data sits once it exists, and who besides you can ever read it.

What a week of notifications reveals

A single notification tells you little. A week of them, sorted by app and time, reads like a loose diary: when you are awake, which bank you use, which pharmacy, which delivery services, who you talk to and roughly how often, and which apps you keep muted because you already know what they say. None of that requires reading a message twice. It falls out of the titles and preview lines alone, the same way a phone bill reveals a life without recording a single call.

That is also why we wrote about what an app with notification access can actually read before we wrote this post. The permission that lets an app build a useful history is the same permission that lets it build a profile. The two are not separable at the Android level. What separates them is what the app does with the copy once it has it, and that is a decision every notification history app makes once, early, and then lives with.

The cloud question and why we answered no

A searchable history that survives a factory reset is a reasonable thing to want, and the obvious way to build it is a server: sync the data up, restore it on the next device, done. We looked at that design and did not build it. A server means a copy of your notification history exists somewhere we control, which means it exists somewhere a subpoena, a breach, or an employee mistake can reach. Promising to never look is not the same as being unable to look, and for data this personal, the difference is the whole point.

A local first android app makes the second promise instead of the first. ReNotify keeps the history in a database that lives only on your device. There is no account to create, nothing to sign into, and no copy anywhere else to protect, lose, or hand over. Uninstalling the app removes the database with it, the same way clearing a drawer empties it. We cannot read a history we never receive, which is a stronger guarantee than a policy promising we will not look at one we do.

What local first costs you

This choice has a real price, and it is worth naming rather than hiding. A history kept only on the device does not follow you to a new phone automatically. Switch devices and the old history stays on the old device unless you export it yourself first. There is no "sign in on your new phone and it is all there" moment, because that moment requires a server holding the data in between, which is the exact thing we chose not to build.

The export matters for a second reason too. If you ever want your own copy outside the app, as a record or just as a backup you control, the data has to come out as a file you asked for, not a login you remember. That is more friction than a cloud sync offers. We think it is friction worth keeping, because the alternative moves the decision about where your data lives from you to us.

Backups are part of the threat model

Keeping data off our server only covers half the question, because Android has its own backup system working in the background. Many apps get their data copied to the user's Google account automatically unless the developer explicitly opts out, so a database that never touches our servers could still end up copied to a cloud account through a mechanism that has nothing to do with us. That copy would carry the same notification data, just routed through a different door.

ReNotify opts out of that system entirely. Its data is excluded from Android's automatic backup, so the only copy of your history that can exist is the one on your device, unless you export one yourself. A threat model for notification data privacy that only covers the app's own servers and ignores the phone's backup system is covering half the problem. The other half is a setting, and it has to be set correctly by the developer, not assumed.

How to audit any app that keeps this data

You do not need to read source code to check whether an app keeping your notifications is honest about where that data goes, though you can read ours, since ReNotify is open source and the listener service that touches your notifications is a few hundred lines anyone can look at. Short of that, four checks work on any app in this category.

• Read the privacy policy for the word "server" or "sync", not for the word "privacy". A policy can use the second word generously while doing the first thing anyway.
• Check whether the app asks you to create an account. A notification history app that genuinely keeps everything on the device rarely needs one, because there is nothing on a server to attach the account to.
• Look for an export option. An app willing to hand you your own data in a file you control is making a different claim than one that only lets you view it inside the app.
• Check what happens when you uninstall it. If the history would still exist somewhere after the app is gone, it was never only on your device.

The same four checks apply to the mess on your screen while you are at it. If you are using rules to quiet a noisy phone, remember that rules and the status bar filter never hide calls, alarms, navigation, media players, or foreground services, by design, no matter how aggressively you configure them. Reducing noise and protecting the content underneath it are two different jobs, and a history app only does the second one well if it was built around that job from the start, not added to a product that was designed to do something else with your data first.