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.

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.

> 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) 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.

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.

https://github.com/SpiderOak || https://github.com/SpiderOak/nimbus.io

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.