Apple forces you to use their notification service. At one point, they even tried to force desktop users of Safari to be bound to their notification service instead of being able to use web push notifications, as well.
Apps distributed on the Play Store also have to use Google's notification service.
True, but apps like signal get around that by having a pushing notification for "you have a new signal message", which then triggers the client to contact the signal servers to download the message.
And a lot of messaging programs send push notifications for highly dubious reasons, like when you read your own messages (so that the other devices mute their notifications). Element does this.
…so? That’s just not very useful when applied to a large scale service like Signal. You and god knows how many other people are getting a generic “check me” notification at a high rate.
Again, this doesn't necessarily apply in the case of a sufficiently used service like Signal:
- 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.
If you have metadata for a couple of messages it is no longer a needle. Not sure what your point about APNS tokens is - I agree, once they hone in on who received the messages Apple would know the device.
Look, if all you're after here is an "I hate Apple" pity party, you can do better: iMessage is default backed up to iCloud - without encryption - and offers an even easier workaround for the government. I would have to imagine they get more from that than notification payloads.
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.
If I sent a message to a group of friends, you don't need to know the contents if all you want to know is who my friends are. Just look for groups of people getting notifications at the same time. After a few messages, you'll know exactly who is in that group.
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.
Yeah, no. You're missing the point of this thread here.
> 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.
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?
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):
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.
>, it has to be stored somewhere, pending delivery.
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".
If every app need to poll different servers periodically or, listen for pushes, it will be a nightmare for battery life and be a big detriment to phone resource usage.
Sure, but shouldn't this be e2e encrypted? You could probably come up with a scheme such that Apple doesn't know the contents, sending app or recipient device.
This is up to app developers to implement themselves. The mechanism Apple provides for this is UNNotificationServiceExtension, which allows an app to step in before a notification is delivered so that it can do things like decrypt it.
Encryption should have been the default in the official framework/API to begin with. But I assume E2EE wasn't a concern for Apple/Google back then, and now it's to late to change everything without a lot of pain.
Apple previously didn't have any problems making breaking changes to their stuff, they even switched their whole CPU architecture and said "deal with it". If E2EE was really a concern to Apple, they'd implement it.
Push notifications just have the convenience of even technical people often not knowing that most of them are routed directly through Apple/Google. So how should your average user know? It's free data and nobody complains about it how they would with messengers eg
> Apple previously didn't have any problems making breaking changes to their stuff, they even switched their whole CPU architecture and said "deal with it"
What? Apple put a tonne of effort into continuity between arches. You think Rosetta is them saying “deal with it”?
> Apple put a tonne of effort into continuity between arches.
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.
It should. I am sure that Apple will be working on this now. It’s unfortunate that they didn’t implement it before. Maybe Apple itself didn’t realise that this data was being taken by the authorities, and the parts of Apple that did know were not allowed to inform engineering.
Push is a just technique for minimizing (scarce wireless) bandwidth, battery and RAM consumption, which was critical in the mass deployment of the initial iPhone on AT&T.
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
