9 ms·

But the point the EFF makes is very important. If the code is not open source, we just cannot verify the security of the application. All applications must be c

But the point the EFF makes is very important. If the code is not open source, we just cannot verify the security of the application. All applications must be considered unsafe unless we can review the code. We can't review Whatsapp's source code, and therefore Whatsapp is to be considered unsafe. So yeah, Whatsapp has made a probably positive move, but it is still largely unsafe.

n13 11y ago
Just wondering what EFF has to say about other Apps like Telegram since code is open sourced [1]? [1] - https://telegram.org/apps#source-code https://telegram.org/apps#source-code
- akvadrako 11y ago
  Telegram wouldn't fair very well. It has weak home-grown encryption and doesn't enable it be default.
  - morsch 11y ago
    They've got two scores for Telegram on their score card[0]: "Telegram" scores poorly (4 out of 7), "Telegram (secret chats)" scores perfectly (7 out of 7). The quality of the encryption algorithm itself doesn't factor into it, though Telegram gets a check for having a recent audit. Even if the crypto was good, the cognitive load of having to decide whether you want a chat to be secret or not makes it a bad choice IMO, especially if it comes with a downside. [0] https://www.eff.org/secure-messaging-scorecard https://www.eff.org/secure-messaging-scorecard
    - tptacek 11y ago
      7/7 being a score that no practicing crypto engineer would be likely to come up with for that application.
kasey_junk 11y ago
I don't think that open source is considered a requirement by the professional security community. Which makes sense, we've known for a very long time that you can't trust the source, so you must verify the binary one way or the other.
- akvadrako 11y ago
  And one way to increase confidence in the binary is to compile it yourself.
  - kasey_junk 11y ago
    Twice, using 2 different compilers. That you have also audited. Or you could observe what the original binary actually does, which you need to do anyway.
    - tptacek 11y ago
      Exactly what I would expect to hear from an NSA stooge!
    - cptskippy 11y ago
      At which point you might as well just let someone else compile it and look at their binary.
    - dave2000 11y ago
      If you have the source then you can see what it does. If you only have the binary you have no idea what it does. You can observe what it does today, but what use is that if tomorrow it receives a short message from Facebook which tells it to email back the encrypted, compressed copy of your messages it's been quietly keeping for the last few hours/days/weeks? The argument "what about this or that open source project with bugs in it" is silly. It's an argument for more scrutiny of code, not blindly trusting in third party code where you have no idea if they can be trusted today, or in the future, or can be compelled to spy on you, or introduce weaknesses deliberately into their products. Open source mitigates against several of these risks.
simonh 11y ago
But if the code is open source, we _can_ verify it's security? Heartbleed and Shellshock, the two most significant vulnerabilities found in heavily used open source software, were found by vulnerability testing and not code inspection. So while being open source is a nice-to-have attribute for a piece of software, that's as far as it goes. Painting open source as being a magical wand that wishes away all our security troubles is completely out of order. Edit: I'll go further. It's become dismayingly apparent that very little systematic code review of open source software in order to secure it is actually taking place. It now seems quite possible that the most thorough investigations of software vulnerability, via code analysis or any other techniques, are carried out by those wishing to exploit them. They are well funded and highly motivated. Looked at in that light, the balance may well tip towards open source actually increasing the likelihood of software vulnerabilities being exploited maliciously. The open source community has a long way to go if it's going to clearly demonstrate that it's model is advantageous, and complacent pronouncements of it's assumed superiority like this aren't going to achieve that.
- pekk 11y ago
  Do you understand the concept of "necessary, but not sufficient"?
  - simonh 11y ago
    Yes I do, but that's not what the post I was responding to was saying. However I have not seen any arguments that convince me if its necessity. Furthermore were talking about third party services. What code they open sourcezsndcegat code they actually run on their servers are two different questions. Open source doesn't solve this problem whichever way you slice it.
- dspillett 11y ago
  If the source is open you can verify/test both ways, if it isn't then you only have the external testing option. The code being publicly available does not guarantee security but makes insecurity easier to find which on balance indirectly increases security.
- 11y ago
hiq 11y ago
See this thread for tptacek's views on the topic: https://news.ycombinator.com/item?id=11432047 https://news.ycombinator.com/item?id=11432047 In short, "sources do not guarantee anything, and it's better to inspect the binary directly".
danielrhodes 11y ago
> it is still largely unsafe It's not unsafe, you just don't know if it's safe or not. That doesn't make it unsafe. Even if the code were open source and there were some guarantee that WhatsApp was using that exact code during compilation, you still would not know if it's safe. Just like most other people, you are relying on people experienced with such things to confirm that they are doing things in a "safe" way. Thus for all practical matters, it really doesn't matter if it's open source or not. There is always going to be an unknown here, and open source does not reduce that much risk. In fact, it's probably better to look at how WhatsApp, the software, behaves (i.e. what it does on the wire) rather than the code. Sure there could be backdoors, but that is the risk you take when you use any pre-compiled software -- open source doesn't change that. All we are really left with then is trust.
- pookeh 11y ago
  And if you don't trust FB then it is ... unsafe :)
  - danielrhodes 11y ago
    Well if your point is that safe or unsafe are always subjective conclusions, then of course I agree with you. If the safe/unsafe determination is being declared as an objective conclusion, then I don't.
- lmm 11y ago
  > Even if the code were open source and there were some guarantee that WhatsApp was using that exact code during compilation, you still would not know if it's safe. Speak for yourself > Just like most other people, you are relying on people experienced with such things to confirm that they are doing things in a "safe" way. Thus for all practical matters, it really doesn't matter if it's open source or not. If you rely on the experts then it still matters to you whether being open-source means more or better experts. > In fact, it's probably better to look at how WhatsApp, the software, behaves (i.e. what it does on the wire) rather than the code. It is provably impossible to tell whether the RNG has been backdoored that way. > Sure there could be backdoors, but that is the risk you take when you use any pre-compiled software -- open source doesn't change that. Huh? So you require reproducible builds and/or build from source yourself. You absolutely don't trust that some random binary is what it claims to be.
yeukhon 11y ago
If that's the stand, EFF is basically with Stallman that there shouldn't be any proprietary software and that view is hard to agree on. > All applications must be considered unsafe unless we can review the code. Let's face it. I like to give the liberty to people who prefer to keep their code secret and their responsibility to hire people to do proper security auditing. Curious whitehats are welcome to attack systems which have bounty program. While obfuscation is never a good idea in security, the paywall between Facebook and the public keeps large exploits away. Attacks came directly from behavior testing require some cleverness and dedication (of course there are those really dumb XSS everywhere). So in this case, obfuscation by hiding the source code is one way. However, you can argue that someone could have lost work laptop and steal the source code (let just assume some startup whose git repo is clonable entirely onto the laptop).

n13 11y ago

Just wondering what EFF has to say about other Apps like Telegram since code is open sourced [1]? [1] - https://telegram.org/apps#source-code https://telegram.org/apps#source-code

akvadrako 11y ago
Telegram wouldn't fair very well. It has weak home-grown encryption and doesn't enable it be default.
- morsch 11y ago
  They've got two scores for Telegram on their score card[0]: "Telegram" scores poorly (4 out of 7), "Telegram (secret chats)" scores perfectly (7 out of 7). The quality of the encryption algorithm itself doesn't factor into it, though Telegram gets a check for having a recent audit. Even if the crypto was good, the cognitive load of having to decide whether you want a chat to be secret or not makes it a bad choice IMO, especially if it comes with a downside. [0] https://www.eff.org/secure-messaging-scorecard https://www.eff.org/secure-messaging-scorecard
  - tptacek 11y ago
    7/7 being a score that no practicing crypto engineer would be likely to come up with for that application.

kasey_junk 11y ago

I don't think that open source is considered a requirement by the professional security community. Which makes sense, we've known for a very long time that you can't trust the source, so you must verify the binary one way or the other.

akvadrako 11y ago
And one way to increase confidence in the binary is to compile it yourself.
- kasey_junk 11y ago
  Twice, using 2 different compilers. That you have also audited. Or you could observe what the original binary actually does, which you need to do anyway.
  - tptacek 11y ago
    Exactly what I would expect to hear from an NSA stooge!
  - cptskippy 11y ago
    At which point you might as well just let someone else compile it and look at their binary.
  - dave2000 11y ago
    If you have the source then you can see what it does. If you only have the binary you have no idea what it does. You can observe what it does today, but what use is that if tomorrow it receives a short message from Facebook which tells it to email back the encrypted, compressed copy of your messages it's been quietly keeping for the last few hours/days/weeks? The argument "what about this or that open source project with bugs in it" is silly. It's an argument for more scrutiny of code, not blindly trusting in third party code where you have no idea if they can be trusted today, or in the future, or can be compelled to spy on you, or introduce weaknesses deliberately into their products. Open source mitigates against several of these risks.

simonh 11y ago

But if the code is open source, we _can_ verify it's security? Heartbleed and Shellshock, the two most significant vulnerabilities found in heavily used open source software, were found by vulnerability testing and not code inspection. So while being open source is a nice-to-have attribute for a piece of software, that's as far as it goes. Painting open source as being a magical wand that wishes away all our security troubles is completely out of order. Edit: I'll go further. It's become dismayingly apparent that very little systematic code review of open source software in order to secure it is actually taking place. It now seems quite possible that the most thorough investigations of software vulnerability, via code analysis or any other techniques, are carried out by those wishing to exploit them. They are well funded and highly motivated. Looked at in that light, the balance may well tip towards open source actually increasing the likelihood of software vulnerabilities being exploited maliciously. The open source community has a long way to go if it's going to clearly demonstrate that it's model is advantageous, and complacent pronouncements of it's assumed superiority like this aren't going to achieve that.

pekk 11y ago
Do you understand the concept of "necessary, but not sufficient"?
- simonh 11y ago
  Yes I do, but that's not what the post I was responding to was saying. However I have not seen any arguments that convince me if its necessity. Furthermore were talking about third party services. What code they open sourcezsndcegat code they actually run on their servers are two different questions. Open source doesn't solve this problem whichever way you slice it.
dspillett 11y ago
If the source is open you can verify/test both ways, if it isn't then you only have the external testing option. The code being publicly available does not guarantee security but makes insecurity easier to find which on balance indirectly increases security.
11y ago

hiq 11y ago

See this thread for tptacek's views on the topic: https://news.ycombinator.com/item?id=11432047 https://news.ycombinator.com/item?id=11432047 In short, "sources do not guarantee anything, and it's better to inspect the binary directly".

danielrhodes 11y ago

> it is still largely unsafe It's not unsafe, you just don't know if it's safe or not. That doesn't make it unsafe. Even if the code were open source and there were some guarantee that WhatsApp was using that exact code during compilation, you still would not know if it's safe. Just like most other people, you are relying on people experienced with such things to confirm that they are doing things in a "safe" way. Thus for all practical matters, it really doesn't matter if it's open source or not. There is always going to be an unknown here, and open source does not reduce that much risk. In fact, it's probably better to look at how WhatsApp, the software, behaves (i.e. what it does on the wire) rather than the code. Sure there could be backdoors, but that is the risk you take when you use any pre-compiled software -- open source doesn't change that. All we are really left with then is trust.

pookeh 11y ago
And if you don't trust FB then it is ... unsafe :)
- danielrhodes 11y ago
  Well if your point is that safe or unsafe are always subjective conclusions, then of course I agree with you. If the safe/unsafe determination is being declared as an objective conclusion, then I don't.
lmm 11y ago
> Even if the code were open source and there were some guarantee that WhatsApp was using that exact code during compilation, you still would not know if it's safe. Speak for yourself > Just like most other people, you are relying on people experienced with such things to confirm that they are doing things in a "safe" way. Thus for all practical matters, it really doesn't matter if it's open source or not. If you rely on the experts then it still matters to you whether being open-source means more or better experts. > In fact, it's probably better to look at how WhatsApp, the software, behaves (i.e. what it does on the wire) rather than the code. It is provably impossible to tell whether the RNG has been backdoored that way. > Sure there could be backdoors, but that is the risk you take when you use any pre-compiled software -- open source doesn't change that. Huh? So you require reproducible builds and/or build from source yourself. You absolutely don't trust that some random binary is what it claims to be.

yeukhon 11y ago

If that's the stand, EFF is basically with Stallman that there shouldn't be any proprietary software and that view is hard to agree on. > All applications must be considered unsafe unless we can review the code. Let's face it. I like to give the liberty to people who prefer to keep their code secret and their responsibility to hire people to do proper security auditing. Curious whitehats are welcome to attack systems which have bounty program. While obfuscation is never a good idea in security, the paywall between Facebook and the public keeps large exploits away. Attacks came directly from behavior testing require some cleverness and dedication (of course there are those really dumb XSS everywhere). So in this case, obfuscation by hiding the source code is one way. However, you can argue that someone could have lost work laptop and steal the source code (let just assume some startup whose git repo is clonable entirely onto the laptop).