We open sourced our instant answers platform a couple years ago, in the hope to get more eyeballs on them (for quality and quantity): http://duckduckhack.com/ It might not address your point but any underlying flaws (randomness, etc) can be caught/fixed by the community.

Sounds like that still requires that we trust DDG to be actually using the code in its git repo.

Yes, just like you're trusting the gazillion lines of code running on your own computer. No one is able to audit all of them in their lifetime.

Giving the benefit of the doubt to the gazillion lines of code running on your computer, that you and several million other people downloaded from the same place, with verified SHA sums, is actually pretty reasonable. If you're truly paranoid, all you have to do to ensure that you're benefiting from crowd-sourced verification is verify the SHA sum code.

Stuff running on some website that only the web site admins can see is not in the same ballpark.

Where you download it from and SHA only gives guarantees about integrity of the data transfer. I am talking about trusting that the code does what it is supposed to do. Bugs can hide in code for years, whether inserted accidentally or intentionally, as the Heartbleed episode demonstrates. SHA does absolutely nothing against this.

I'm addressing malice, not oversight. The SHA allows you to be confident that you've got the same code as everyone else.

I was addressing malice as well. Having the same code is no guarantee that it does not contain an intentional bug that can be exploited. Neither is knowing that it came from some specific entitity (code signing), because again this presupposes establishing trust. There is no technical solution to trust.

But if the code you have is the same as the code millions of other people have, it's safer to give it the benefit of the doubt than a single server than only a handful of people have access to.

I just gave you an example where it turned out not to be safer: Heartbleed. Malicious bugs can be well hidden, also in open source code. The openness shouldn't give you a false sense of security, because it doesn't imply the code has been audited any better than some closed source code.

I disagree that heartbleed is an example of not being safer. If everyone's SSL was a closed-source library, then we would be considerably less safe.

But to carry the analogy to a closed-source web site that you just connect to, as is the topic of this comment thread, we'd certainly be less safe if we routed all SSL traffic through an unknown system on the web that had the opportunity to decrypt and encrypt.

> it really a good idea to trust DDG (or any remote web service) to generate a strong password?

Probably not, but for ease of use, I've used it a couple of times to generate temporary passwords that users are forced to change on login.