What is mindblowing is the mental gymnastics big tech does on this one.
"Oh we are sorry but gov didn't allow us to share this blabla"
Just don't collect push notifications and delete them from your servers after delivered and regularly rotate those push-ids and you have little to nothing to share with leo.
This again shows that they just don't care
Governments obtaining push notification metadata from Apple/Google
- Edited
FlyingRacoon The data does have to be kept while it's in the process of being delivered but can be deleted afterwards. They could demand future data rather than only past data so it can be obtained going forward. End-to-end encryption can resolve this for the content sent through it and there's no reason automatic, seamless end-to-end encryption cannot be implemented inside of newer client and server libraries for FCM. In fact, a third party could write a wrapper around the FCM libraries implementing near fully automatic E2EE. The client just needs to provide a public key to the server alongside the FCM registration ID, and then regularly rotate it.
- Edited
Upstate1618 Apps choose which of the data they have available local should be sent to their own services or other services. They choose how they protect that data. As an example, Signal doesn't send any data through FCM but rather only uses it to wake itself. Any other E2EE messaging apps do the same thing or send the data through FCM end-to-end encrypted. They don't have the non-E2EE data so they cannot send it through FCM. They can E2EE the whole FCM message to avoid giving more metadata to it than the time, destination and size of the message. The only reason to send data through it is avoiding a connection to their own server to display the notifications after waking to handle notifications being ready. Any app can use it to trigger a connection to their own server like Signal with empty content if they choose.
FCM exists to push data from the app's servers to their app on your device. Their servers must have the data to send it to it to you in the first place. The data being on their server makes it available to be obtained via lawful requests as is happening with FCM here. They can serve the warrants to the app's servers too, not only Google for FCM. It's easier for them to not need to deal with smaller companies but they can certainly do it for any large messaging app. This is something solved by E2EE, not avoiding a specific service because it complies with warrants requesting data.
Requesting data via warrants doesn't apply specifically to FCM. Google is requiring a warrant, so they're requiring more than Apple and it wouldn't be legal for them to outright refuse all the requests. If what you've taken away from the story is that you should avoid FCM, then you've largely missed the point. This applies to all data stored on servers under the jurisdiction of a country. It applies to all Apple and Google services, and all alternatives to those services. An alternate push messaging system can have the same requests made of them. If they use end-to-end encryption or don't support messages with content, then they can avoid content being obtained but they still have tons of metadata passing through. They could avoid recording metadata, but they are capable of recording it if a court requires that they do it.
GrapheneOS I find your explanation extremely helpful, thank you! One question: do you know if the push notifications for Proton Mail and Tuta Mail are E2EE?
- Edited
xYz do you know if the push notifications for Proton Mail
This was brought up in Proton's AMA 5 days ago to which their CTO, Bart Butler answered:
we anticipated this years ago, which is why we end-to-end encrypt all push notifications between our servers and users' devices. That said, we will continue to use Apple and Google push notifications when the services are available on the device because unfortunately they are favored heavily by the operating system in terms of performance and battery life. We are also developing an alternative push notification framework to support web, desktop, and de-Googled devices.
As for Tuta Mail....
and Tuta Mail are E2EE?
They published this on their blog back in 2020 and updated it 5 days ago too.
Tuta was already aware of this potential risk years ago and in 2017 we entirely replaced Google's notification services with our own push notification service. If you are using Tuta on Android, no push notification data is shared with Google. Your privacy is safe with us.
archvile77
This is the most sensible path, I think.
This is a concern only with Play Services right ? Asking caz microg also tries to connect to their servers via Cloud Messaging (unless not enabled).
- Edited
cro78 Many users think microg is safer alternative to Official Play Services. But I'm sure I've read somewhere that it's no different when you still login into your Google account with it, utilise their GCM as well as proprietary droidguard for SafetyNet/PlayIntegrity. You're just minimizing the data footprint, but not entirely. Caz you're still contacting the servers.
As it is open source, if can someone (who read the code) explain how GCM in microg works? Or is it just a blackbox with a toggle ?
foxjaw It's the same thing with microG but you should read the info in our responses above.
foxjaw The FCM library used by the app and the server are the same closed source code with microG. microG itself has major privacy and security issues and you're still using a Google service with the same proprietary libraries and server. It's a misconception that apps cannot simply use Google services themselves directly and many of the libraries do that.
- Edited
I think the best way to avoid this push notification theft is just by avoiding apps and services without GSF requirement in the first place.
Doesn't mean other 3rd parties can't steal. It's just a precaution against 1st party. Google can be avoided through de-googling. But for those who are on team apple, you're mostly out of luck.
Bruce Schneier recently posted about how push notifications can be used by the FBI to track a target's location: https://www.schneier.com/blog/archives/2024/03/surveillance-through-push-notifications.html