"OK. Signal has forward secrecy. So messages are gone after I receive them. Great!"
Oh, you didn't turn on disappearing messages? Oh, right, then forensic tools like Cellebrite can get them. You have to turn on disappearing messages. The default is off.
Oh, you did turn on disappearing messages? We send the messages in notifications. So the OS can keep them. Turns out Apple was doing that. There is an option you can turn on to prevent that. It is off by default.
"I'll just delete the entire app!" No, sorry, the OS still has your messages...
At what point does the usability get so bad that we can blame the messaging system?
This same app had a usability issue that turned into a security issue just last year:
End to End Encrypted Messaging in the News: An Editorial Usability Case Study (my article)
Similarly on Android, WhatsApp suggests unencrypted backups to Google Drive by default.
Putting on my tinfoil hat, I am pretty sure that Google/Apple/Meta have some deal (successor to PRISM) where end-to-end encrypted messaging is tolerated as long as they have defaults that make it possible to access chats anyway. Apple not enabling ADP by default and WhatsApp doing Google Drive backups that are not end-to-end encrypted is the implementation. Since most people just use the defaults, it undermines security of people who care.
It's a 'win-win', the tech companies can wash their hands in innocence, the agencies get access to data, and phone users believe that they are chatting in a secure/private manner.
Just look at Salt Typhoon, every single person should be way more paranoid than they are, including government & agency officials. The attach surface and potential damage - financial and reputation - will only get worse with AI automation and impersonation, and that's for people who are doing nothing interesting and are law abiding citizens.
No one’s crazy enough to push that button, because once you do there is no turning back.
- create an encrypted disk
- install Mac OS on the encrypted disk
- use Time Machine to back it up with encrypt turned on
- Restore from Time Machine
- enjoy your PLAIN TEXT install :poo:At some point there need to be a frank admission that ETE encrypted messaging apps are just the top layer of an opaque stack that could easily be operating against you.
They've made encryption so slick and routine that they've opened a whole new vector of attack through excessive user trust and laziness.
Encrypting a message used to be slow, laborious and cumbersome; which meant that there was a reticence to send messages that didn't need to be sent, and therefore to minimise disclosure. Nowadays everything is sent, under an umbrella of misplaced trust.
You're right. This is configurable via settings, but is not the default state.
That said: if I can get friends and family to use Signal instead of iMessage, that gives me the opportunity to disable those notifications and experience more security benefits.
But I agree with your point: most people think that Signal is bulletproof out of the box, and it's clearly not.
If security is the main differentiator then app should start in the most secure mode possible. Then allow users to turn on features while alerting them to the risks. Or at least ask users at startup whether they want "high sec mode" or "convenient mode".
As the app becomes more popular as a general messaging replacement, there will be a push towards greater convenience and broad based appeal, undermining the original security marketing as observed here.
Worse than that, they did not take advantage of the ability to send that message data as an encrypted payload inside the notification.
https://blog.davidlibeau.fr/push-notifications-are-a-privacy...
Either do not include sensitive user data inside a notification by default, or encrypt that data before you send it to the notification server.
WTF. This is super simple stuff.
I've had this enabled to prevent sensitive messages from appearing in full whilst showing someone something on my phone, but I guess this is an added benefit as well.
Critical distinction, as merely changing OS notification settings will simply prevent notification content from being displayed on-screen.
If the app generates them, the OS receives them. That's why the Signal app offers this setting.
Source? I don't think either OS implements notification syncing between devices, it's only one way, and as others have mentioned, the actually push notification doesn't contain any message content, only an instruction for signal to fetch and decrypt the message.
iOS does. This is how you can receive Signal notifications on your Apple Watch and other Apple devices that don’t have the app installed.
Can't speak for iOS and no idea if this relates to the above functionality, but Pixel lets you deduplicate notifications across Pixel devices.
I also didn't realize that Android stores message history even after I've replied or swiped them away. That's nuts - why!?
Source: https://mastodon.world@Mer__edith/111563866152334347 (Meredith Whittaker is the current CEO of Signal)
I can't link you rigth now to the actual code on their repo but it is verifiable.
Receiving a ping from Firebase Cloud Messaging triggers the app to whatever it does in order to display its notification. In the case of Signal, that probably means something like fetching the user's latest messages from the server, then deciding what to show in the notification based on the user's settings, metadata, and message content.
Here's example code for using FCM to show a notification. In this case, the notification content also passes through FCM, but Signal does not do that. https://www.geeksforgeeks.org/android/how-to-push-notificati...
Looks like there is a way to bypass Firebase by using something like UnifiedPush which runs a perpetual background process that acts similar to Google Play Services to pick up notifications from the server and calls the local notification API.
That's unreliable though since some OEM Android builds will kill it for that even if the user disables battery optimizations. Those OEMs sort of have a point; if lots of apps did that it would drain the battery fast.
I’ll note that whatever other reasons it’s also the only way to make this battery efficient. Having a bunch of different TCP connections signaling events at random times is not what you want.
Ideally the app also is responsible for rendering rather than having to disclose the message but that can be challenging to accomplish for all sorts of reasons).
This is more of a fundamental technical limitation of operating systems and networks; I don't think it is possible to design distributed communication between arbitrary service provider infrastructure and end-user devices without an always-online intermediary reachable from anywhere (a bouncer, in IRC terms) that accepts messages for non-present consumers.
The flip side of the coin: any possibly avenue to exfiltrate data and do (advertising) tracking by app developers will be used. The restrictions also protect my privacy.
And my phone battery.
Except you need an entitlement for that, because it requires that your app has the ability to receive a notification without actually showing it (Apple checks this).
Your app gets woken up, decrypts the message, and then shows a local notification.
Normally no notifications are shown for hidden apps, and even if you unhide the apps, prior notifications which were sent do not reappear IIRC. I'm curious if notifications like that are still hitting the phone into the notifications database, or get silently dropped, or something else.
Signal has this setting to tell the backend how much information to put into the push message. It can tell the backend to send a simple notification saying “new message” and not send information through APNS or enable it.
I am willing to bet Signal has a notification extension to handle edge cases where there is lag in settings to scrub the message metadata before it dings a screen alert.
Basically, give you a heads up that the other side has settings that make the system less secure.
I suppose you could do both, but "Hey I've got something extra important to send you, but it says need to change your settings first please hurry" seems worse than "sometimes I don't get full notifications on my watch, weird."
Thank you for adding this to the conversation.
Settings > Notifications > Messages > Show
Deleting that history is good to know about after the fact, but preferably lets just not create the problem.
But you can set them without content. That actually works with signal because all it sends through Google Firebase is a notification to wake up the app. If you have the content turned on the app basically fills the content in the notification locally. But you can turn that off.
The Defaults have to be the most sensitive ones.
If you are a supposed super secure app, this should be the default.
But most likely (pure speculation mind you), this was a case of someone handing over the phone for review and where cooperating.
It might have been that they deleted signal some time ago, or even deleted signal and then handed over the phone.
It's notable that the data wasn't recovered from signals storage (was the data securely erased or that kind of recovery not attempted?).
> Web browsing: Certain complex web technologies are blocked, which might cause some websites to load more slowly or not operate correctly. In addition, web fonts might not be displayed, and images might be replaced with a missing image icon.
"Signal’s settings include an option that prevents the actual message content from being previewed in notifications. However, it appears the defendant did not have that setting enabled, which, in turn, seemingly allowed the system to store the content in the database."
Second, how can I see this notification history?
HOURS=6
EPOCH_DIFF=978307200
SINCE=$(echo "$(date +%s) - $EPOCH_DIFF - $HOURS * 3600" | bc)
sqlite3 ~/Library/Group\ Containers/group.com.apple.usernoted/db2/db \
"SELECT r.delivered_date, COALESCE(a.identifier, 'unknown'), hex(r.data)
FROM record r
LEFT JOIN app a ON r.app_id = a.app_id
WHERE r.delivered_date > $SINCE
ORDER BY r.delivered_date ASC;" \
| while IFS='|' read -r cfdate bundle hexdata; do
date -r $(echo "$cfdate + $EPOCH_DIFF" | bc | cut -d. -f1) '+%Y-%m-%d %H:%M:%S'
echo " app: $bundle"
echo "$hexdata" | xxd -r -p > /tmp/notif.plist
plutil -p /tmp/notif.plist 2>/dev/null \
| grep -E '"(titl|title|subt|subtitle|body|message)"' \
| sed 's/^ */ /'
echo "---"
done
In recent years, filesystem paths for system services have started to converge for both macOS and iOS so I'm thinking with jailbreak you could get read access to that database and get the same data out of it.
But this is a reminder that these centralized notification infrastructure (FCM and APNs) store notification content (if the app is told to send content in it - signal with option enabled wouldn't send content) even if we clear local history these middleman still hold it
“We learned that specifically on iPhones, if one’s settings in the Signal app allow for message notifications and previews to show up on the lock screen, [then] the iPhone will internally store those notifications/message previews in the internal memory of the device,” a supporter of the defendants who was taking notes during the trial told 404 Media
The default setting appears to be to only show notification preview when unlocked. Will that notification still be stored unencrypted in notification storage or is it in an encrypted store because it will preview after unlock?
It makes sense that any notification that previews on the lock screen would be unencrypted (including the case where it is encrypted but the encryption key is adjacently stored).
This all reads to me that this was a user induced OPSEC issue and Signal had the right defaults.
By this logic, you, me, and everyone else using the defaults are using bad opsec. Doesn’t that strike you as problematic?
This user went out of their way to show previews on the lock screen, that is an OPSEC failure, even if you do not consider the acquisition of the messages digitally.
I do think there should be some UI somewhere that allows for locking all things down to the most secure configuration possible.
Android > Settings > Notifications > Manage > Notification History
Unrelated to the OP, but I bet the thousands of "exploits" that Claude Mythos has identified already are a lot of these kind of things that regular people would never think about.
But it was really useful each time I did not see a notification in time.
Edit: typo
Hopefully, you meant to write "shortcut"...
Not implying anything evil but it feels a bit weird esp after this.
For an app that prides itself on privacy, it's kind of crazy that you're making it so easy to accidentally blow it.
I fear that with the notifications pop up asking me this I might hit the wrong button and woops turn it on.
Oh... hmm, two toggles actually. One at Settings > Notifications > Calls > Notifications toggle, and the other at Settings > Notifications > Messages > Notifications toggle
I know octogenarians who use signal daily. "You called me and it didn't ring" or "messaged and it didn't beep" are definitely the top support complaints I receive. Thanks for being sensitive to this use case.
We as a society have gotten way too comfortable expecting every single person to be available at all times to provide us some kind of immediate response. Let people live. If I'm hiking through the woods with my camera doing bird photography, even if you're my best friend you can wait until I get back to my car and manually check my messages, I don't need a notification. If it's an emergency, dial my number and call me, which will make my phone ring. Novel concept, I know.
Why does any software keep asking you to do things you explicitly told them you don't want to do? Because it's in the software developer's best interest to get you to do them, not yours. We've gotten way past the point in software where we no longer expect the software to serve the user's interest and solve the user's problems. Now, the expectation is that the user gets nagged and coerced into serving the software's interest and solving the developers' problems.
EDIT: Looks like a developer confirmed this in a sibling comment already: It nags you because that solves their support problem.
The easiest way to experience that yourself is to set your device to a language you barely understand. You’ll find yourself dismissing dialogs just like all those illiterate normies.
I think we're capable of finding it ourselves if you do.
I don't see my computers as partners or helpful assistants or eager interns. I see them as tools for reliably performing computation, and I expect them to operate that way.
I fully understand that this means that fewer and fewer developers are "building their software for me" and I find that pretty disappointing.
HN truly never fails to make me laugh when it comes to discussing user experience.
I don’t follow how it’s necessarily selfish for the developer to reduce that.
There certainly are selfish ways to reduce support load, like making it harder to ask for help at all. But this way seems like the right way: listen to users’ problems and act to avoid them.
If your remedy causes more pain and frustration than the status quo, you’ll end up with more support load, not less.
Sure it’s greyer when the developer’s trying to sell something, but what does Signal gain from pushing notifications on users?
This seems to be about making the software humane and forgiving—meeting users where they are, not tricking them into something they don’t want.
I guess they /want/ more storage to be used? Or is there a support issue they are trying to deal with?
But it would be nice to have a "don't ask again" option regardless, even if it's hidden in settings.
At some point it is just not beneficial anymore.
Court cases are the real way to audit security.
Larping about security and complaining about companies responding to court orders only gets you so far. Its way more useful to look at what actually happens in reality.
The case comes with a long statement about the Antifa “organization”. Just your weekly reminder we are living under an Orwellian administration. https://www.justice.gov/opa/pr/antifa-cell-members-convicted...
"[A]llowing the system to store the content in the database" where a third party, such as Apple or a government, can access it is the default
Only a small minority of users know about settings and how to change them. The vast majority of users do not change default settings. Apple knows this
Even worse, whatever critical settings you may set as a sophisticated user will frequently be reset, or changed, or re-organized under different settings… And of course, set back to insecure defaults… With subsequent software updates.
This is a regular occurrence with Firefox and privacy settings.
Whatever the actual impetus is, we should act as if this is intentional.
If you don't know how to disable it, you use your favorite search engine / LLM / knowledgeable relative to find out, and disable it.
But if you just didn't pay attention, "never thought about it", you don't care about security, and no amount of technical means would help, sorry.
With at least one combination of settings, it shows the message content only when the lockscreen has been unlocked, but not yet swiped away.
The only way they're not saved is to disable name/content in signal itself.
Maybe you're not as capable of elementary logical inference as you thought?
But indeed, the idea that disabled notifications are still stored, and not directed to /dev/null immediately, cannot be inferred from just observing the behavior of the phone UI.
"However, it appears Apple's system uses a default setting which, in turn, seemingly allowed it to store the defandant's content in Apple's database"
instead of
"However, it appears the defendant did not have that setting enabled which, in turn, seemingly allowed the system to stoire the content in the database"
In the later version, the defendant, namely his inaction in not changing a default setting, appears solely responsible for the outcome. And the actor that placed a copy of his incoming messages in a database that the actor created is referred to as "the system", not the corporation that wrote the system and sold the computer with this system pre-instaalled
I couldn't believe this so went to look up some data on this.
Holy FUCK that is bleak. There needs to be way more computer education, not just "how2type" classes.
Obviously the cause is different interests. Different interests can explain everything from a bad decision to going to sleep early. It says nothing useful.
0. https://www.404media.co/fbi-extracts-suspects-deleted-signal...
After these news Signal should ask the users ASAP and on new installs something like:
> Do you want the notifications to pass through Apple (no privacy, better battery) or through Signal itself (better privacy, but less battery life due to the persistent connection to Signal's servers.
It should be as part of the setup wizard, not inside the settings.
Correct me if I've misunderstood something.
1. On android if Google Play isn't available (or you install the no Google apk version) it'll use a websocket for notifications. Apple doesn't allow a persistent connection except through their own notification framework.
2. In either case Signal doesn't send message contents through the notification framework (not even encrypted). Once Signal receives a notification the app wakes up and reaches out to the signal service directly for actual encrypted message.
3. Regardless when signal shows the contents of your message in the notification menu of your device your device keeps a record on your device of that message content.
The FBI here didn't get anything from apple, once they had the apple device unlocked they looked at the notification database on the device to get the message contents. This isn't really any different from the fact that if the FBI has your unlocked phone they can read your signal messages. The notable bit is that the notification database retains messages even after the app is deleted.
How can iOS not allow persistent connections at all? How would a long download work or a call in the background work at all?
> Regardless when signal shows the contents of your message in the notification menu of your device your device keeps a record on your device of that message content.
How is that not treated as a backdoor unless it's explicitly mentioned when someone installs iOS?
It's worth noting you can add an additional security check pin/bio/pass to signal that is different from your phone unlock.
The protester had also uninstalled signal from phone (even with access to the phone, they would not have access to signal, if they had reinstalled signal, and some how got the security pin or passphrase, they wouldn't be able to load the prior messages, without either, no messages at all).
You can send push notifications with your own encryption on top, which I believe Signal does, so Apple can't see it on the APNS side, but your local extension to decrypt the content is still subject to the user's settings, and part of the notification history if you put message content in the notification.
On which end, Apple or Signal? Because neither Apple nor Google will overhaul this behavior, the FBI asked for it directly: https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...
I'm not sure precisely how the NAND controller responds to requests for raw data from blocks with "deleted" data. And if this would require decapping the flash.
Some flash will happily let you see the data and delay erasing it.
Generally flash is non deterministic about when blocks even those with entirely stale data are erased . It might be years before the block is reused due to wear leveling algorithms and it might retain data that entire time.
Here's hoping the controller for phones which hold sensitive data are more active
Semi-related, in whatsapp reading the text in the notification doesn't mark the message as read, so the OS is kinda mitm here.
If piping encrypted content resulted in a plaintext notification then you'd have a right to be concerned.
https://github.com/RealityNet/iOS-Forensics-References https://theforensicscooter.com/2021/10/03/ios-knowledgec-db-...
This makes sense and there's really no way around it without a change from Apple. If iOS is going to show the user a Signal notification with the decrypted message in the notification body, then iOS must be given the decrypted message. iOS could (and probably should) delete that data off the device as soon as the user dismisses/engages with the notification. But it sounds like they do not.
I guess that's what you deserve if you trust apple with your operational security.
i haven't actually seen signal or anyone adjacent recommend that previously though, idk where that claim came from
I’ve checked the Signal documentation page, and there’s no mention of the privacy implications of the setting: https://support.signal.org/hc/en-us/articles/360043273491-In...
“Messages were recovered from Sharp’s phone through Apple’s internal notification storage—Signal had been removed, but incoming notifications were preserved in internal memory. Only incoming messages were captured (no outgoing).”
ie the messages recovered were 1. incoming 2. stored by the OS after decryption
i also was spooked by the headline :p
Photos I had long deleted were still in the backup! It's quite surprising just how much is being stored by the phone.
Screenshot of notification settings page: https://files.catbox.moe/3gwjoy.png
I also get that in Texas they are fine "criminalizing" protesting, but that's just part of its hyper-authoritarian "charm", and a lot of us don't think that protesting in itself should be criminal.
the verification accepts other people's credit cards and IDs. so the 'age gate' doesn't even verify the person using the device, just that someone with a credit card touched it once. it's all the privacy cost of an identity check with none of the supposed child safety benefit
Data Protection is implemented by constructing and managing a hierarchy of keys, building on the hardware encryption technologies built into Apple devices. It's controlled on a per-file basis by assigning each file to a class; accessibility is determined by whether the class keys have been unlocked.
The four protection classes, from strongest to weakest:
NSFileProtectionComplete — Files are only accessible when the device is unlocked.
NSFileProtectionCompleteUnlessOpen — A file can only be opened when the device is unlocked, but is not closed when the device is locked — it's encrypted when the last open handle is closed. Suitable for data being uploaded in the background.
NSFileProtectionCompleteUntilFirstUserAuthentication — The resource cannot be accessed until after the device has booted. After the user unlocks the device for the first time, the app can access the resource and continue to do so even if the user subsequently locks the device. Fortify This is commonly called AFU (After First Unlock). This is the default class for all third-party app data not otherwise assigned to a Data Protection class.
NSFileProtectionNone — The resource has no special protections. It can be read or written at any time. The encryption only uses a key derived from the device's UID.
The BFU/AFU Distinction — The Heart of the Signal Issue
Apple's iOS devices operate in two key security states that directly impact data accessibility: Before First Unlock (BFU) and After First Unlock (AFU).
When an iPhone is in the BFU state, it has been powered on or rebooted but not yet unlocked with a passcode. In this state, the Secure Enclave does not release the decryption keys needed to access most user data.
Once you've unlocked once (AFU), files protected with NSFileProtectionCompleteUntilFirstUserAuthentication become accessible, the Keychain is available, and background processes and apps can access encrypted content as needed.
The Signal notification content issue connects here because notification data (including previews) stored in the default CompleteUntilFirstUserAuthentication class remains decryptable by any process — including OS-level forensic tools — as long as the phone has been unlocked at least once since the last reboot.
They rest who "evaluate their threat models" can practice Spy-life-gymnastics by disabling it from Signal.
Personally, it's a moral good to free people from a concentration camp, even if it requires violence to do so. However it's also obvious that when you oppose a State, you get hit with terrorism charges. ...unless you're a jan6er, of course.
Privacy, that’s Apple: https://www.reuters.com/article/world/exclusive-apple-droppe...
An individual can disable name or content in notifications in iOS, or set "mute messages" for a chat to prevent notifications from appearing for that specific chat, but there's nothing that gives group members any assurance that other group members are doing that.
Since the purposes of the program are pretty heavy on private communication, I'm inclined to think that takes precedence here, especially considering the consequences for dropping default message previews versus adding default reveal of supposedly private information.
The major hole here is that you turn off your notifications and don't have a bunch of database records, but the threat actor somehow finds out who your contacts are, gets a hold of their phone, and can then see all of the messages you sent via their notifications database. So if you want to trust the device for secure communications, you can't do that.
I've found other ways Signal can leak information, even with disappearing messages. It's not the total install-and-be-done privacy screen that some people think it is, and requires a little effort at the user end to fill in a few gaps.
Am I missing something here? Maybe I'm missing a subtle detail.
I'm always like "JFC, can't you cache the notifications, so I can see it there while waiting for the app to gets its act together?" But no, that's never an option.
So I'm getting a laugh out of how notifications last long enough to be extracted by someone just not the person that they're for. (Though to be fair, it could be a case of a notification that was never tapped, and therefore hadn't been purged yet. I couldn't tell from the story.)
Personally I'd be in favor of a hard app store policy, that if an app notifies you about something, all the importantdetails (like full message text) must be included - specifically to allow the user to view the important information without having to open the app itself.
I generally sympathize, I also don't like when apps block screenshots (or even more stupidly, they can block Android's amazing "select text from anywhere" feature...). But I don't think there are similar concerns for Signal allowing me to hide notification content from the OS.
"To use the Signal desktop app, Signal must first be installed on your phone."
The only one I can think of that doesn't require a mobile login is iMessage, because it's not a chat app, it's lock in and data theft disguised as software
OK, maybe they can be stored until they're dismissed in case the battery suddenly dies, so they can be displayed again on next boot and are not lost, but it sounds like they are being stored long after they are dismissed.