Apps distributed on the Play Store also have to use Google's notification service.
elsewhere if you use firefox their webnotification push servers use a e2ee schema.
also on Android apps have the option to not use google's server and pull (e.g. ntfy)
... aren't you glad you bought an iphone thanks to all that "we respect your privacy" marketing? /s
It’s not rocket science to obscure push notification data. Your beef should be with the app devs who don’t go the extra mile, not Apple.
I did some anonymization across hundreds of millions of users for some GDPR stuff a few years ago. If I knew when you made a purchase, to within a day, for two separate one-off purchases of our products ... I could deanonymize you. Specifically just you. If you had a subscription payment, and I knew at least one payment you were late on, and the hour you eventually paid it ... I could deanonymize you down to a group of 3-4 people.
Correlation and timing are huge for deanonymizing things in otherwise anonymous data. We had to round our dates to the week to keep some of our analytical data anonymous.
> Just look for groups of people getting notifications at the same time.
In a sufficiently built system - like what Signal does, and like what most apps should be learning from - all the notification payload is getting is a "check for updates" command. You and literally everyone else are getting that generic notification all the time if you're in more than one chat. Just because Alice sent a message at 12:01PM and Bob received the generic "check me" notification at 12:02PM doesn't mean Bob necessarily received Alice's message specifically, because the notification has absolutely no concept of the messages period. Bob could have gotten that notification due to any of the other chats he's in.
At best the argument here is that the government could use the push notification token to link a Signal account to a real username via Apple, but if you're that paranoid you shouldn't use an iOS device anyway. You also likely wouldn't use Signal due to the phone number issue.
It's pretty simple: don't use iMessage if you value secure communication, since we know Apple gets hamstrung by the government at points. Devs building for the platform should be taken to task here because they need to be aware of and optimize around the data leaking issue, relying on the parent platform to always be a good steward is a recipe for disaster.
- Alice sends message to Bob at 12:01PM - Bob receives generic "check me" notification at 12:02PM
The key point with line #2 is that Bob is not the only user at 12:02PM who received that generic notification, and is likely in more chat than one. Pinning the specific notification to Bob is a needle in a haystack. It's not perfect, but it's not the slam dunk people are making it out to be.
And before that's even a concept, you have to contend with the fact that it's very hard to use an Apple device anonymously. The government doesn't need to correlate message timings, because if they have the APNS token for the device, all they have to do is ask Apple who the hell owns the device.
Anonymity and privacy are two different, albeit related, concepts.
The "send" part I understand. What I don't understand is the "store" part.
And is the Apple's routing even needed? Web push notification don't need Apple, Google, Microsoft or Ubuntu between the web app and you. Can't app push notifications work in the same way?
They do. To implement "web push", each web browser vendor has their own backend server to handle notification subscriptions[1][2].
- Mozilla Firefox uses their server at "push.services.mozilla.com"
- Google Chrome uses their server "fcm.googleapis.com"
- Apple Safari uses "api.push.apple.com"
- MS Edge uses their Windows Notification API server
[1] https://stackoverflow.com/questions/53169001/web-push-do-the...
[2] https://stackoverflow.com/questions/48683770/how-are-web-pus...
[3] https://news.ycombinator.com/item?id=38430226
The web push architecture requiring middleman servers in between the website and the browser is similar to native iOS apps requiring the APNS server (Apple Push Notification Server):
[4] https://stackoverflow.com/questions/17262511/how-do-ios-push...
If the device is not able to receive the notification at the time it was sent out, it has to be stored somewhere, pending delivery. It's the same with email, SMS, literally every messenger app, heck it's the same with physical parcels!
You could argue the protocol should allow the sender to store the message, to allow the receiver to fetch it directly, without a middleman - and this is more or less what RSS is, except the polling architecture causes both extra latency and increased server load. But we could "fix" RSS by eliminating polling, etc - that's an easy engineering problem, the true issue would be standards/consensus.
Finally, since we're talking mobile devices, you must consider battery usage. It's cheaper to keep only a single TCP connection open; this path is heavily optimized at every layer of the stack, from network hardware and drivers to the app-facing API. Notably, email notifications have to go through their own network path (there's a couple of IMAP extensions to enable push), this is part of the reason why some email apps would like to look at your email from the POV of their own hosted backend.
These choices reflect the fundamental problems of mobile messaging. But we could still improve upon the status quo - like requiring E2EE for notification payload. That would be a huge effort though, as an app vendor you already need to implement APNS/FCM/Web (all very different from one another), and I'm sure every middleman would like to build their encryption slightly differently. Adoption would be slow and painful.
I think the "stored?" question isn't about the minimal fraction of time notifications have to be in transient storage to even "send and immediately forget". Yes, a transitory "message queue pub/sub" architecture still needs to have some notion of "storage" to work.
Instead, "stored?" is wondering about a company's discretionary and optional retention period after the successful notification delivery that isn't required by law. E.g. 30 days?, or 1 year?, or longer? ... such that those archive records of past notifications have become targets for court subpoenas and law enforcement information requests. If Apple doesn't "store" notifications in this sense, there's nothing to "hand over".
https://developer.apple.com/documentation/usernotifications/...
What? Apple put a tonne of effort into continuity between arches. You think Rosetta is them saying “deal with it”?
Still can't run windows on an M* mac, can you? Why? Because there is literally no documentation for the CPU and they didn't really follow any standards. They just built some shit that literally only Marcan probably knows how it actually works. Even the people who made it probably don't know how it works, only how it is supposed to work.
iPhone developers typically aren’t very skilled and they will stuff things into APNS payloads without thinking through the consequences (they’re just happy to get something working at all and more often than not, are in some remote country that doesn’t allow familiarizing with the user context) so this is definitely a privacy concern whether due to legal interception or hacking.
Perhaps a future version of SwiftUI (and what Xcode Cloud may evolve into) will implement a simple E2E Push scheme by default, allowing Apple to spend more time reviewing the Push API use by the remaining legacy apps.
But…take comfort in knowing that at least Apple’s server is not purposely located across national boundaries (like Blackberry). That’s good because users have no expectation of privacy from monitoring (by US government or otherwise) when using servers (or when they themselves are) on foreign soil.
Meanwhile, US let 12,000 unknown persons literally wander across the border in just a single day last week (US can only handle 1,000 border crossers on a good day) and some are committing horrible crimes (https://foxsanantonio.com/amp/newsletter-daily/undocumented-...) —and yes, they do have Android and iPhones. The US is also sinking another $1T in (unfunded) debt every 90 days (meaning another Great Depression is not out of the question) and maybe it’s time to better focus our resources, for example, (after 40 years) China seems just about done surveying western IP and is clearly moving into a new era by having their massive APT groups (collectively 50x larger than US cyber forces) operate crude things like MoonBounce deployments —we have almost no monitoring for factory-installed threats, we’re totally wide open. https://youtu.be/j7OHG7tHrNM