3 ms·

How can we trust SpiderOak when their client is not open sourced?

by mikevm 12y ago

makmanalp 12y ago
I think the more important question is if their client is open sourced, how can we trust that the binaries are made with exactly those sources? There should be a measure of testing it without the sources too, maybe sniffing packets to check for the encrypted content is a start.
- mkal_tsr 12y ago
  https://github.com/SpiderOak https://github.com/SpiderOak || https://github.com/SpiderOak/nimbus.io https://github.com/SpiderOak/nimbus.io
- Kryptor 12y ago
  Checking for encrypted packets wouldn't tell you anything about the binaries' trustworthiness. A back door might just encrypt the data with a second key, or more specifically, encrypt the key that encrypts the data with another key. A reliable way of testing binaries doesn't seem very feasible to me. It's like antivirus vendors trying to find new viruses: the malware authors can always obfuscate their code just a little more, do it just a little bit differently, and now it does the same thing while escaping detection. Authors of open source software who want to distribute trustable binaries should include instructions for how to reproduce the binary exactly from the source. A third party verifier could reproduce the binary, then publish a digital signature affirming that they reproduced it, allowing anyone who doesn't want to compile it to check with a trusted third party. But all of that is a moot point if the source code isn't being very carefully checked.
- rakoo 12y ago
  The whole point of being open sourced is that you can compile them yourselves after your verification and use the product of your own compilation with the server-side of spideroak. More realistically, your distribution maintainers will verify and compile the package, and you trust your distribution maintainers more than spideroak so you delegate source verification to them.
  - makmanalp 12y ago
    > The whole point of being open sourced is that you can compile them yourselves after your verification and use the product of your own compilation with the server-side of spideroak. So this is a good point, however: > More realistically, your distribution maintainers will verify and compile the package, and you trust your distribution maintainers more than spideroak so you delegate source verification to them. This is actually pretty compelling, but ignores Windows and OSX devices, which not only are the vast majority of all users, but also the least likely to compile their own. They will trust the provided binaries instead. This is one of those "Why Johnny Can't Encrypt" (http://www.gaudior.net/alma/johnny.pdf http://www.gaudior.net/alma/johnny.pdf) situations. I'm not solely criticizing spideroak here, I think this is a more general open problem with any 3rd party service that's meant to be trusted. It's an oxymoron that's been only somewhat breached because of public key cryptography.
    - marcosdumay 12y ago
      Windows and OSX devices are already trusting a huge lot of binaries compiled by companies that we already know that have been compromissed. Or, in other words, nobody that cares about privacy are using those anyway (at least while they care about privacy), by definition.

How can we trust SpiderOak when their client is not open sourced?

by mikevm 12y ago

How can we trust SpiderOak when their client is not open sourced?

I think the more important question is if their client is open sourced, how can we trust that the binaries are made with exactly those sources? There should be a measure of testing it without the sources too, maybe sniffing packets to check for the encrypted content is a start.

mkal_tsr 12y ago
https://github.com/SpiderOak https://github.com/SpiderOak || https://github.com/SpiderOak/nimbus.io https://github.com/SpiderOak/nimbus.io
Kryptor 12y ago
Checking for encrypted packets wouldn't tell you anything about the binaries' trustworthiness. A back door might just encrypt the data with a second key, or more specifically, encrypt the key that encrypts the data with another key. A reliable way of testing binaries doesn't seem very feasible to me. It's like antivirus vendors trying to find new viruses: the malware authors can always obfuscate their code just a little more, do it just a little bit differently, and now it does the same thing while escaping detection. Authors of open source software who want to distribute trustable binaries should include instructions for how to reproduce the binary exactly from the source. A third party verifier could reproduce the binary, then publish a digital signature affirming that they reproduced it, allowing anyone who doesn't want to compile it to check with a trusted third party. But all of that is a moot point if the source code isn't being very carefully checked.
rakoo 12y ago
The whole point of being open sourced is that you can compile them yourselves after your verification and use the product of your own compilation with the server-side of spideroak. More realistically, your distribution maintainers will verify and compile the package, and you trust your distribution maintainers more than spideroak so you delegate source verification to them.
- makmanalp 12y ago
  > The whole point of being open sourced is that you can compile them yourselves after your verification and use the product of your own compilation with the server-side of spideroak. So this is a good point, however: > More realistically, your distribution maintainers will verify and compile the package, and you trust your distribution maintainers more than spideroak so you delegate source verification to them. This is actually pretty compelling, but ignores Windows and OSX devices, which not only are the vast majority of all users, but also the least likely to compile their own. They will trust the provided binaries instead. This is one of those "Why Johnny Can't Encrypt" (http://www.gaudior.net/alma/johnny.pdf http://www.gaudior.net/alma/johnny.pdf) situations. I'm not solely criticizing spideroak here, I think this is a more general open problem with any 3rd party service that's meant to be trusted. It's an oxymoron that's been only somewhat breached because of public key cryptography.
  - marcosdumay 12y ago
    Windows and OSX devices are already trusting a huge lot of binaries compiled by companies that we already know that have been compromissed. Or, in other words, nobody that cares about privacy are using those anyway (at least while they care about privacy), by definition.