not exactly. on ios it's 100% their servers with wide open data.

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 “wide open data” if app developers choose to build that way.

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.

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 birthday paradox won't save you here, there is too much noise.

oh, right. let me talk to the devs of imessage, which is one of the notifications hinted at the origin of this discussion last week

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 you are forced to use a third party for push notifications, there should be end-to-end encryption by default. Really strange they don't do this.

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.

"Apps like Signal" is an exaggeration. Practically all programs do that. This has always been about metadata.

If the entire push is "you have a new message", then the only metadata in the push is the timestamp, who it's pushed to, and what app it's for, right?

Like a poster in a previous thread say, the "only" in "only metadata" is outright malicious. It's more than enough.

More than enough for what? To find out what someone is saying on Signal? I don't think so.

It’s not a full workaround. You can still see that a message arrived and when.

…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.

I can imagine it could be useful, e.g. if you already have metadata on “dates when user A messaged user B”, and are trying to de-anonymize user B.

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.

Correlations in the timings of notifications can unlock members of group chats by IP or even Apple ID.

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.