Thank you @hpk for your reply.
Even when encryption is implemented, this depends on how the encryption is implemented. If the encryption of the device token produces the same ciphertext for each account, then its obvious those accounts are of the same user, even if the original device token can’t be known, but if each account uses it’s own unique nonce for encrypting the device token or otherwise guarantees unique ciphertext, then this is not a risk. The fact alone that the device token will be encrypted, as stated in the FAQ, isn’t enough to be reassuring, because it all depends on if each account uses it’s own nonce or not.
And since there is currently no encryption for the device tokens, this should be an opt-in experimental feature IMO, but I also understand DC team is eager to release the feature and I accept that opinions can be different about this.
While logging happens only in RAM, this won’t matter if police seize the DC proxy, because they will then have the decryption key and can decrypt whenever they want all the push tokens they obtain from a chatmail server. I appreciate the measures which DC has taken, like logging only to RAM and (in future) encrypting the device tokens, but these measures do not address all possible threat scenarios.
No, I don’t mean that the user has a chatmail account and a gmail account configured in Delta Chat. I acknowledge the facts you give, that Google by itself does not know the chatmail account, and the DC proxy by itself does not know the gmail account. The problem is when you combine these views, which police can do by seizing or subpoenaing the chatmail server, the DC proxy, and the Google FCM server.
According to Wired:
To identify a person of interest and whom they may have been communicating with, law enforcement must first go to an app developer to obtain the relevant push token and then bring it to the operating system maker—Apple or Google—and request information on which account the token is associated with.
We also know that police are often over-zealous about seizing servers and act in illegal ways, so I don’t think these concerns can be dismissed as theoretical.
You could be right about this in general, and I am not expert in all the ways Google knows what’s going on in a device. My understanding is that a device using FCM with Micro G is not “tied to Google cloud” in a way that lets Google see everything going on in a device, but I could be wrong about this.
The threat comes not only from Google, but also from the police, who can potentially combine the view from Google and the view from the chatmail server and DC proxy through raids and subpoenas.
As to traffic analysis, i don’t think it’s as obvious as you make it sound that you could reliably find out who chats with whom. Traffic analysis on human chatting activity is harder than someone visiting a website via TOR, which causes a lot of instant machine-generated bidirectional traffic.
I don’t want to make traffic analysis sound easy, I don’t think it is easy, but I also don’t want to underestimate the sophistication of well resourced attackers and the availability of commercialy available tools for attackers ready to buy, especially in the age of surveilance capitalism.
A single message probably isn’t enough for traffic analysis to work, but the risk is when many messages are exchanged over a long period of time, which provides enough data points for the correlation attack, so its a bit different to visiting a website, although read receipts also cause instant machine-generated bidirectional traffic and lower the number of messages needed for a successful attack. It probably isn’t 100% reliable, but it doesn’t need to be 100% accurate to be a risk and it doesn’t stop attackers from employing this technique anyway.
Amnesty International’s Security Lab has a report on this:
As internet traffic was increasingly encrypted, companies such as Nexa group started to offer new product lines such as JASMINE, which focused on analysing the metadata of encrypted traffic apps with a particular focus on messaging applications …
The JASMINE documentation also explains that by analysing encrypted traffic “events” for a whole country – in mass interception mode – JASMINE has the ability to correlate and identify the participants in encrypted group chats on messaging apps, with specific support analysing WhatsApp chat conversations.
Such a metadata analysis system can record the distinctive network traffic pattern each time a phone receives a new encrypted message or notification from a chat application such as WhatsApp or Telegram. Over time, with dozens or hundreds of messages received, the correlation between these notification events for multiple individuals will get stronger.
Eventually these systems can, with a high degree of confidence, determine which phones in the country are consistently receiving a notification at the same time, therefore indicating the phones and individuals which are likely members of the same encrypted messenger chat group. Recent reporting from the New York Times revealed how states, for example Russia, are developing and deploying similar internet traffic analysis systems to track the users of encrypted messaging applications in the country.
This is not an abstract risk; other commercial surveillance vendors such as Sandvine have reportedly developed and advertised similar surveillance capabilities to government customers such as Algeria and Belarus.
An internal threat assessment by WhatsApp’s security team has also highlighted this danger and refers to “ongoing exploitation of traffic analysis vulnerabilities that make it possible for nation states to determine who is talking to who”.
Obviously its not just DC which is effected. WhatsApp, Signal, and Telegram all are vulnerable. Until now DC and other common messaging apps don’t consider traffic analysis part of they’re threat model, but I think its something we need to talk about more, because it doesn’t seem reasonable to exclude it from the threat model.
Amnesty International’s Security Lab recommends:
To defend against traffic correlation attacks, messaging apps and push notification services should consider traffic correlation attacks as practical real-world attacks which are deployed against their users and include this in their threat models.
I know there is no quick and easy solution, and its a very complex problem, but sooner we acknowledge and discuss the problem, sooner we can work toward addresing it and maybe creating long term solution.
A comprehensive solution would probably involve multiple mitigation techniques and take a lot of time to implement and maybe also make some things less convenient for users, but there are also some things which would be easier and quicker to implement with minimal inconvenience for users, for example introducing random delays for read receipts. With discussion about the topic we can get different viewpoints and find the right balance to address the needs of privacy, convenience and developer resources.
Well resourced attackers can carry out traffic analysis attacks even without FCM, but for the reasons I gave above, I think FCM lowers the bar for these sorts of attacks. And my second example shows FCM can help police deanonymize accounts even without any traffic analysis.
I do appreciate the thought put into the existing privacy design and I do think its better then many other messaging apps, but I also think DC plays down the risk when it implies that instant delivery with FCM does not create any additional risks, and I also think that more discussion of topics like traffic analysis (with and without FCM) is needed, even if its a difficult topic.