Comment by Klonoar
2 years ago
Unless I’m mistaken - and I might be or it may have changed - Signal notifications on iOS just tell the app “hey, something happened, call the service and check for updates”.
I.e, the push notification itself contains little to nothing in terms of data/metadata.
You can also of course decrypt a notification by shipping an extension to do so, and maybe Signal does - it’s been awhile since I poked around it. I’d just be surprised if the Signal team didn’t analyze the issue to death and find the gaps.
What you've said is correct, but it doesn't stop the attack vector described.
If the question to Apple or Google is "who received a notification from Signal at 17:15 UTC?" then even if the notification is “hey, something happened, call the service and check for updates”, you've got your answer.
To defeat it, one would have to regularly send cover traffic (i.e. push messages saying "nothing happened"), and accept that notification of messages may be delayed until that regular period.
i.e. the app sends its push token to its back end, together with a "use by" date. The server sends a push by that time, even if there is nothing to send. In the case of receiving such a "nothing happened" push, the app gets a new token, and informs the back end server.
The constraint there is how frequently Apple / Google will allow pushes, and how well the respective central server can scale to sending all of those dummy notifications.
The cost for the mobile being extra data use, and extra battery from the forced wake ups. So it may have to be a configurable option in the app.
So do Apple / Google allow at least one notification per hour?
I would have to imagine that a high enough level of traffic/users would obscure this sufficiently.
e.g: If the question to Apple or Google is "who received a notification from Signal at 17:15 UTC?", then that could very well be a million people.