Hacker News Reader

Comment by angio | Hacker News Reader

They mention metadata in the article. Imagine sending a message to a Signal account at time X, then asking Apple a list of all users that received a Signal notification at that specific time.

View on HN

This ^. approach and modified forms of it can bu used to track lots of things, and have be done so for decades by some goverment agencies. You can use a method like this even if people are using encryption and lot of anonymous tunnels. You simply shape the traffic and watch where the shape of that traffic stops. Can track people realtime across almost any link, including things like Tor, etc.

I had to anonymize some data while still keeping some details. You could imagine individual trees that needed to be put into groups of similar trees so individual details were lost.

Anyway, these "trees" were effectively user behavior across all our products. I was shocked that simply knowing *when* (to within a second or two) a person did two or more things, you could narrow it down to *one single person* out of hundreds of millions.

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.

That doesn't make sense. I would expect Signal notifications to happen completely out-of-band with "normal" push notifications (e.g. NYT news alert). Otherwise that completely defeats the purpose of the service. Basically you're saying Apple/Google are MITM'ing Signal.

I'm not so familiar with Signal, but could you explain why you would expect Signal notifications to happen out-of-band with normal push notifications?

Assuming Signal sends push notifications of some sort, as most messaging services do, that would make them vulnerable to the metadata-level attacks described in this thread.

What kind of "out-of-band" are you thinking of that would mitigate this issue?

Not using APN I assume, but then you are not allowed(or rather won't pass the review) to publish the app in the App Store.

Why: because otherwise the service, which is supposed to be private, is no longer private.

I dunno how it would work, maybe something like a third-party push? Why does everything have to be channeled through central service? A service like Signal could operate its own push channel.

Notice how SimpleX (https://simplex.chat/) has no push notifications by default because of this issue.

Apple doesn't support any third-party push platforms, and they are restricted on Android to preserve battery life.

no, that's not basically it. MITM to me means being able to read the data by placing yourself in the encrypted chain. that's not how push notifications work. they don't need to know the contents of the message

The notification is separate from the message. It absolutely is MITM, just for the notifications, which are messages themselves with real content (you have received a message from so-and-so).

I don't know what you think you are proving here. They did not view the contents of the message. An MITM "attack" would allow them decrypt the content of the message. This is just metadata being used. It's no different than all of the other metadata uses that the TLAs have been using. We've known for a long time (for me since Snowden was the first time I ever even considered it) that metadata can tell us a whole hell of lot about people that is just as much evidence that the actual contents of the message are irrelevant. With metadata alone, you can build up an entire network of people to investigate. You can do that investigation without ever decrypting anything. It's no different from the police following a suspect to see who they meet, and then following that person, and continuing until they find the bigBoss. They can then roll up the entire network in one fail swoop if they so choose.

This is just how push notifications work on iOS and Android. The app requests a push token from the operating system, sends that to its backend and stores it against the user's identity. To send a push a message is sent from the backend to a push service maintained by Apple or Google, who then deliver the push to the phone in question. In the case of Signal, their backend cannot access the message content, so the notification does not contain this, i.e. it's not MITM.

On iOS in particular background modes are finicky and you cannot generally have an continuously poll notifications in the background. Further, if every app did this battery drain would be significant.

Reply on news.ycombinator.com