FBI used iPhone notification data to retrieve deleted Signal messages

Original Article ↗ Hacker News Discussion ↗

FBI investigators were able to recover deleted Signal messages from an iPhone by extracting plaintext notification previews stored in iOS’s internal notification database, despite Signal’s end-to-end encryption and the app having been uninstalled. Commenters explain that Signal sends encrypted push notifications and decrypts them locally, but once the OS renders message previews, iOS (and similarly Android) may cache that content unencrypted, creating a forensic trail users don’t expect. Much of the debate centers on unsafe-by-default notification settings, limits of end-to-end encryption on real-world devices, and whether “secure” messaging apps should default to more privacy-preserving notification behavior even at the cost of usability.

What actually happened (per thread)

  • iOS keeps an internal SQLite/plist database of delivered notifications.
  • Signal’s push via APNs/FCM is effectively empty; it just wakes the app.
  • The Signal app then fetches the encrypted message, decrypts it locally, and creates a system notification.
  • iOS stores the resulting preview text unencrypted in its notification database, which persisted even after Signal was uninstalled and messages deleted in‑app.
  • Forensics tools accessed that database on an unlocked iPhone and recovered incoming Signal message content.

Who is “at fault”?

  • One camp: this is entirely an OS issue; Signal sends encrypted/empty pushes, iOS decides to store plaintext previews.
  • Another camp: Signal markets itself as “secure,” so defaults that leak plaintext via notifications are bad design, regardless of OS behavior.
  • Several note that many apps are affected, not just Signal.

Defaults, usability, and threat models

  • Signal allows configuring notification content: full preview, name only, or neither.
  • There’s disagreement over what the default actually is, but multiple users report that name+content will be shown unless changed.
  • Critics argue a “secure by default” messenger should minimize leaked data and only show “new message” by default.
  • Others stress tradeoffs: most users expect rich notifications and rarely change settings; too strict defaults hurt adoption.

Platform behavior and persistence

  • iOS: notification previews are cached in an internal DB, seemingly not wiped when swiped away or when the app is removed; Apple could in principle tie this to per‑app keys or delete on uninstall, but apparently does not.
  • Android: also has notification history features (often opt‑in) and third‑party “notification log” apps; some ROMs let you disable history entirely.

Limits of end‑to‑end encryption / OPSEC

  • Multiple comments stress that E2EE only protects data in transit; anything before encryption or after decryption (notifications, screenshots, backups, OS caches, keyboards) is outside its guarantees.
  • Deleting messages or even uninstalling the app does not ensure erasure if the OS or backups retain copies.
  • Some argue this case shows how hard real operational security is and how much users over‑trust “secure” apps.

Mitigations and suggestions

  • Use Signal’s in‑app setting to show “name only” or “no name or content” in notifications, especially for sensitive chats.
  • Possibly add chat‑ or group‑level policies that can require stricter notification behavior for all participants.
  • Calls for Apple/Google to:
    • Delete notification data on app uninstall or after dismissal,
    • Store notification content with stronger data‑protection classes or rolling per‑app keys,
    • Make notification retention more transparent/configurable.