Hacker News Reader

Comment by notaustinpowers | Hacker News Reader

What sort of metadata or information can be gathered from a push notification from an app like iMessage? I know a timestamp is there and most likely the sender's phone number.

But is there some sort of sensitive info that these governments are trying to glean? Or is it more so they can build info maps and communication maps on targets?

View on HN

Compromise a single phone in a target group, send a message to an anonymous chat, and you now know every other member of the group.

Apple needs to know your Apple ID to send you an APNS payload. Now your anonymous chat profile is tied to your real Apple ID. Busted.

This is not necessarily true. You’re assuming that all the info is in push notifications themselves.

E.g: if I get a push notification that is simply “you have a new event, poll the server”, and then I poll the server for (encrypted) batch updates, where exactly do you see the leak that ties an anonymous profile to an Apple ID? Given a large enough service, that same generic batch update endpoint would be getting hammered and I have to think it would effectively be camouflaged to a degree.

Granted, not every app is going to use this design - but if or when done properly I don’t see that much of an issue here.

(I am open to being wrong, mind you)

Very delayed reply here, but it's a timing attack, I think.

If the government has access to telco resources (I think it's safe to assume that they can and do), then they can line up the timing of a chat message with the push notifications it triggers.

If we are chatting and the government doesn't know who I am, it will only be a matter of time before the number and timing of the push notifications I receive line up in a unique way to the messages you sent me. That would work for every member of the group.

Apple could bundle up multiple push notifications to obfuscate it a bit, but it would hurt real-time communications and wouldn't be that strong of a mitigation anyway.

If you were able to do this, and you also had control of the person's ISP/cell network (not unusual for the threat model here), then one thing you could do is interfere with their communications, "shadowbanning" them from their friends/contacts. Say you used a particular app, like LINE, to speak to one particular friend who your "benefactors" didn't want you speaking with, they could drop connections between your device and that app's servers whenever they intercept a push notification from Google or Apple targeted to that app on your device. Effectively preventing the two parties ever communicating.

Depending on specifics, it seems it would be possible to do this cleverly, so the app still thinks it's connected, but just never receives these messages.

I'm not an expert on this, it just seems a plausible possibility. Best effort response to your question! :)

This would only work if the protocol doesn’t have the concept of retries, which it does. They’d have to block all communications which would be highly noticeable - especially since you’d get a flurry of messages any time you opened the app or migrated onto a Wi-Fi network.

I suppose it depends on which protocol, and which app, we're talking about, but...Interesting. Good analysis!

It's conceivable that connectivity checks flow to other servers than delivery traffic, and these are passed-through. Although addressing your more general critique of the "flurry" (good word! :)), requires noting that accomplishing this capability would involve compromising the app's servers. Such backdoors are again not outside the realm of possibility in the given threat model.

Do you see any possibilities for interference in the push interception capability described?

Chat message content?

I know iMessage is E2E encrypted, and I wonder if that extends to the content shown within a push notification. Maybe the push notification servers receive the content encrypted, pushes it to the device, and then decrypted on-device?

Reply on news.ycombinator.com