6 ms·

You're describing exactly the problem that key transparency helps to solve. With this rolled out, the WhatsApp app itself will be able to detect, by default wi

You're describing exactly the problem that key transparency helps to solve. With this rolled out, the WhatsApp app itself will be able to detect, by default without any manual verification, if FB attempts to MITM the connection. While this doesn't make it technically impossible for Facebook to modify the app and servers, it does make it organizationally almost impossible to do so secretly. Such a move would require the involvement of numerous individuals across multiple teams and would be noticeable to security researchers through changes to the app. This approach is taking off in a bunch of similar problem spaces (web PKI, code signing, etc), so very exciting to see it applied here. Randomly, and somewhat weirdly, Facebook actually offered one of the first Certificate Transparency monitoring tools, which made it possible to monitor all certificates issued for your domain using a very similar approach: https://www.facebook.com/notes/3497286220327506/ https://www.facebook.com/notes/3497286220327506/

rvnx 4y ago
Not really ? I don't see what prevents the app from pushing a decoded copy of the conversation ? Even a variant of Skype was caught doing such (we only know about it because they left the server which had the raw logs completely open). And still, Skype is very secure/encrypted/blablabla; which is true, but within the borders of local regulations. https://web.archive.org/web/20090210230204/http://www.informationweek.com/news/telecom/voip/showArticle.jhtml?articleID=210605439 https://web.archive.org/web/20090210230204/http://www.inform... The end comment/advice from the US part is even a bit funny: "travelers should assume that all communications are monitored."
- dheera 4y ago
  Exactly, without Zuck opening the protocol and sanctioning the use of open-source clients it is not meaningful.
  - rvnx 4y ago
    Somehow I think this is still possible. The engineers behind WhatsApp seem to be very talented, and they may be able to convince Zuck that an open client would increase trust in Meta's brands, and increase usage (which can then be used to promote other Meta's products). If they keep the server-side closed, it's totally fair I think.
    - palata 4y ago
      Or open source alternatives will pick up their work, and the WhatsApp engineers will probably be happy about it.
- russell_h 4y ago
  You're making my point: some Chinese Skype variant did this, back in 2009, and got caught. There's just no way, in real life, for Facebook to add what you're describing to one of the most prominent messaging apps in the world without somebody noticing. I'm not here to tell you that your WhatsApp messages are perfectly secure. If the CIA wants to read your messages they'll probably just hit you with the wrench instead of some FB exec. But I do think that transparency logs are deeply under-appreciated for their ability to make undetected mass-surveillance dramatically more challenging.
  - crote 4y ago
    The trick is to push a modified version only to the few clients you want to attack. Use it sparingly and you won't get caught.
    - rvnx 4y ago
      and most of all, do not forget the logfiles on an open server (it was their mistake, otherwise it would have been fine I think)
    - palata 4y ago
      Or just hack the phone of those few clients with another attack vector. Doesn't mean that security is entirely useless. It depends on the threat model.
  - buran77 4y ago
    > There's just no way, in real life, for Facebook to add what you're describing to one of the most prominent messaging apps in the world without somebody noticing Your point moved from "key transparency is the defense" to "someone will notice". But if your defense is the hope of "someone noticing" you're in for a big surprise. Sometimes things go unnoticed. Look no further than OpenSSL, open source, used by billions, deployed by companies worth as much as small countries, and yet nobody noticed Heartbleed for years. So I'll be very cynical that some development flag targeting a handful of people in an app like WhatsApp and then is removed will be so noticeable that it's a strong defense.
- btown 4y ago
  There are also tons of ways to exfiltrate data through known channels in ways that are difficult for security researchers to distinguish from otherwise secure app analytics code. A crash/exception logging system, say, might appear to researchers to anonymize data, but it would be very possible for code to be written that happens to raise a mundane exception when specific users or geofences see specific words on screen, in a way where that list of users/geofences/words could be controlled by non-technical teams. The log message itself doesn't even need to carry sensitive data; its existence alone, when the trigger conditions are known, can be used to carry out a highly targeted attack. Even open-source systems can be vulnerable to this: see e.g. https://github.com/signalapp/Signal-iOS/blob/eaed4da06347a3a1af45662a6424d6bc99bf1bf8/SignalServiceKit/src/Messages/OWSMessageDecrypter.swift#L424 https://github.com/signalapp/Signal-iOS/blob/eaed4da06347a3a... and consider the ways it might be possible for a small group of people at Signal to cause a specific set of messages to be seen as corrupt without raising any flags to the community auditing the code. Of course, lack of visibility into runtime errors can lead to vulnerabilities as well. I don't think the solution is for us as a community to advocate for removing all error analytics in distributed systems. But we can't ever forget that: all analytics surfaces are attack surfaces.

rvnx 4y ago

Not really ? I don't see what prevents the app from pushing a decoded copy of the conversation ? Even a variant of Skype was caught doing such (we only know about it because they left the server which had the raw logs completely open). And still, Skype is very secure/encrypted/blablabla; which is true, but within the borders of local regulations. https://web.archive.org/web/20090210230204/http://www.informationweek.com/news/telecom/voip/showArticle.jhtml?articleID=210605439 https://web.archive.org/web/20090210230204/http://www.inform... The end comment/advice from the US part is even a bit funny: "travelers should assume that all communications are monitored."

dheera 4y ago
Exactly, without Zuck opening the protocol and sanctioning the use of open-source clients it is not meaningful.
- rvnx 4y ago
  Somehow I think this is still possible. The engineers behind WhatsApp seem to be very talented, and they may be able to convince Zuck that an open client would increase trust in Meta's brands, and increase usage (which can then be used to promote other Meta's products). If they keep the server-side closed, it's totally fair I think.
  - palata 4y ago
    Or open source alternatives will pick up their work, and the WhatsApp engineers will probably be happy about it.
russell_h 4y ago
You're making my point: some Chinese Skype variant did this, back in 2009, and got caught. There's just no way, in real life, for Facebook to add what you're describing to one of the most prominent messaging apps in the world without somebody noticing. I'm not here to tell you that your WhatsApp messages are perfectly secure. If the CIA wants to read your messages they'll probably just hit you with the wrench instead of some FB exec. But I do think that transparency logs are deeply under-appreciated for their ability to make undetected mass-surveillance dramatically more challenging.
- crote 4y ago
  The trick is to push a modified version only to the few clients you want to attack. Use it sparingly and you won't get caught.
  - rvnx 4y ago
    and most of all, do not forget the logfiles on an open server (it was their mistake, otherwise it would have been fine I think)
  - palata 4y ago
    Or just hack the phone of those few clients with another attack vector. Doesn't mean that security is entirely useless. It depends on the threat model.
- buran77 4y ago
  > There's just no way, in real life, for Facebook to add what you're describing to one of the most prominent messaging apps in the world without somebody noticing Your point moved from "key transparency is the defense" to "someone will notice". But if your defense is the hope of "someone noticing" you're in for a big surprise. Sometimes things go unnoticed. Look no further than OpenSSL, open source, used by billions, deployed by companies worth as much as small countries, and yet nobody noticed Heartbleed for years. So I'll be very cynical that some development flag targeting a handful of people in an app like WhatsApp and then is removed will be so noticeable that it's a strong defense.
btown 4y ago
There are also tons of ways to exfiltrate data through known channels in ways that are difficult for security researchers to distinguish from otherwise secure app analytics code. A crash/exception logging system, say, might appear to researchers to anonymize data, but it would be very possible for code to be written that happens to raise a mundane exception when specific users or geofences see specific words on screen, in a way where that list of users/geofences/words could be controlled by non-technical teams. The log message itself doesn't even need to carry sensitive data; its existence alone, when the trigger conditions are known, can be used to carry out a highly targeted attack. Even open-source systems can be vulnerable to this: see e.g. https://github.com/signalapp/Signal-iOS/blob/eaed4da06347a3a1af45662a6424d6bc99bf1bf8/SignalServiceKit/src/Messages/OWSMessageDecrypter.swift#L424 https://github.com/signalapp/Signal-iOS/blob/eaed4da06347a3a... and consider the ways it might be possible for a small group of people at Signal to cause a specific set of messages to be seen as corrupt without raising any flags to the community auditing the code. Of course, lack of visibility into runtime errors can lead to vulnerabilities as well. I don't think the solution is for us as a community to advocate for removing all error analytics in distributed systems. But we can't ever forget that: all analytics surfaces are attack surfaces.