| ▲ | dlcarrier 5 hours ago |
| This was a bug that left it cached on the device. Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring. If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from. |
|
| ▲ | gruez 5 hours ago | parent | next [-] |
| > Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring. >If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from. This incorrect on two counts: 1. As per what you wrote immediately before the quoted text, the issue was that the OS keeps track of notifications locally. Google/Apple's notification servers have nothing to do with this 2. It's entirely possible to still have end-to-end messaging even if you're forced to send notifications through Google/Apple's servers, by encrypting data in the notification, or not including message data at all. Indeed that's what signal does. Apple or Google's never sees your message in cleartext. |
| |
| ▲ | saagarjha 4 hours ago | parent | next [-] | | If Signal wants to show you a notification with message text, it needs to put it on the screen through an OS service. That service was storing the plaintext on the device. | | |
| ▲ | avianlyric 3 hours ago | parent | next [-] | | Through an OS service yes, but not a hosted backend service. Obviously that service has store the notification in plaintext (although everything on an iPhone is encrypted at rest, but notification crypto keys have to stay in active memory for the lock screen to work), otherwise it wouldn’t be able to display the notification text. Apple support applications sending encrypted notifications, where the OS launches the app the decrypt the notification body locally and pass it back to the OS for display. | |
| ▲ | wpm an hour ago | parent | prev | next [-] | | This is correct, but my understanding of it is that the push notification (which is not the same thing as the actual "Notification" that is shown on the screen) basically contains a "hey $DEVICE, go talk to $APP_NOTO server they got something for you". APNS just taps on the device's metaphorical shoulder and hands them a courtesy phone "call for you sir" | |
| ▲ | Vinnl 3 hours ago | parent | prev | next [-] | | Yes, but that service is running locally. | |
| ▲ | dmitrygr an hour ago | parent | prev [-] | | > it needs to put it on the screen through an OS service. That service was storing the plaintext on the device. Technically, so can the OS's text drawing primitive while drawing Signal's UI. |
| |
| ▲ | mdavidn 5 hours ago | parent | prev | next [-] | | You are correct, but you omitted one complication: Clients trust Google's and Apple's servers to faithfully exchange the participants' public keys. | | |
| ▲ | pcl 5 hours ago | parent | next [-] | | Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption. | | |
| ▲ | toast0 4 hours ago | parent [-] | | Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext. | | |
| ▲ | saagarjha 4 hours ago | parent [-] | | This is how it used to work; notifications can be encrypted now and Signal uses an extension to decrypt them. |
|
| |
| ▲ | xmx98 5 hours ago | parent | prev | next [-] | | Sending public keys through the notification system is an unnecessary complication. | |
| ▲ | soamv 5 hours ago | parent | prev | next [-] | | Which clients? | |
| ▲ | ls612 5 hours ago | parent | prev | next [-] | | Isn’t that what Contact Key Verification solves? Or do I misunderstand how that works? | |
| ▲ | qurren 5 hours ago | parent | prev [-] | | ... and hold participants' private keys truly private, which you cannot verify without a rooted phone. |
| |
| ▲ | totetsu an hour ago | parent | prev [-] | | What about when my notifications are showing up on my MacBook next to the phone via mirroring? | | |
| ▲ | ChadNauseam 23 minutes ago | parent [-] | | talking totally out of my ass, but apple seems to have robust infrastructure for e2ee communication between your devices, for example it is known that location information in find my is not visible to apple. I’d be surprised if the channel to send iphone notifications to your mac wasn’t also e2ee | | |
| ▲ | zadikian a minute ago | parent [-] | | Unless something has changed since I last did this, the app's server initiating the apns doesn't encrypt using some public key for the destination. So no e2ee. |
|
|
|
|
| ▲ | ya3r 5 minutes ago | parent | prev | next [-] |
| Telegram secure chat messages do this by default. |
|
| ▲ | asteroidburger 5 hours ago | parent | prev | next [-] |
| Both Apple and Google offer the ability for your app to intercept and modify messages before being displayed. Use that to send encrypted messages and decrypt them there, using your own code on the user’s device. |
| |
| ▲ | Zak 4 hours ago | parent | next [-] | | That framing Makes it sound like the app developer has to do something active to keep message cleartext out of notifications. That's not how it is on Android. A Firebase Cloud Messaging push notification contains what the app developer's server puts in it. That could include the message body or it could just be an instruction to the app to poll the server for new messages. It has nothing to do with the notification that's displayd on an Android device. Those are entirely local. An app that cares about privacy wouldn't send anything more than a poll instruction over FCM. | | |
| ▲ | avianlyric 3 hours ago | parent | next [-] | | You can implement either approach on iOS as well. But if you have strong end-to-end encryption for messages, then you don’t have to care about the transport anymore, you assume they’re all compromised. At that point you might as well use the push notification system as your transport, given both OSs allow applications to intercept the push notification locally and decrypt it before it’s displayed to the user. | |
| ▲ | saagarjha 4 hours ago | parent | prev [-] | | This has performance/reliability tradeoffs. |
| |
| ▲ | ls612 5 hours ago | parent | prev [-] | | In fact this is what both iMessage and Signal (and maybe Whatsapp too but I can’t tell from a quick google) do. |
|
|
| ▲ | 1r0nym4n 3 hours ago | parent | prev | next [-] |
| Right, it would be too hard to just have a server send a notification and to jumble that notification locally with the read of the unlocked message without it going through Apple/Google servers. |
|
| ▲ | unethical_ban 3 hours ago | parent | prev | next [-] |
| Incorrect. At least according to the Matrix (chat) app FAQs I have read recently. With Matrix apps, certain metadata is pushed from the chat server, to a push server, through Google and then to my device. But the message is not part of that data - it's E2EE. What happens is the app wakes up from the metadata notification, and then fetches the message and displays it in the notification field. Your last point is correct, at least until/unless this is remedied in Android, too. |
|
| ▲ | xmx98 5 hours ago | parent | prev | next [-] |
| You are right in that it is Google’s and Apple’s OS notification api, and we do give them the plaintext messages. |
|
| ▲ | asdfman123 5 hours ago | parent | prev [-] |
| Seems like you should use an app like Signal for anything sensitive at all so you don't have to worry about megacorp ecosystems as much. |
| |
| ▲ | jdwithit 5 hours ago | parent | next [-] | | As mingus88 said, this story is literally in response to Apple leaking messages sent through Signal. Doesn't matter if the message is securely transmitted if the operating system then keeps it lying around in plain text in a cache. From the linked article: > The independent news outlet reported that the FBI had been able to extract deleted Signal messages from someone’s iPhone using forensic tools, due to the fact that the content of the messages had been displayed in a notification and then stored inside a phone’s database — even after the messages were deleted inside Signal. | | |
| ▲ | stavros 5 hours ago | parent [-] | | You can easily configure Signal not to show the message contents if you want, though. | | |
| ▲ | jim33442 5 hours ago | parent | next [-] | | The original comment mentions this but gives the wrong reasoning. The APNs are encrypted either way, but this setting prevents Signal from decrypting them client-side and letting the notification cache store it. Yeah this is more secure because it means not trusting Apple to do their job right with local storage, but it's also kind of a reasonable thing to trust. | |
| ▲ | QuantumNomad_ 2 hours ago | parent | prev [-] | | Except even when you turn off message previews, it has to be specifically from within Signal settings. Not the iOS settings for notifications for the Signal app. To the user it looks the same, so it’s easy to make the mistake of turning off the previews in iOS settings instead of from within Signal settings. I didn’t even know there was a difference between the two until the recent posts about it. |
|
| |
| ▲ | mingus88 5 hours ago | parent | prev | next [-] | | Nope, Signal messages were stored in the phones notification DB even after the app was deleted https://www.404media.co/fbi-extracts-suspects-deleted-signal... | | | |
| ▲ | ryanisnan 5 hours ago | parent | prev | next [-] | | This is also an oversimplification. If I understand the issue correctly, the notification with the message contents was what was cashed locally and then accessed. This same vulnerability would exist with Signal if you had the notifications configured to display the full message contents. In this case, it has nothing to do with either Apple or Signal. | | | |
| ▲ | 4 hours ago | parent | prev [-] | | [deleted] |
|
