- cross-posted to:
- technology@piefed.social
- cross-posted to:
- technology@piefed.social
You must log in or # to comment.
Notification history is off by default in GrapheneOS…so that is nice.
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.
It is beyond easy, connect and press the button.
Just take note of your settings and apps to duplicate.
Aegis works perfectly. My university used Duo and then Okta, and both worked. I was unable to get Authy to work, though.
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.
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.
I have it turned on. It only shows the last 24 hours.
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.
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
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.
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.
Did you read the headline?
Control.
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.
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.
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.
Wdym push notifications are not private on Graphene??
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.
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.
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.
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.
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.
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.
But they only instruct Signal to wake up and download whatever is waiting. They don’t contain the message contents.
By not having Google Play Services, isn’t this prevented?
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.
I don’t use Play Services and still get push notifications from Signal, so they’re clearly using an alternative implementation.
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.
That would make sense.
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?
The message you send them would probably go through as a push notification to them, but the message they send you wouldn’t.
I’m actually talking about sensitive data on Google/Apple hosted servers, as well as on the phone itself!
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.
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.
No, push always leaks metadata to Google. Use molly (signal fork on fdroid) and unified push instead.
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
It should.
Signal has internal settings for exposing or not exposing the sender/content of messages to iOS notifications.
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.
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.
On iOS, under Settings > Notifications > Notification Content
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.
Thanks for taking the time to post a helpful instruction.
glad to know this setting is available
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?
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.
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.
deleted by creator
yeah, my first reaction was, “hmmm, clever…”
doesn’t signal use empty notifications by default?
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.
