Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
We (the matrix team) addressed the implementation vulnerabilities discussed here back in September: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en....
The only pending work is switching to TOFU (trust on first use) and client-controlled room membership. Currently users get warned if a malicious device or user gets added to a room by a malicious server (assuming users in the room are verified). However, rather than warning, we could block it outright - but this is nontrivial as it means clients have to independently replicate the group membership semantics the server currently handles, which are complicated in a decentralised environment.
https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift membership to be controlled clientside, and https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift to TOFU.
Meanwhile, this work is blocked behind switching to matrix-rust-sdk-crypto across Element on Web, iOS and Android, so we only fix this in one (audited) place - and can also build on the newly audited vodozemac implementation of Matrix’s encryption: https://matrix.org/blog/2022/05/16/independent-public-audit-...
You are completely misinterpreting my quote, which makes me question whether you are acting in good faith.
Totally agreed that Signal servers cannot just add a device to a group chat.
What I saying was: in any system, you have to verify users for security in general. Having verified users in Matrix, you then get a massive red warning if an unverified device is added to their accounts. Given we have cross-signing (i.e. users are heavily encouraged to verify their own devices when they log in), you can be sure that such unverified devices are malicious and take appropriate action.
The obvious thing we could do is to go one step further (as we used to, until we backed it out in https://github.com/matrix-org/matrix-react-sdk/pull/3837) and stop messages from flowing until the unverified device has been dealt with. Even better would be to make group membership controlled by the clients, so the server can't add devices at all. And we're working on this, as part of shifting the implementations over to the audited matrix-rust-sdk-crypto implementation to avoid having to solve the problem in quadruplicate.
> I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.
Hopefully someone will pop up here and confirm that I'm not talking shit :) Failing that, you'll have to wait for the next Least Authority audit - we have another independent public audit queued once this wave of work finishes to address the "To me Matrix isn't secure" polemicists. You can see the previous one (on the crypto layer, rather than the group membership layer) at https://matrix.org/blog/2022/05/16/independent-public-audit-... fwiw.