It always bears repeating, push notifications are not private, neither for Android, GrapheneOS, nor iOS, even if you use end-to-end encryption. If you are privacy conscious, you should either use settings to hide sensitive data from push notifications or turn them off altogether.
If you turn off notification history on Android, should be enough to avoid such "attacks". Hiding sensitive content inside notifications only hides it in the lock screen. If your OS keeps a clear log of them, it's useless.
Edit: didn't know Signal actually has settings to hide their own notifications. I was thinking about Android's "hide sensitive content" setting.
Signal only sends a "new message, retrieve the rest from Signal" ping to your phone through Firebase. It doesn't contain message details, just that you have a new message.
Local, on-device apps don't need to go through FCM or any other servers to show notifications, apps generate notifications offline.
Same goes for Signal, it doesn't ask FCM to deliver a notification, it asks to deliver a wakeup ping, and then the Signal app gets the message and generates a notification locally.
If you don't use Google Play Services, you don't get push notifications, so yes. Libre reimplementations of Google Play Services such as Gapps etc. or alternative push notification providers do not circumvent this issue, except possibly self-hosted push notification providers. This approach is really rare though and limited generally to very few apps.
You might be getting pull notifications, that's generally the workaround for push notifications being disabled - it generally increases battery usage because it forces the app to stay open in the background.
websocket based push notifications is still called push notifications in signal. this is the first time I hear the term "pull notifications", I don't think it's widely used.
This is about a history of notifications locally on the phone.
This is implemented outside of gms at least on my rom, and in the past I have also installed a separate app to do the same.
If you log your notifications ... that log can leak your notifications.
Yes, I know! Sorry for the confusion, I just wanted to take the opportunity to raise awareness about a privacy issue that lots of people aren't aware of
If I turn off notifications on my end, does the other person still generate a push notification when they send me a message, even if I never receive it?
Edit: Sorry, I think I misunderstood your question. If you don't have Google Play Services enabled but your friend does and messages you, no, a push notification won't be sent, but if you message them, one will be sent to them.
I thought you were asking if you just disabled notifications on your phone if that would prevent push notifications from being sent. I'll leave my original answer in case someone else has that question.
It depends on what exactly you mean, but usually not. If you mean in your phone's notifications management settings, that does not affect the push notifications being sent to Google/Apple servers, that's just a local setting to decide how your phone handles it.
Some apps, though rarely, allow you to disable push notifications from being sent. If it exists, this is inside a settings screen in the app itself or on the app provider's website somewhere. Generally, only privacy-conscious apps provide such settings.
Notification logging is usually done by some other part of android as far as I know. GMS is the typical way to deliver notifications and is a far more serious privacy concern, since it also directly passes googles servers and is not encrypted. However as others mentioned, signal does not send contents there, message notifications with the message contents stay on device.
A push notification is pretty much just a ping that wakes up the app that is supposed to show you the notification. There usually isnt much data in that ping, so the only thing the Google firebase servers (or whatever other backend solution you use) see is a timestamp and an app. If you then disable Notification historie (default is off bzw on GraphenOS) there is no other data stored anywhere.
That's metadata that every single chat service has, no matter if its E2EE or not, because that's the bare minimum they need to transmit anything at all. If that already isn't private for you then you'd have to stop using the internet or phonecalls entirely and go back to carrier pidgeons.
It depends on the app. Some apps do (or can be configured to) indeed send "empty"/blank notifications which just notify you that you've received a new message from an app, but not from whom, or what the message contains.
However most apps by default will contain more data, such as who the message is from, and some/all of the sent message body.
You seem to be under an impression that the actual notification that you see in the notification shade of your phone must go through FCM. That is not true. There are no external services involved in generating notifications on Android, apps can just show notifications by themselves.
What FCM is used for is sending a wakeup call to an app. The naming is confusing, but the "notification service" is not sending a notification in the sense of what you see in the notification shade. It is notifying an app of an event. The app can then react in any way it wants, possibly by creating a notification for the notification shade. But the notification you see in the UI of your phone didn't go through FCM.
Some apps do (or can be configured to) indeed send “empty”/blank notifications which just notify you that you’ve received a new message from an app, but not from whom, or what the message contains.
And this is a completely separate thing. Yes, you can configure apps to not show details in notifications, but that has nothing to do with FCM. It only controls what the app does locally, when generating the local notification, after FCM is no longer involved (if it was involved in the first place - many notifications don't need it, for example a notification from a timer app).
If you get a push notification on your phone, everything you see in that notification must by definition pass through the push notification service.
This statement is easy to disprove in another way too. FCM only supports sending up to 4KB of data, and yet you can get a notification with high resolution images. Which also shows that no, things you see in the notification didn't have to pass through the push notification service - the local app got the data and prepared the notification by itself, possibly after being woken up to do so by FCM.
Signal doesn't send anything in the payload. They just use it to wake the phone up and then download all messages that are waiting to be delivered through the usual encrypted means. All Google knows is that something happened at that time. They don't know anything else.
So it'll use TLS encryption, meaning that others on your network won't be able to snoop it, but not end-to-end encryption, so Google/Apple servers will see the plaintext of the push notification content.
This is a limitation of the specific implementation of how push notifications work. End-to-end encrypted push notifications would be technically possible but it would require Apple/Google to make it possible. Developers can't implement it without getting you to run some services yourself, either self-hosted or a long-running background process on your phone, which would be a battery drain.
The link you shared isn't really relevant to push notifications specifically.
The best happy medium we can get is to send empty/blank push notifications, which some apps including Signal offer as an option, but you often need to set it that way in the settings. I think Signal does that by default, but very few apps do.
The push notification for most messengers is a ping with little to no data in it, telling the app to grab messages directly via TLS. That's how e2e works with push.
It depends on the app. Some apps do (or can be configured to) indeed send “empty”/blank notifications which just notify you that you’ve received a new message from an app, but not from whom, or what the message contains.
However most apps by default will contain more data, such as who the message is from, and some/all of the sent message body.
If you get a push notification on your phone, everything you see in that notification must by definition pass through the push notification service.
I'd disagree with "most messengers" doing that, in my experience, most don't do it by default. Signal is a pretty rare exception to do so by default.
I'd disagree with "most messengers" doing that, in my experience, most don't do it by default. Signal is a pretty rare exception to do so by default.
What messenger doesn't? Signal, WhatsApp, Matrix, Snapchat, Discord, Telegram, etc. I'd say "most" is pretty accurate. No idea what Wechat does, but that's a whole different story.
If you get a push notification on your phone, everything you see in that notification must by definition pass through the push notification service.
Also not true. What you "see" could have been retrieved post-notification, as described in the message you responded to. What you see has nothing to do with what goes through the push service and is a full technical inacurracy.
I don't know about others, but Mattermost sends everything by default. first to mattermost's server, then from there to firebase/apple. there's a setting to not send message body, but it's not set by default
If you use GrapheneOS with push notifications, after enabling Google Play Services, those push notifications are relayed through Google servers. Most apps will include message sender and text in the push notification, meaning that data will pass through Google servers and they can read it.
If you are a GrapheneOS user and leave Google Play Services disabled - which they are by default - you have nothing to worry about, but notifications are generally delayed and use more battery as a downside.
What's the purpose of keeping a history of seen notifications in a database? That shit should be being automatically purged if it needs to exist to show it, after its been dismissed.
I wonder if this revelation will trigger a change in how it works, since apple has often tried to do things securely?
If you accidentally dismiss a notification, you can go back in the history to see it. Or if you dismiss a message notification that you want to respond to later. Or if a notification keeps popping up and disappearing and you want to investigate.
Oh I honestly didnt understand there's a perpetual database you can go back and look at, I didnt even know i had one on android, I just turned that off.
I understood it as they need a database to hold the notifications you should be shown and it gets purged eventually kinda thing.
As a history it makes sense, and that its something that can leak.
Also if you leave it on, uninstalling an app should definitely purge its history.
The poor FBI has kinda triggered a Streisand effect. We used this thing no one knows about to win a case and shit now they know about it and are turning it off!
My android shows a history of notifications. Not sure what the retention period is. It does add conveniece by allowing me to check dismissed notifications. It allows some monitoring about the type, content, and frequency of notifications as well as control to block them.
It certainly now appears the convenience isn't worth the loss of privacy, though.
Once in a while I get a notification that, for one reason or another, doesn't actually bring me to the content it was supposed to link to and instead brings me to the main page of an app, and sometimes it's difficult or impossible to find where the link was supposed to go
But going in through the notification history, the second try usually takes me where it was supposed to go
Apple has gone out of their way to fuck with the government trying to get data from people phones, I really don't think this was something done on purpose to help them.
The data has to be stored somewhere to be shown, so a temporary spot existing isn't a surprise. It almost sounds more like lazy developers not thinking the government could access the history that only gets purged after X amount of time, instead of continually being pruned.
You can export them from the Google authenticator app and import into something like keepassdx. Its a bit of a workaround doing such, having to read the data from the QR code but entirely possible.
Not sure you would, both are FOSS and if it works I wouldn't change. Looks like similar feature sets at the core, so unless you want something specific I'd leave it.
End-to-end encryption is the final boss of false-sense-of-security.
Like, it's great and all, but it's not universal perfect privacy the way a lot of people seem to hold it up as if it were. You have to understand what it's actually defending against, and who might be blocked by that, and more importantly, who won't be. Because the list of potential adversaries it is actually useful against are becoming narrower and increasingly out-of-date.
Encryption alone prevents the messages being read in transit between you and Signal, and obviously that's fundamental basic security at this point. Signal being end-to-end encrypted prevents your messages being spied on by Signal, but ironically they're probably one of the most trustworthy actors in this whole chain, so the fact that it's protected from them, while commendable, is not particularly valuable security. They were probably not the ones going to spy on you in the first place. They have prevented themselves from being capable of doing so, and that's good, but if that's all you're worried about and you now think your privacy problems are solved, you're completely missing the point because instead of Signal themselves, you need to be worried about the guy currently standing over your shoulder with his camera filming.
Treat your phone and your Windows computer like they are permanently compromised with a rootkit taking continuous screenshots of everything you do and feeding that to their big tech overlords, because they might as well be.
For that matter, even Linux PCs still have their black box "intel management engine" or similar processor running constantly and potentially watching everything you do, although I don't believe they actually do that in any reasonable case, we need to understand they have both the capability and the motivation to be, at least in some cases, compromised by adversaries which may include (but are not limited to) tech companies and governments. You can't even trust your "dumb monitor" unless you've audited every chip inside it, you'll never know if it could be scanning everything on your screen and feeding it back through HDMI/DP back-channels or even through powerline networking. You also don't know if the same kind of things could be happening on the other side that you're sending/receiving from. Sure the network trip is protected, but that's hardly the only place you're vulnerable to interception.
That probably all sounds paranoid and extreme and improbable, and it is, but the point is end-to-end encryption does nothing to help you against any of that, so don't make the mistake of assuming you're 100% safe because it's end-to-end encrypted. The "end" is not what you think it is and it's not paranoid to at least understand that and accept the risk with the understanding.
I realize I am probably preaching to the choir here, and most of you probably understand this as well as I do. But I'm also pretty sure a lot of people truly believe it's more secure against eavesdropping than it actually is and that needs to change. The surveillance state is adapting and expanding rapidly and I fear they've started getting ahead of many of us. Beware, and plan carefully in the months and years ahead.
End-to-end encryption is the one of the most basic requirements for a communication system to be secure. Endpoint authentication is another. Message authentication is the third. After those 3 are fulfilled, further requirements can vary from system to system.
It's like electrical or building code. Just because it's compliant doesn't mean it's safe, but if it's not compliant it's almost certainly not safe. Necessary, not sufficient!
Is your keyboard app secure (yes seriously)? Does you device store notification details? Can your notifications be viewed without unlocking the device?
Those are all little concerns that need to be considered.
I understand the intent, but this is not phrased well.
prevents your messages being spied on by Signal, but ironically they’re probably one of the most trustworthy actors in this whole chain, so the fact that it’s protected from them, while commendable, is not particularly valuable security
It's extremely valuable security, because most companies, even if they don't want to spy on you might be compelled to by court order. And those companies often think their security is sufficient because they have good intentions, and they expect the government to have good intentions when they're going as far as getting a court order. (I also suspect more court orders are justified than not, but a few bad subpoenas spoil the bunch.) The fact that they physically are unable is quite important.
All your points about how things around that can fail are valid.
Somewhat like it, but with different operational goals.
FreeBSD focuses on wide hardware compatibility and very high speed.
OpenBSD focuses on security, exclusively. It's slower and with a narrower range of supported hardware, but a MUCH higher effort in security, assurance and audit.
So, the fact that some bugs have been found in FreeBSD is more or less irrelevant to the security of OpenBSD
You may not be aware, but find it interesting that MacOS is also a BSD variant, and there was a distro called NetBSD which was (is?) focused on what you'd expect from the name of it.
Another thing you might not know is that the OpenBSD folks also publish OpenSSH which is a very well regarded and widely used package.
Of course all software is subject to bugs/error/vulnerabilities and OpenSSH as well as OpenBSD are constantly being reviewed, revised and audited for potential security issues.
That's a interesting approach. It kind of backdoors a lot of private communication efforts. I can't even be sure, if disabling notifications for signal would avoid them from showing up in the database anyways
Clever. Not much you can do for this except not subscribe your app to the notifications API, or take extra steps to attempt to clear them, but I don't remember that being an option on iOS. Going to be an interesting fix.
Correct - the notification API from the server is literally just a ping to inform it there's something to fetch. The app itself fills the notification content. If you tell it to leave it blank there's nothing cached outside the application storage.
Apps *can* let the server fill the entire notification content without waking the app, but that's not how Signal works
Play Store version uses Google’s push/FCM but yeah even then it's just the generic ping data they get as I understand it. Some may not even want them to have timestamps, so there's solutions to that:
Can take it a step further grabbing the non-google APK on their website instead or using the hardened Signal fork named Molly. Both use a persistent WebSocket connection to Signal’s servers instead.
I imagine a similar exploit will work on Android devices, as well. Wouldn't have considered it, but it may be a good idea to figure out how to disable the content from appearing in the Android notifs, too.
It's not an exploit. It's a built-in setting in Signal, and the Android options are identical to the one displayed above. You can turn off notification history in Android as well, so it has no stored record of cleared notifications at all.
This is for the client display only, and not the iOS API interface as I'm discussing. It's not very plainly laid out in the docs, but one would assume any queuing of content into the notification system would be stored or cached if not cleared. There doesn't seem to be a way to have a client of that system to clear it's own data once it's in there, just cancel last notification.
I think it depends on where they're turned off. In Signal itself you can change it to remove the message text from the notification, or a few other variations.
If you just have notifications off on your phone in general, the notification is still being generated by the app and could potentially be stored somewhere on a server before being filtered out by your phone.
Any software allowed on an appstore can be backdoored and decrypted many different ways. Even if the notification routing was turned off to prevent this, you still have a virtual keyboard that can be debugged at the system level or in one of the secure enclaves running on an iPhone. All of it is an illusion of security being sold for profit. Even the devices allowed to be sold must be backdoored many differnet ways by the state. In other words, anything that actually provided security and anonymity either from a hardware or software level would never be allowed on the market in the first place.
For the push notification yes. Once it pulls the message and creates the full notification with preview, that can be added to the local notification history.
112 Comments
bearboiblake@pawb.social · 198 pts · 135d
It always bears repeating, push notifications are not private, neither for Android, GrapheneOS, nor iOS, even if you use end-to-end encryption. If you are privacy conscious, you should either use settings to hide sensitive data from push notifications or turn them off altogether.
MrSoup@lemmy.zip · 45 pts · 135d
If you turn off notification history on Android, should be enough to avoid such "attacks". Hiding sensitive content inside notifications only hides it in the lock screen. If your OS keeps a clear log of them, it's useless.
Edit: didn't know Signal actually has settings to hide their own notifications. I was thinking about Android's "hide sensitive content" setting.
4am@lemmy.zip · 39 pts · 135d
Notifications go through FireBase Cloud Messaging (FCM) on Android. They bounce off a Google server. Even from local, on-device apps.
Same with iOS.
They can read and store every one of them, and you don’t control the encryption keys.
bjoern_tantau@swg-empire.de · 41 pts · 135d
But they only instruct Signal to wake up and download whatever is waiting. They don't contain the message contents.
CorrectAlias@piefed.blahaj.zone · 24 pts · 135d
Signal only sends a "new message, retrieve the rest from Signal" ping to your phone through Firebase. It doesn't contain message details, just that you have a new message.
dev_null@lemmy.ml · 6 pts · 134d
Local, on-device apps don't need to go through FCM or any other servers to show notifications, apps generate notifications offline.
Same goes for Signal, it doesn't ask FCM to deliver a notification, it asks to deliver a wakeup ping, and then the Signal app gets the message and generates a notification locally.
MrSoup@lemmy.zip · 4 pts · 135d
By not having Google Play Services, isn't this prevented?
bearboiblake@pawb.social · 13 pts · 135d
If you don't use Google Play Services, you don't get push notifications, so yes. Libre reimplementations of Google Play Services such as Gapps etc. or alternative push notification providers do not circumvent this issue, except possibly self-hosted push notification providers. This approach is really rare though and limited generally to very few apps.
degenerate_neutron_matter@fedia.io · 6 pts · 135d
bearboiblake@pawb.social · 15 pts · 135d
You might be getting pull notifications, that's generally the workaround for push notifications being disabled - it generally increases battery usage because it forces the app to stay open in the background.
Redjard@reddthat.com · 6 pts · 135d
Molly supports unified push
degenerate_neutron_matter@fedia.io · 5 pts · 135d
WhyJiffie@sh.itjust.works · 2 pts · 133d
websocket based push notifications is still called push notifications in signal. this is the first time I hear the term "pull notifications", I don't think it's widely used.
semperverus@lemmy.world · 3 pts · 135d
Is this true if you don't have Google Play Services but the person you're messaging does? Is one person cutting GPS out enough?
bearboiblake@pawb.social · 3 pts · 135d
The message you send them would probably go through as a push notification to them, but the message they send you wouldn't.
Redjard@reddthat.com · 3 pts · 135d
This is about a history of notifications locally on the phone.
This is implemented outside of gms at least on my rom, and in the past I have also installed a separate app to do the same.
If you log your notifications ... that log can leak your notifications.
bearboiblake@pawb.social · 2 pts · 135d
Yes, I know! Sorry for the confusion, I just wanted to take the opportunity to raise awareness about a privacy issue that lots of people aren't aware of
frongt@lemmy.zip · 0 pts · 135d
If I turn off notifications on my end, does the other person still generate a push notification when they send me a message, even if I never receive it?
bearboiblake@pawb.social · 1 pts · 135d
Edit: Sorry, I think I misunderstood your question. If you don't have Google Play Services enabled but your friend does and messages you, no, a push notification won't be sent, but if you message them, one will be sent to them.
I thought you were asking if you just disabled notifications on your phone if that would prevent push notifications from being sent. I'll leave my original answer in case someone else has that question.
It depends on what exactly you mean, but usually not. If you mean in your phone's notifications management settings, that does not affect the push notifications being sent to Google/Apple servers, that's just a local setting to decide how your phone handles it.
Some apps, though rarely, allow you to disable push notifications from being sent. If it exists, this is inside a settings screen in the app itself or on the app provider's website somewhere. Generally, only privacy-conscious apps provide such settings.
frongt@lemmy.zip · 1 pts · 135d
So how does it decide to generate a push notification or not?
Redjard@reddthat.com · 2 pts · 135d
Notification logging is usually done by some other part of android as far as I know. GMS is the typical way to deliver notifications and is a far more serious privacy concern, since it also directly passes googles servers and is not encrypted. However as others mentioned, signal does not send contents there, message notifications with the message contents stay on device.
MalMen@masto.pt · -2 pts · 135d
@4am @MrSoup wtf
bearboiblake@pawb.social · 3 pts · 135d
I'm actually talking about sensitive data on Google/Apple hosted servers, as well as on the phone itself!
Jako302@feddit.org · 15 pts · 135d
That depends on your definition of private.
A push notification is pretty much just a ping that wakes up the app that is supposed to show you the notification. There usually isnt much data in that ping, so the only thing the Google firebase servers (or whatever other backend solution you use) see is a timestamp and an app. If you then disable Notification historie (default is off bzw on GraphenOS) there is no other data stored anywhere.
That's metadata that every single chat service has, no matter if its E2EE or not, because that's the bare minimum they need to transmit anything at all. If that already isn't private for you then you'd have to stop using the internet or phonecalls entirely and go back to carrier pidgeons.
bearboiblake@pawb.social · 6 pts · 135d
It depends on the app. Some apps do (or can be configured to) indeed send "empty"/blank notifications which just notify you that you've received a new message from an app, but not from whom, or what the message contains.
However most apps by default will contain more data, such as who the message is from, and some/all of the sent message body.
dev_null@lemmy.ml · 3 pts · 134d
You seem to be under an impression that the actual notification that you see in the notification shade of your phone must go through FCM. That is not true. There are no external services involved in generating notifications on Android, apps can just show notifications by themselves.
What FCM is used for is sending a wakeup call to an app. The naming is confusing, but the "notification service" is not sending a notification in the sense of what you see in the notification shade. It is notifying an app of an event. The app can then react in any way it wants, possibly by creating a notification for the notification shade. But the notification you see in the UI of your phone didn't go through FCM.
And this is a completely separate thing. Yes, you can configure apps to not show details in notifications, but that has nothing to do with FCM. It only controls what the app does locally, when generating the local notification, after FCM is no longer involved (if it was involved in the first place - many notifications don't need it, for example a notification from a timer app).
This statement is easy to disprove in another way too. FCM only supports sending up to 4KB of data, and yet you can get a notification with high resolution images. Which also shows that no, things you see in the notification didn't have to pass through the push notification service - the local app got the data and prepared the notification by itself, possibly after being woken up to do so by FCM.
VibeSurgeon@piefed.social · 1 pts · 134d
This is immediately disprovable by anyone who has ever implemented push notifications on Android
apftwb@lemmy.world · 5 pts · 135d
I am no Android developer, but can't the push notification payload be encrypted?
https://firebase.google.com/docs/cloud-messaging/encryption
A better question is if Signal does this already.
bjoern_tantau@swg-empire.de · 6 pts · 135d
Signal doesn't send anything in the payload. They just use it to wake the phone up and then download all messages that are waiting to be delivered through the usual encrypted means. All Google knows is that something happened at that time. They don't know anything else.
lemonuri@infosec.pub · 2 pts · 135d
No, push always leaks metadata to Google. Use molly (signal fork on fdroid) and unified push instead.
bearboiblake@pawb.social · 0 pts · 135d
So it'll use TLS encryption, meaning that others on your network won't be able to snoop it, but not end-to-end encryption, so Google/Apple servers will see the plaintext of the push notification content.
This is a limitation of the specific implementation of how push notifications work. End-to-end encrypted push notifications would be technically possible but it would require Apple/Google to make it possible. Developers can't implement it without getting you to run some services yourself, either self-hosted or a long-running background process on your phone, which would be a battery drain.
The link you shared isn't really relevant to push notifications specifically.
The best happy medium we can get is to send empty/blank push notifications, which some apps including Signal offer as an option, but you often need to set it that way in the settings. I think Signal does that by default, but very few apps do.
Fmstrat@lemmy.world · 2 pts · 135d
Not true.
The push notification for most messengers is a ping with little to no data in it, telling the app to grab messages directly via TLS. That's how e2e works with push.
bearboiblake@pawb.social · 1 pts · 135d
As I wrote elsewhere:
I'd disagree with "most messengers" doing that, in my experience, most don't do it by default. Signal is a pretty rare exception to do so by default.
Fmstrat@lemmy.world · 1 pts · 134d
What messenger doesn't? Signal, WhatsApp, Matrix, Snapchat, Discord, Telegram, etc. I'd say "most" is pretty accurate. No idea what Wechat does, but that's a whole different story.
Also not true. What you "see" could have been retrieved post-notification, as described in the message you responded to. What you see has nothing to do with what goes through the push service and is a full technical inacurracy.
WhyJiffie@sh.itjust.works · 1 pts · 133d
I don't know about others, but Mattermost sends everything by default. first to mattermost's server, then from there to firebase/apple. there's a setting to not send message body, but it's not set by default
Fmstrat@lemmy.world · 1 pts · 133d
Hmm, does that mean "most" since it... matters most? Eh? Eh? Ehhhhhhh?
https://docs.mattermost.com/administration-guide/configure/push-notification-server-configuration-settings.html#id-only-push-notifications
Yea not sure why they don't do that by default since they claim they are a Slack competitor. You'd think a corporate entity would want that.
timestatic@feddit.org · 4 pts · 135d
Wdym push notifications are not private on Graphene??
bearboiblake@pawb.social · 11 pts · 135d
If you use GrapheneOS with push notifications, after enabling Google Play Services, those push notifications are relayed through Google servers. Most apps will include message sender and text in the push notification, meaning that data will pass through Google servers and they can read it.
If you are a GrapheneOS user and leave Google Play Services disabled - which they are by default - you have nothing to worry about, but notifications are generally delayed and use more battery as a downside.
WhyJiffie@sh.itjust.works · 1 pts · 133d
this is not about push notifications. signal is smart enough to not send your texts to firebase
but wait a minute! I just remembered something.
isnt it that they couldn't even send you the plain text message itself through push, because only your device can decrypt it?
NotMyOldRedditName@lemmy.world · 104 pts · 135d
What's the purpose of keeping a history of seen notifications in a database? That shit should be being automatically purged if it needs to exist to show it, after its been dismissed.
I wonder if this revelation will trigger a change in how it works, since apple has often tried to do things securely?
frongt@lemmy.zip · 43 pts · 135d
If you accidentally dismiss a notification, you can go back in the history to see it. Or if you dismiss a message notification that you want to respond to later. Or if a notification keeps popping up and disappearing and you want to investigate.
dance_ninja@lemmy.world · 22 pts · 135d
I just checked if there were any controls for this on Android. As far as I could tell, you can only toggle it on/off.
Off clears the history, but I wish we could do more than all or nothing. I don't need a history of more than a week at most.
frongt@lemmy.zip · 9 pts · 135d
I have it turned on. It only shows the last 24 hours.
yessikg@fedia.io · 3 pts · 135d
I just checked and it seems to be off by default in e OS, another W
NotMyOldRedditName@lemmy.world · 8 pts · 135d
Oh I honestly didnt understand there's a perpetual database you can go back and look at, I didnt even know i had one on android, I just turned that off.
I understood it as they need a database to hold the notifications you should be shown and it gets purged eventually kinda thing.
As a history it makes sense, and that its something that can leak.
Also if you leave it on, uninstalling an app should definitely purge its history.
MrShankles@reddthat.com · 8 pts · 135d
TIL I have a "notification history" toggle setting
NotMyOldRedditName@lemmy.world · 10 pts · 135d
The poor FBI has kinda triggered a Streisand effect. We used this thing no one knows about to win a case and shit now they know about it and are turning it off!
WhyJiffie@sh.itjust.works · 1 pts · 133d
that part can just happen in volatile memory
XeroxCool@lemmy.world · 6 pts · 135d
My android shows a history of notifications. Not sure what the retention period is. It does add conveniece by allowing me to check dismissed notifications. It allows some monitoring about the type, content, and frequency of notifications as well as control to block them.
It certainly now appears the convenience isn't worth the loss of privacy, though.
sem@piefed.blahaj.zone · 1 pts · 134d
How do you see them
XeroxCool@lemmy.world · 2 pts · 133d
Settings>notifications>notifications history on my pixel. Looks like just 24 hours of history, including the content
Fondots@lemmy.world · 2 pts · 135d
Once in a while I get a notification that, for one reason or another, doesn't actually bring me to the content it was supposed to link to and instead brings me to the main page of an app, and sometimes it's difficult or impossible to find where the link was supposed to go
But going in through the notification history, the second try usually takes me where it was supposed to go
NotMyOldRedditName@lemmy.world · 2 pts · 135d
Ive had that issue as well, deeplinks can be fickle creatures if the app isnt perfectly set up and youre potentially in a spot it fails in.
bitjunkie@lemmy.world · -1 pts · 135d
Control.
NotMyOldRedditName@lemmy.world · 10 pts · 135d
Apple has gone out of their way to fuck with the government trying to get data from people phones, I really don't think this was something done on purpose to help them.
The data has to be stored somewhere to be shown, so a temporary spot existing isn't a surprise. It almost sounds more like lazy developers not thinking the government could access the history that only gets purged after X amount of time, instead of continually being pruned.
osanna@lemmy.vg · 2 pts · 134d
Remember when the fbi wanted access to a perp’s iPhone and they told the govt to fuck off?
themurphy@lemmy.ml · -1 pts · 135d
No way, it's for the data collection.
They dont want to share it, that's right, but it's very much not done by accident.
sturmblast@lemmy.world · -3 pts · 135d
Did you read the headline?
absGeekNZ@lemmy.nz · 64 pts · 135d
Notification history is off by default in GrapheneOS....so that is nice.
JasonDJ@lemmy.zip · 8 pts · 135d
I really want to convert my pixel but I'm so damn lazy.
Mostly worried about losing TOTP apps and configurations. I really should be backing those up.
epicshepich@programming.dev · 18 pts · 135d
Aegis works perfectly. My university used Duo and then Okta, and both worked. I was unable to get Authy to work, though.
absGeekNZ@lemmy.nz · 3 pts · 135d
Squizzy@lemmy.world · 11 pts · 135d
It is beyond easy, connect and press the button.
Just take note of your settings and apps to duplicate.
dai@lemmy.world · 4 pts · 135d
You can export them from the Google authenticator app and import into something like keepassdx. Its a bit of a workaround doing such, having to read the data from the QR code but entirely possible.
https://www.keepassdx.com/
Mine sync between devices using Syncthing, merging forked credentials is easy enough to fix too with the desktop app.
Blaster_M@lemmy.world · 3 pts · 135d
Authy doesn't work, but Authy is not that great privacy-wise. I use a self-host app anyway that's backed up.
tomatolung@lemmy.world · 3 pts · 135d
https://f-droid.org/packages/org.liberty.android.freeotpplus
ilillilillilillililli@lemmy.world · 4 pts · 135d
Why would I use this over Aegis? Genuine question. Aegis has been working flawlessly for years.
tomatolung@lemmy.world · 2 pts · 135d
Not sure you would, both are FOSS and if it works I wouldn't change. Looks like similar feature sets at the core, so unless you want something specific I'd leave it.
Just good to have options.
BladeFederation@piefed.social · 1 pts · 135d
You can export and import Totp codes pretty easily with most apps I've tried. Except Microsoft's.
frongt@lemmy.zip · 0 pts · 135d
You should really not be backing them up. You should be saving and securing your recovery codes.
BigAssZombie@lemmy.world · 1 pts · 130d
two different things, it won't stop relay history
buddascrayon@lemmy.world · 0 pts · 134d
Yeah if you're going to go hard on protesting, you should probably not be using an iPhone. Literally the least secure phone in the entire universe.
percent@infosec.pub · 55 pts · 135d
iPhones save old notifications in a database? Why?
Landless2029@lemmy.world · 48 pts · 135d
So it can relay notifications across devices like your Apple watch, macbook, iPad and iToilet
osanna@lemmy.vg · 13 pts · 134d
Brings new meaning to piece of shit device.
PhoenixDog@lemmy.world · 1 pts · 133d
Enshitification indeed.
recursivethinking@lemmy.world · 39 pts · 135d
Android does this too (ETA: by default). There's a history. You can set Signal to not display message content in notifications.
Hyaline_Cat@lemmy.world · 15 pts · 135d
Thannnnk you! My Signal notifications now vaguely say I have a new message and nothing more. Good catch
MML@sh.itjust.works · 9 pts · 135d
Is it like easy to get to? Could actually be useful for some stuff. Yes it's right under notifications, turns out mines been off though.
cecilkorik@piefed.ca · 48 pts · 135d
End-to-end encryption is the final boss of false-sense-of-security.
Like, it's great and all, but it's not universal perfect privacy the way a lot of people seem to hold it up as if it were. You have to understand what it's actually defending against, and who might be blocked by that, and more importantly, who won't be. Because the list of potential adversaries it is actually useful against are becoming narrower and increasingly out-of-date.
Encryption alone prevents the messages being read in transit between you and Signal, and obviously that's fundamental basic security at this point. Signal being end-to-end encrypted prevents your messages being spied on by Signal, but ironically they're probably one of the most trustworthy actors in this whole chain, so the fact that it's protected from them, while commendable, is not particularly valuable security. They were probably not the ones going to spy on you in the first place. They have prevented themselves from being capable of doing so, and that's good, but if that's all you're worried about and you now think your privacy problems are solved, you're completely missing the point because instead of Signal themselves, you need to be worried about the guy currently standing over your shoulder with his camera filming.
Treat your phone and your Windows computer like they are permanently compromised with a rootkit taking continuous screenshots of everything you do and feeding that to their big tech overlords, because they might as well be.
For that matter, even Linux PCs still have their black box "intel management engine" or similar processor running constantly and potentially watching everything you do, although I don't believe they actually do that in any reasonable case, we need to understand they have both the capability and the motivation to be, at least in some cases, compromised by adversaries which may include (but are not limited to) tech companies and governments. You can't even trust your "dumb monitor" unless you've audited every chip inside it, you'll never know if it could be scanning everything on your screen and feeding it back through HDMI/DP back-channels or even through powerline networking. You also don't know if the same kind of things could be happening on the other side that you're sending/receiving from. Sure the network trip is protected, but that's hardly the only place you're vulnerable to interception.
That probably all sounds paranoid and extreme and improbable, and it is, but the point is end-to-end encryption does nothing to help you against any of that, so don't make the mistake of assuming you're 100% safe because it's end-to-end encrypted. The "end" is not what you think it is and it's not paranoid to at least understand that and accept the risk with the understanding.
I realize I am probably preaching to the choir here, and most of you probably understand this as well as I do. But I'm also pretty sure a lot of people truly believe it's more secure against eavesdropping than it actually is and that needs to change. The surveillance state is adapting and expanding rapidly and I fear they've started getting ahead of many of us. Beware, and plan carefully in the months and years ahead.
Eufalconimorph@discuss.tchncs.de · 31 pts · 135d
End-to-end encryption is the one of the most basic requirements for a communication system to be secure. Endpoint authentication is another. Message authentication is the third. After those 3 are fulfilled, further requirements can vary from system to system.
It's like electrical or building code. Just because it's compliant doesn't mean it's safe, but if it's not compliant it's almost certainly not safe. Necessary, not sufficient!
Gormadt@lemmy.blahaj.zone · 7 pts · 135d
Exactly!
Is your keyboard app secure (yes seriously)? Does you device store notification details? Can your notifications be viewed without unlocking the device?
Those are all little concerns that need to be considered.
Serinus@lemmy.world · 29 pts · 135d
I understand the intent, but this is not phrased well.
It's extremely valuable security, because most companies, even if they don't want to spy on you might be compelled to by court order. And those companies often think their security is sufficient because they have good intentions, and they expect the government to have good intentions when they're going as far as getting a court order. (I also suspect more court orders are justified than not, but a few bad subpoenas spoil the bunch.) The fact that they physically are unable is quite important.
All your points about how things around that can fail are valid.
cecilkorik@piefed.ca · 14 pts · 135d
That's a fair criticism and an important clarification, I agree.
Scirocco@lemmy.world · -1 pts · 135d
Ahem may introduce you to OpenBSD
SuspciousCarrot78@lemmy.world · 2 pts · 135d
Scirocco@lemmy.world · 1 pts · 124d
Somewhat like it, but with different operational goals.
FreeBSD focuses on wide hardware compatibility and very high speed.
OpenBSD focuses on security, exclusively. It's slower and with a narrower range of supported hardware, but a MUCH higher effort in security, assurance and audit.
So, the fact that some bugs have been found in FreeBSD is more or less irrelevant to the security of OpenBSD
You may not be aware, but find it interesting that MacOS is also a BSD variant, and there was a distro called NetBSD which was (is?) focused on what you'd expect from the name of it.
Another thing you might not know is that the OpenBSD folks also publish OpenSSH which is a very well regarded and widely used package.
Of course all software is subject to bugs/error/vulnerabilities and OpenSSH as well as OpenBSD are constantly being reviewed, revised and audited for potential security issues.
https://en.wikipedia.org/wiki/OpenSSH
AzuraTheSpellkissed@lemmy.blahaj.zone · 37 pts · 135d
That's a interesting approach. It kind of backdoors a lot of private communication efforts. I can't even be sure, if disabling notifications for signal would avoid them from showing up in the database anyways
SnoringEarthworm@sh.itjust.works · 47 pts · 135d
It should.
Signal has internal settings for exposing or not exposing the sender/content of messages to iOS notifications.
dudesss@lemmy.ca · 22 pts · 135d
Use Molly as your Signal client instead. It solves this.
Landless2029@lemmy.world · 15 pts · 135d
Molly is always the answer.
nutbutter@discuss.tchncs.de · 7 pts · 134d
Hehe.
WhyJiffie@sh.itjust.works · 1 pts · 133d
does not by default. you still have to disable showing notification details, if you don't want to turn off history
dudesss@lemmy.ca · 1 pts · 133d
oh, I remember mine being by default. Thanks for sharing though.
just_another_person@lemmy.world · 11 pts · 135d
Clever. Not much you can do for this except not subscribe your app to the notifications API, or take extra steps to attempt to clear them, but I don't remember that being an option on iOS. Going to be an interesting fix.
crank0271@lemmy.world · 46 pts · 135d
On iOS, under Settings > Notifications > Notification Content
evasive_chimpanzee@lemmy.world · 14 pts · 135d
I'm assuming that changes what it actually displays, but is there confirmation that those data dont enter the notification system on the back end?
n3ur0n@discuss.tchncs.de · 17 pts · 135d
On Android the setting is within the Signal app, so I assume it won't leave the app and therefore won't enter the notification system.
Natanael@slrpnk.net · 15 pts · 135d
Correct - the notification API from the server is literally just a ping to inform it there's something to fetch. The app itself fills the notification content. If you tell it to leave it blank there's nothing cached outside the application storage.
Apps *can* let the server fill the entire notification content without waking the app, but that's not how Signal works
BurgerBaron@piefed.social · 6 pts · 135d
Play Store version uses Google’s push/FCM but yeah even then it's just the generic ping data they get as I understand it. Some may not even want them to have timestamps, so there's solutions to that:
Can take it a step further grabbing the non-google APK on their website instead or using the hardened Signal fork named Molly. Both use a persistent WebSocket connection to Signal’s servers instead.
Chozo@fedia.io · 7 pts · 135d
I imagine a similar exploit will work on Android devices, as well. Wouldn't have considered it, but it may be a good idea to figure out how to disable the content from appearing in the Android notifs, too.
Telorand@reddthat.com · 6 pts · 135d
It's not an exploit. It's a built-in setting in Signal, and the Android options are identical to the one displayed above. You can turn off notification history in Android as well, so it has no stored record of cleared notifications at all.
Cherry@piefed.social · 6 pts · 135d
Thanks for taking the time to post a helpful instruction.
just_another_person@lemmy.world · 6 pts · 135d
This is for the client display only, and not the iOS API interface as I'm discussing. It's not very plainly laid out in the docs, but one would assume any queuing of content into the notification system would be stored or cached if not cleared. There doesn't seem to be a way to have a client of that system to clear it's own data once it's in there, just cancel last notification.
homes@piefed.world · 3 pts · 135d
glad to know this setting is available
franzbroetchen@feddit.org · -2 pts · 135d
homes@piefed.world · 2 pts · 135d
yeah, my first reaction was, "hmmm, clever..."
eager_eagle@lemmy.world · 10 pts · 135d
my signal notification history is a lot of "Locked message"
CuddlesMcBubblefun@lemmy.world · 10 pts · 135d
You know, I'm starting to think that maybe the "drive bay full of thermite" guy way back in the day WASN'T crazy...
Jalfred_prurock@lemmy.today · 8 pts · 135d
What if your notifications are turned off? Is anything stored in that circumstance?
xthexder@l.sw0.com · 5 pts · 135d
I think it depends on where they're turned off. In Signal itself you can change it to remove the message text from the notification, or a few other variations.
If you just have notifications off on your phone in general, the notification is still being generated by the app and could potentially be stored somewhere on a server before being filtered out by your phone.
homesweethomeMrL@lemmy.world · 6 pts · 135d
Not allowing notifications has been SOP since the beginning.
Go through your settings. There’s almost certainly some app doing something you don’t prefer.
RabbitBBQ@lemmy.world · 3 pts · 135d
Any software allowed on an appstore can be backdoored and decrypted many different ways. Even if the notification routing was turned off to prevent this, you still have a virtual keyboard that can be debugged at the system level or in one of the secure enclaves running on an iPhone. All of it is an illusion of security being sold for profit. Even the devices allowed to be sold must be backdoored many differnet ways by the state. In other words, anything that actually provided security and anonymity either from a hardware or software level would never be allowed on the market in the first place.
tirateimas@lemmy.pt · 3 pts · 135d
doesn't signal use empty notifications by default?
frongt@lemmy.zip · 8 pts · 135d
For the push notification yes. Once it pulls the message and creates the full notification with preview, that can be added to the local notification history.