Observation only goes so far. You couldn't find backdoors unless you started to decompile it.
I think having a trusted compiler is an important first step to trusting software, even if you have to analyize it in depth yourself.
I think having a trusted compiler is an important first step to trusting software, even if you have to analyize it in depth yourself.
https://www.dwheeler.com/trusting-trust/dissertation/wheeler...
But note you are now adding a lot of extra preconditions that are largely not available.
The counter argument is reverse engineering & black box audits are actually easier than getting the conditions right to trust code audits. As a bonus they work regardless of the code availability.
My original claim, that I stand beside, is that code audit-ability for security purposes is not a reason to prefer open source software. For all the reasons this thread points out, that is just as fraught as auditing closed source software. Further, a competent audit of the software would not look much different between open and closed source projects.
Absent a competent audit, there are lots of other factors that are higher on my (and many more knowledgeable peoples) lists for importance to security and privacy than open vs closed source. Things such as documented and approved algorithms, the team involved, the amount of legal backing, the market incentives etc.
That is not to say there aren't reasons to prefer non-Google based API or to prefer open sourced software for other reasons. Just security audit-ability is a bad one.
I never said that. Come on, dude.