Settings > Notifications > Notification Content > Show: "Name Only" or "No Name or Content"
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.
Yes. And technically, from a privacy perspective, it's even worse than that. What's additionally happening is they're still 'syncing' back to Apple servers via APNS (and to Alphabet servers via Firebase on Android)—even with notifications completely disabled, that's correct.
If the app generates them, the OS receives them. That's why the Signal app offers this setting.
>it's even worse than that. What's additionally happening is they're still 'syncing' back to Apple servers via APNS (and to Alphabet servers via Firebase on Android)—even with notifications completely disabled, that's correct.
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.
This sounds correct. When I implemented push notifications for an iPhone application, I remainder needing to obtain a store a separate token for each device a user has, and subscribing to a feed of revoked delivery tokens. Seemed like an interesting design intended to facilitate E2E encryption for push notifications.
Wait... why does Signal need to send notification content to Firebase to trigger a push notification on device? I would instead expect that Signal would send a push to my Android saying nothing more than "wake up, you've got a message in convo XYZ", then the app would take over and handle the rest of it locally.
I also didn't realize that Android stores message history even after I've replied or swiped them away. That's nuts - why!?
If your app needs to send a notification while it's not currently a running process, it must go through Firebase on Google's side and APNS on Apple's side. There is no way for a non running app to send a notification entirely locally, this is by design of both companies.
Signal developer here. Not entirely sure what you're saying. I'm only an Android guy, but FCM messages are certainly one trigger that can allow an app process to run, but it's not the only trigger. You can schedule system alarms, jobs, etc. And the notification does not need to be provided by the FCM message. In our case, the server just sends empty FCM messages to wake up the app, we fetch the messages ourselves from the server, decrypt them, and build the notification ourselves. No data, encrypted or otherwise, is ever put into the FCM payloads.
Sure but it needs to go through Firebase regardless of the content of the notification message, I do not believe there is a way to use a third party notification service which does not depend on Firebase.
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.
Yes, however the fact that it is not customizable is what is annoying, you are forced to rely only on the OS makers' implementations, which I guess should be expected in the day and age.
But there is a way to do this encrypted, so that when the notification is received on your iPhone, the process itself needs to decrypt it.
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.
Any idea if this works the same or differently for Hidden apps specifically?
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.
With notifications disabled APNS push notifications fail for the sending app backend. The device id is rendered invalid if push notifications are disabled at any point. Backends are supposed to handle this and quit sending messages.
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.
However, if this is important to you then you want Signal to stop telling Android to make the notifications. If it doesn't exist nobody will accidentally make it available.
Deleting that history is good to know about after the fact, but preferably lets just not create the problem.
It's a mode of the phone that is supposed to prevent cyber attacks, more so than "normal mode" I suppose, since it's supposed to limit features in the name of security. This seems like a variant of such attack, so seems like it should protect against it
There is a documented list of things that Lockdown Mode affects [1], this is not one of the advertised ones. There are a bunch of other (undocumented) things it affects (some of which are bugs :/), but I don't believe it has any affect on notification storage.
Mostly it seems the documentation is vague. Is there anything clearer than this?
> 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.
Just curious, how come at least once a month signal bugs me to turn on notifications? I said no for a reason, every single time - why does it keep asking?
Not implying anything evil but it feels a bit weird esp after this.
Signal developer here. It's just because notification reliability is always a top support complaint, and a lot of people turn off notifications and don't realize they've done so. Admittedly, once a month is likely too aggressive.
How about instead of prompting to enable notifications, you leave a small banner or other unintrusive/non-annoying UI noting that they're off, which users can tap in order to learn more about how to reenable them?
For an app that prides itself on privacy, it's kind of crazy that you're making it so easy to accidentally blow it.
That would drive me nuts. I do not want a banner permanently on I cannot remove.
And before someone suggests it: If the banner can be removed, you’re back to having lots of complaints for users that did not realise they turned off notifications.
> notification reliability is always a top support complaint
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.
It's just a mental compartmentalization thing for me. When I want to get into slack/signal chatting mode or read messages I load such an app and look/interact. When I'm not doing that I don't want to be bothered with messages. I'm already sacrificing a portion of my life to work related tasks and being in front of a computer at many hours, when I'm not in that mode I don't want to be interrupted - people who need to reach me in an emergency have other ways to get ahold of me.
I disable notifications on every app that is not on the critical path to me earning a living. Notifications are largely unnecessary. Either you are actively engaged with something, in which case you didn't need the notification, or you are doing something else and don't need the distraction, in which case you didn't need the notification. Only my employer gets a right to demand my time during work hours, which is why notifications are enabled during work hours for work apps.
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.
We build Signal for everyone, and that includes a lot of people who are not as technologically literate as the average tech worker. For a lot of people, they don't even know they dismissed the notification permission prompt, they were just closing boxes. For them, the reminder is helpful and prevents them from experiencing missing notifications. Striking a balance between helping these people and annoying more technologically-literate users is very difficult, with compromises everywhere. We're just trying to make sure Signal works for people, nothing more.
What a load of nonsense. These comments, treating users like they are idiots, makes me despise Signal, as a user. "We make our app more annoying to use and its not for us, its for you.' kick rocks
Thanks for the reply. I know it feels noble to do it that way, and I admit I get dogmatic over this one principle: a computer should first and foremost obey the user. It shouldn't have its own agenda. It shouldn't second guess. It shouldn't "did you mean?" I command the computer, and the computer executes that command and then waits for the next command. If I command it to not display a particular output (notifications), then I expect it to never display them, full stop.
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.
“Their support problem” is a regular person’s problem getting the software to do what they want. A problem that frustrated the user enough for them to take it to support.
I don’t follow how it’s selfish for the developer to address pain that users care enough to complain about.
Maybe when they’re 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.
Yes Google constantly asks me to backup my pictures to their platform No, I don't want this. But regularly when I go to my photos it'll pop up with a box asking and the default option is yes please back up. Sad.
"Consent" has become this mystical foreign concept to software developers. If the world of computing was a night club, "Silicon Valley" would be that creepy guy who goes up to everyone asking "Do you want to dance? [YES | Ask Me Later]".
It's pretty shortsighted, bordering on intentionally obtuse, to insinuate that the only person that benefits from solving the support problem is the person on support.. Take the example of automatic backups others brought up in this thread. Are you really going to imply that there's zero benefit to the person who didn't lose their data because the app reminded them to turn backups on?
I don't disagree that it could be improved with a simple "don't ask me again" style setting, but that doesn't change the fact that every time someone doesn't issue a support ticket, it's because they didn't run into an issue. Any effective solution to a support problem is mutually beneficial for the user as well as the support staff.
Messaging platforms where people receive and promptly respond to messages are more successful in the long run. That's why SMS overtook email. If you own a messaging platform there isn't anything inherently nefarious about pushing people to enable notifications.
imagine someone shows up to your door and tries to sell you garbage. you ask him to leave and he says he'll show up again soon. and these idiots defend this behavior. at the end of the day, the people on this site are muppets, they just dont like facebook is all.
What I don’t understand is why anyone can’t imagine scenarios where folks don’t want to turn on notifications. Also, why on a site where all I ever read is “users should be allowed to choose, users should be allowed to control their computers, users should have their consent respected,” etc. (especially when Linux comes up) are we seeing “no, users should keep getting nagged to turn on a feature they explicitly said they don’t want to use”? It’s not like it’s hard to go enable notifications. They can easily change their mind.
"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."
Not sure if it's exactly the same, but I had to add a When notification arrives with <message>, do <action> event trigger in my Crank macOS app (https://lowtechguys.com/crank) so I can show you how to do it on macOS:
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
Basically, notifications are in an sqlite db at ~/Library/Group Containers/group.com.apple.usernoted/db2/db and are stored as plist blobs.
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.
On android there are apps that let you see the history - i use NotiStar occasionally to see if i unwittingly dismissed important notifications. And i believe there are apps/settings that help you clear the history from the device.
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
So I wonder about this. The quote from the 404 media article [0] is:
“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.
Wasn't sure if it was the Pixel or GrapheneOS, but what a relief to actually be covered in one of these weird 0day issues.
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.
On android its quite easy. There is a page of a protocol address that has all notifications show. I used to have a shortcut to it. It has been years since I was on android.
But it was really useful each time I did not see a notification in time.
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.
Yes and no. Court cases certainly will disclose what capabilities various parties have come up with when it comes to security. However, there are documented cases where the government chooses to abandon prosecution for the sole purpose of preventing disclosure of some of their cyber capabilities.
The problem is that, in the current environment of dishonest and corrupt states, "what actually happens in reality" isn't the same as what happens in court because of parallel construction.
"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."
"[A]llowing the system to store the content in the database" on the phone 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
“Only a small minority of users know about settings and how to change them. The vast majority of users do not change default settings.”
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 care about security at all, you disable any previews on the lock screen. The lock screen is by definition visible to anyone without any authorization. Showing anything on it immediately destroys any secrecy. It must be obvious to anyone capable of elementary logic inference.
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.
> If you care about security at all, you disable any previews on the lock screen. The lock screen is by definition visible to anyone without any authorization. Showing anything on it immediately destroys any secrecy. It must be obvious to anyone capable of elementary logic inference.
With at least one combination of settings, it shows the message content only when the lockscreen has been unlocked, but not yet swiped away.
This is insidious indeed. Still I would suggest that any secret message, as it leaves the app that handles secrecy, ceases to be secret. This BTW also applies to copy-paste operations, screen readers, etc.
While it's definitely surprising that the OS caches this data after the notifications have been swiped away, I always thought that notifications are an obvious hole in the whole E2E encryption setup.
AIUI, Signal push notifications just saying a message was received. Signal then fetches the E2E encrypted message from the server and decrypts it locally. So Apple/Google cannot read the messages, nor can Signal servers.
AIUI, Signal decrypts the E2EE message locally, but then sends the decrypted message to iOS in order to display the notification to the user. iOS then stores this data and it persists after the user dismisses the notification.
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 wonder why Apple doesn't 'just' delete the notification data associated with the app from the internal database when the user deletes the app? It seems like asking for problems to just keep old notification content around forever.
It's one of those problems where as soon as someone notices, it's crazy that no one noticed. I can't imagine this not being overhauled going forward. It's just a bad way to operate and now it's news.
If it never hits flash that might work, but if it's in flash storage then the block may not be erased by the time its dumped.
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
If the "database" works like most other databases (eg. postgres or sqlite), deleting a row doesn't immediately cause the data to be wiped from disk, for performance reasons. Then as others mentioned you have filesystem/SSD logic that does something similar on top of that.
But you can do other things to mitigate this. For instance, give each app a set of rolling daily encryption keys, and encrypt new messages at rest. Remove the app, remove all keys. Nightly, remove the oldest key. Perhaps have the entire key database either stored in Secure Enclave, or if there isn't room, have the key database itself encrypted by a rotating single key in Secure Enclave. Now there's nothing that an attacker can do.
Sounds like an intentional government feature. Just speculation though. I'm glad I have a Pixel, but I'm on the default OS and need to switch to GrapiousOS (secure version). Just haven't due to lack of nice Google features.
On Android, when I use WhatsApp and have notifications for groups turned off, I can still see that they arrive briefly and then get removed (the icon top left vanishes). I wonder often, if this is a way to push all group message content into an unencrypted data trace as well - for the same use case.
If the notification has the data, then yes. It's trivial to create an app that listens to notifications; Samsung even has one themselves called NotiStar that replicates the notification history feature that Android normally has.
everyone's arguing about whether apple or the government is to blame. the actual problem is the verification methods themselves. credit card, drivers license, or a pass card. three options that each create a centralized database linking your real identity to your device. age verification is just identity verification with a friendlier name.
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
iOS stores the previously displayed notifications in an internal database, which was used to access the data. It’s outside of Signal’s control, they recommend disabling showing notification content in their settings to prevent this attack vector
They do control the content on the notification. It's a bit odd to put the sensitive text in the notification only to recommend disabling it at the system level.
You can choose what to show in the notification and there is an option to include the message, so I'm guessing that allowed some unencrypted incoming messages to be read.
Sibling comment explains. The notification does arrive encrypted and is decrypted by an app extension (by Signal), however, if the message preview is shown, it is stored unencrypted by iOS. It is that storage that is accessed.
“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
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.
Kind of a wake-up call that even "deleted" messages aren't really gone if the OS is caching notification previews — makes you rethink what end-to-end encryption actually protects you from.
I thought Signal didn’t show message previews by default and you had to go in and enable it? I’ve never had message previews in my Signal and I don’t remember changing anything. Maybe when they introduced the feature, you could pick but they strongly suggested it not showing?
The opposite, actually. Signal endlessly nags you to turn on notifications, and when you turn them on, previews and content are shown by default. You cannot opt out of the nags.
The article you're commenting on is about people who obviously would have wanted this disabled, but didn't have it disabled, presumably because they didn't know about this issue.
Right. It's purely a protection against MitM snooping. The app has to have the messages in plaintext to display to you via whatever mechanism the OS uses. Seems obvious, but also not, at the same time.
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.
Signal does not send any sensitive information in push notifications sent via APNs [0]. This story concerns the local OS cache of push notifications, which are triggered after E2E decryption has occurred.
Right. So I send a push notification with the "silent" flag and encrypted content; the app receives it, decrypts the text, and displays the notification locally. Google/Apple has only ciphertext in their FBI/CIA/NSA-accessible databases.
I think the answer is probably stupid too: because they don't want it encrypted. Jobs used to draw a hard line with this kind of stuff. I imagine Tim Cook instantly folds whenever the Alphabet boys come knocking.
There needs to be a bit more "group chat" control in Signal messages, wherein you could enforce certain settings for certain chats regardless of the phone settings. You could have group chats that would enforce not showing more information in the notifications, while others would still allow it.
I think it fits in pretty well with Signal. As it stands, a group chat can control when a message is automatically deleted for everyone, so everyone can rely on that being a shared setting. That's an intentional design decision. There's no individual opt-out.
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.
But it would be pretty well in line with the "I trust my contact with this communication, but only if they're not systematically misled to copy it to readily exploitable insecure storage" line of thinking.
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.
Good. The moment they add it, all kinds of apps will start to abuse it, for "sekhurity" (read: engagement) reasons. See e.g. all the apps that now disallow taking screenshots, for no legitimate reason.
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'm referring to what sounds like a feature of the app, not the OS... The app... already chooses what to send through the OS notification API so I really don't have any idea what scenario you're worried about.
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.
thank god whatsapp doesn't do that either. or telegram. or allo back in the day, or every single mobile first messaging app
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
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.
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.
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.
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.
Thank you for adding this to the conversation.
At least for me, it was name and content.
Settings > Notifications > Messages > Show
Deleting that history is good to know about after the fact, but preferably lets just not create the problem.
Settings > Notifications > Show preview
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?).
[1] https://support.apple.com/en-us/105120
> 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.
Not implying anything evil but it feels a bit weird esp after this.
I fear that with the notifications pop up asking me this I might hit the wrong button and woops turn it on.
For an app that prides itself on privacy, it's kind of crazy that you're making it so easy to accidentally blow it.
And before someone suggests it: If the banner can be removed, you’re back to having lots of complaints for users that did not realise they turned off notifications.
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.
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.
I don’t follow how it’s selfish for the developer to address pain that users care enough to complain about.
Maybe when they’re 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.
"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?
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
If you drop a settings widget on your home screen, it will let you choose a specific area, including notifications.
I don't know if the output is the complete database.
“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.
[0] https://archive.is/bSQhD#selection-619.0-622.0
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"...
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...
https://github.com/RealityNet/iOS-Forensics-References https://theforensicscooter.com/2021/10/03/ios-knowledgec-db-...
"[A]llowing the system to store the content in the database" on the phone 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.
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.
0. https://www.404media.co/fbi-extracts-suspects-deleted-signal...
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.
The actual one end is the phone, not the app, period.
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.
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
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
i haven't actually seen signal or anyone adjacent recommend that previously though, idk where that claim came from
“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
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.
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
They rest who "evaluate their threat models" can practice Spy-life-gymnastics by disabling it from Signal.
The article you're commenting on is about people who obviously would have wanted this disabled, but didn't have it disabled, presumably because they didn't know about this issue.
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.
[0] https://mastodon.world/@Mer__edith/111563865413484025
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.
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