Comment by garblegarble
2 years ago
The timing would still give you away - with a privileged network position you can tell that a user sent a message to an messaging service, and that some set of users got notifications from that messaging service moments later. Observe that enough times and you'll have good confidence in the members of a group.
If you're trying to hide from that type of attack you need to send a fixed rate stream of messages (most of which are dummy messages, except the occasional message containing genuine content -- like number stations). Furthermore, every point in the chain also needs to avoid revealing which messages are genuine (by fetching the encrypted message from the server when it receives a genuine notification, you're giving data away).
The operator of the app could send messages at fixed intervals to make it more difficult to correlate the messages (more samples required to have confidence in the recipient). If they send dummy notifications they'd probably fall foul of Apple/Google's constraints around invisible-to-the-user notifications (I know Apple prohibits them, I assume Google does as well)
I can't see that frustrating this type of attack would be interesting to Apple/Google: it would push up power & radio bandwidth requirements for everybody pretty significantly.
In fact, at least on Android, the contents of most push notifications are not the actual messages to be displayed to the user, but just empty notifications letting the app know it must poll for something on the server or some other activity which may result in a notification.
It's all about the timing (and meta-data like which app), not about the contents.
Isn’t this somewhat defeated if the service is large enough?
E.g: if I get a signal notification and the notification has no data except “event happened, call server for updates” - and then you fetch updates as a batch - doesn’t the sheer number of people making that same generic batch update call somewhat mask it?
I’m curious where Apple prohibits dummy notifications, by the way - I used them for a financial app I worked on a few years back and never got dinged for it.
What you're talking about is achieving perfect privacy/security.
Even just E2EE on the notifications themselves would be an improvement over the current situation. It would make certain categories of data unavailable to eavesdroppers. The fact that it would not protect against 100% of all types of data/metadata exfiltration is not sufficient reason to oppose implementing it.
If notification is malformed or erroneous it should be invisible, shouldn't it?
I think (reading between the lines on their docs) that you'll get throttled/dropped if you abuse the system by sending a regular push notification but do not notify the user. Apple doesn't like app developers using invisible notifications because it risks wasting device battery without the users being aware that their device is constantly being awakened by your app.
However, I was actually wrong more generally because Apple does have push notification type for this, Background Updates[1] are permitted to run invisibly. They say not to try sending more than 2-3 per hour, and that "the system may throttle the delivery of background notifications if the total number becomes excessive" - which sounds like you're permitted some unspecified small number between app launches.
These notifications seem to only be able to send a single boolean flag, so it doesn't seem like an awfully viable way of implementing a fixed rate message system (especially because you'd also want to be sending messages out on that same fixed rate to frustrate analysis)
1: https://developer.apple.com/documentation/usernotifications/...
Technically you can make malformed messages visible: store them in spambox and display their metadata or maybe even as a source of randomness, like random.org