Well, it is a major step – but Moxie always sells his solutions, even if they’re just a puppy, as solutions for world hunger.
As I mentioned, advertising with Snowden leads to a promise that Signal can not fulfill. Not even with this.
But, you know, there is already a solution for all the issues here: Don’t use phone numbers, use usernames! As it turns out, that is far more private and secure.
First, you're not wrong about Signal being insufficient against nation state adversaries. The Grugq has a nice talk about opsec that I can't seem to find atm. He sums up the issues with Signal nicely in a Medium article. [1]
That said, this particular development is a lot more than a puppy. It's at least a full grown, happy, friendly Golden Retriever who's already house trained and knows how to fetch your slippers.
They've removed one of the biggest remaining weaknesses of their system, where they still required the users to "just trust" them. That's pretty cool, especially for the vast majority of us whose primary adversaries are smaller or profit-driven.
> Don’t use phone numbers, use usernames! As it turns out, that is far more private and secure.
It is. But it's not convenient. Everyone has contact list with numbers and people want to talk to their friends immediately not call them for their ID for service X.
I've got basically no phone numbers of many of my friends, or they've switched them so often that the ones I have are long wrong. Half the numbers in my contacts list don't exist anymore.
Any project made up of hundreds of repos has bad areas which you can cherrypick if you want to bad-mouth, especially whilst still it's very actively in dev. For instance, conversely on iOS we have four different local store API implementations[1] ranging from in-memory, flatfile (via NSKeyedArchiver), CoreData and Realm. The equivalent work just hasn't yet happened on Android; PRs welcome.
Once again, why not invest your time in doing something more productive than spreading FUD about Matrix?
> Once again, why not invest your time in doing something more productive than spreading FUD about Matrix?
Because I’m already investing my time in improving IRC, and there’s little time left after that.
> spreading FUD about Matrix?
Every criticism of mine you’ve admitted to be true, yet call it FUD still. Even this one you admit that there is significant amounts of bad code in Matrix, just argue that other projects have as much. That’s no excuse.
> The equivalent work just hasn't yet happened on Android; PRs welcome.
So why did this happen in the first place? This isn’t even just bad code – someone spent significant amounts of work and time (far more than would’ve been spent for using existing solutions such as Realm) on this. And there’s many pieces of the Matrix code just like that.
The FUD is saying "Matrix's code quality makes me want to puke" and then cherrypicking a non-representative example. Android may still use flatfiles as the work needed to switch simply hasn't happened yet (it's a one person team handling the whole platform), but both iOS & JS SDKs show the opposite picture (iOS with 4 stores; JS SDK supporting 3 different stores; in-memory, localStorage and indexeddb).
So, please back off. We wish IRCv3 and your projects the best; please stop spewing negativity about us.
That was a representative sample of the code quality on the Android side.
The problem isn't in flat files, it's in "serializing" to the flat files by dumping the objects directly from memory. Specifically, Java's native serializer is used, which serializes types and constructors in a non+portable way. There are fucktons of people that get this wrong, every second RCE in JavaEE was due to this. It's long deprecated. You use it as only storage backend.
Files written that way can't be reliably read on different android versions, or different devices.
Reading such files back in basically allows anyone with write access to the files to execute whatever they want in your process, because it also serializes constructors.
The problem isn't flat files, but that whoever wrote that code has never had any experience with security critical code.
I can easily provide hundreds more examples of this. Race conditions that lead to private messages being sent unencrypted. Bugs that cause full crashes due to code errors. Horrible messaging performance with tons of low hanging fruit.
All this would be fine were this a random flashlight app.
But if an app with a focus on secure messaging fucks up the secure part and the messaging part, then it's definitely not something I'd want to use. I've got apps of my own that I've worked on daily for 3 years that have similar code quality — but guess what, I haven't released them, because of this code quality.
With secure messaging, you can't release first and iterate later, you actually need to build a secure solution from the first version on.
The fact that you apply Silicon Valley mentality to secure messaging makes it already problematic. If your company needs to iterate or pivot, you can. But once your data's been sent unencrypted, it's gone.
And the fact that you also don't even notice the problem with this code even when I'm pointing you directly at it makes it even worse, because it makes your project even less trustworthy.
We know the issues around ObjectStreams and rehydrating constructors; mad gadget style vulns etc. But this is a local cache of trusted data which can only ever be touched by the app, and if an attacker is starting to mess around with your app's file storage you are already in a pretty bad situation. And, as I said, this is a placeholder for a proper DB.
In terms of whether "release and iterate" is unacceptable for secure messaging: we make it abundantly clear that the privacy protecting features are still in development and are beta quality and shouldn't be used for anything where privacy is critical. Meanwhile the idea that secure messaging products shouldn't be publicly beta'd prior to a formal GA (especially for stuff as complex as decentralised e2e crypto) feels weird at best.
If you've found fatal crashes or races in the E2E UX, please do the responsible thing and chuck an email to security@matrix.org rather than bragging about non-specifics here. Finally: Matrix's projects span a little bit more than just the Android SDK, which is admittedly mid-development still. So yes, there's loads of low-hanging optimisation work to be done and some areas of crappy code, but that's not remotely the whole picture.
As I mentioned, advertising with Snowden leads to a promise that Signal can not fulfill. Not even with this.
But, you know, there is already a solution for all the issues here: Don’t use phone numbers, use usernames! As it turns out, that is far more private and secure.