Of course, for that to be feasible, the network architecture of the app must not require API keys—and so must either be purely peer-to-peer, or involve a FOSS server component that the developer can run an instance of themselves (as in the Matrix protocol.)

Of course, the counter is that if you publish it you don't risk that someone actually is checking.

Open beats closed, but we must be careful not to think it immediately makes the code sound.

I've been thinking about this particularly recently in relation to Monzo, the will-be bank. There's no web app and slow progress on the android front. Lots of open source effort though, since they publish an API, but... That's my bank account I'm (not) giving open source developers access to.

nobody is saying it's automatically sound, but open is the only option that makes any security analysis possible.

I'm not disputing that. Let me repeat myself:

> Open beats closed

All I'm saying is that it doesn't stop there. Too often there's this complacent 'great, it's open source!' - I'm as guilty of it as anyone.

Many people are disputing that, and I'm getting around to that view. Closed doesn't mean you have nothing, it means you have the binaries, which you can disassemble and analyse. With open, you have a bit higher level language, which you have to analyse, plus then you have to show that the binaries correspond to it.

Generations of crackers and security researchers have proven that incorrect. There are plenty of tools for dealing with compiled programs.