Comment by matthewdgreen
2 years ago
Some issues could be prevented if push messages added end-to-end encryption by default, something that shouldn’t be particularly hard to use if it was built into the dev tooling. Instead, developer recommendations like this one [0] suggest that you should put content into your push messages and optionally use a separate library to encrypt them. Clearly developers aren’t doing this, hence the opportunity for surveillance.
[0] https://android-developers.googleblog.com/2018/09/notifying-...
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/...
1 reply →
If it’s metadata they’re after (according to the article) would it really matter if the push notifications themselves were encrypted? As long as you’re using Apple/Google’s servers to manage push notifications it seems like there would be some metadata that could be useful for surveillance purposes, encrypted or not.
Getting rid of all metadata is fundamentally hard, unless providers are willing to deploy PIR or anonymity networks. But I think it's a mistake to assume metadata means "just the timing of a message": these push messages may include a lot of detailed content that is being described in this article as metadata, and all of that stuff can and should be encrypted.
Additionally, with a little bit of work (well, really quite a lot) the push messages can be made to hide the source. This would make it harder to distinguish a Gmail or DoorDash notification from a WhatsApp notification.
Some apps actually do that. I know at least Rocket.Chat has an option to handle push that way. I'd like to believe other similar chat apps used by groups and communities have it too.
But as others have pointed out, just having the timestamp and target of the notifications already tells a lot.
Encryption wouldn’t help as the whole point would be to look for coincident timings. I.e. after activity from one user to a known service you see a push occur going to another user. If this pattern repeats you can build confidence they are in contact.
It would very much help if you wanted to stop the government hoovering up the content of chat messages sent as push notifications
Encrypted messengers aren’t sending unencrypted push payloads, at least not deliberately.
A lot of apps don’t even put much in the push messages themselves at all, they are mainly an indicator to phone home for more information.
Consequently no gov has been getting meaningful info from the content of this stuff for many years - it will all be what you can infer from observed patterns, which is a lot.
1 reply →
Differential privacy, meet notifications: just add random notifications as noise to everyone. If payload decrypts to junk, then drop/ignore as a faux-notification; else, trigger notification.
Eh, what’s a few orders of magnitude increase in notification infrastructure overhead anyway? /s
I don't see why. The system operator knows to whom the message is being sent. They get a court order, ordering them to track messages sent to enumerated entities and they have to comply.