I would never trust a closed source messaging app if I was an activist, regardless of what encryption they claim to implement.
I would never trust a closed source messaging app if I was an activist, regardless of what encryption they claim to implement.
Of course I'm not going to read the source code but at least I'm sure developers behind the app do not open a backdoor for someone else.
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.