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.
Just to clarify, this is within the Signal app settings—not the OS (iOS or Android) system settings.
Critical distinction, as merely changing OS notification settings will simply prevent notification content from being displayed on-screen.
Wait so if I do iOS setting notifications > never show previews it’s still caching them in the background? Unencrypted?
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.
> I don't think either OS implements notification syncing between devices
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.
> I don't think either OS implements notification syncing between devices
Can't speak for iOS and no idea if this relates to the above functionality, but Pixel lets you deduplicate notifications across Pixel devices.
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.
I do wonder how notifications that are synced/mirrored to the Apple Watch and newer versions of Mac are handled.
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!?
Signal does NOT send notification content througth APN/Firebase, their push notification is literaly a ping as you expected.
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.
Btw I clicked your mastodon link and it didnt work
https://mastodon.world/@mer__edith/111563866152334347
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.
It doesn't. The API for displaying a notification is purely local.
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...
Sorry I should clarify, by "it" I meant any sort of ping must go through Firebase Cloud Messaging, not that the message content itself goes through Firebase.
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.
It's theoretically possible to just keep an app running in the background all the time and periodically poll a server.
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.
Then that's basically what I said right? That there is in practice no way to opt out of using Firebase if you want consistent notifications.
When running Signal without google play services, Signal reliably received push notifications and with minimal battery drain.
Do you have microG? That provides a compatibility layer for FCM.
Any application can send notifications without going through a server.
How? I'm not talking about an application backend server but a notification server which Google and Apple have for all apps. I'm not sure besides polling or having a persistent connection to send notifications to an app while that app is not running.
> this is by design of both companies.
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 by design of both companies.
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.
It sounds like you’re hinting at being unhappy with the lock-in forced by the ecosystem.
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.
Clearly they don't protect your privacy as evidenced by the post we're commenting on.
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.
Android doesn't store message history unless you explicitly enable that feature and neither does Signal send message content to Firebase.
You're angry about a huge amount of outright misinformation here.
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.
Sad to think there is a PostIt note somewhere in Virginia and written on it is a box labelled Signal, with an arrow pointing to a box labelled Apple servers, followed by a smirking smiley face pointing between the boxes with the message “encryption added and removed here”
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.
yes, since apple doesn't control the content of the pushes it is sent by application backends. that can only be controlled within each app
Signal should switch the default to being less verbose.
They should also signal your counterparty's security posture.
Basically, give you a heads up that the other side has settings that make the system less secure.
I'd prefer the receiving end looks at sender's metadata on the message, and uses that to determine where the line is between recipient-convenience and betrayal.
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."
The default should be "No name or content".
Name only strikes me as a fairer compromise between security and usability.
I thought name-only was the default.
> I thought name-only was the default
At least for me, it was name and content.
I may be misremembering, or it may have changed; I've been using Signal from the early days.
No it shouldn't. That makes the UX much worse, just to guard against the 0.00001% case where the FBI seizes your iPhone.
Not really, that would discourage use by normies.
users should switch to simpleX
When you put it up against each other it makes perfect sense, but I would never have thought about it in that way!
Thank you for adding this to the conversation.
I allway say it: it is the defaults, stupid (paraphrasign).
The Defaults have to be the most sensitive ones.
If you are a supposed super secure app, this should be the default.
Fwiw, in my Signal app on Android this setting is in
Settings > Notifications > Messages > Show
My Samsung also keeps a history of notification content. Under Settings->Notifications ->Advanced -> Notification History
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.
I need the notifications though.
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.
Disable Apple Intelligence summaries for sensitive app notifications too.
Given the quality of the summaries, you might want to keep them just for plausible deniability </s>
I guess enabling Lockdown mode might avoid this particular issue too, together with a bunch of other stuff?
Why would lockdown mode prevent this? I have lockdown mode on but that doesn't automatically make my notifications private.
Lockdown mode would prevent access to the data in theory.
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?).
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.
[1] https://support.apple.com/en-us/105120
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.
Maybe it should.
Originally enabled it just to avoid awkward moments
WhatsApp supports this too.
Settings > Notifications > Show preview
This seems to be the default for me, at least on Android.
Android also supports custom encrypted payloads so Signal doesn't have to give them to Google.