[tptacek]

No. Virtually everything Signal has proposed to use SGX for, competing secure messengers simply store in plaintext databases already. Further, the fundamental security model of Signal is about what you don't send to Signal in the first place.

[comex]

Yes. Signal should have taken your last sentence to heart and not implemented contact discovery. The feature actually compromises privacy even when used as intended, because anyone can see whether anyone else uses Signal (and, if you check regularly, when they started using it, which can be revealing). The fact that the feature requires sending your entire contact list to Signal's servers (using a broken encryption mechanism) is just another reason not to do it. To add insult on top of injury, Signal doesn't even notify the user it's uploading their contact list, instead using an actively misleading description when it asks for contacts permission ("See contact names and photos in your chats").

[saagarjha]

It's such a silly hill to die on, too. SGX keeps breaking, their push for it remains annoying, and it's not even that great of a feature. Why are they so ardent about it?

[lrvick]

But SGX is almost no better than plain text, especially when centralized.

At least solutions like Matrix give you the choice where your metadata is stored, and have never had a requirement for PII like phone numbers to worry about in the first place.

[tptacek]

Matrix, the secure messenger where all messages are group messages, and servers control the group membership?

[lrvick]

Meanwhile Signal has a single stranglehold on the supply chain for client binaries that hold all decryption keys.

I will not deny you have made valid criticisms of the matrix protocol, but Signal has some very broken design choices as well. One of these is much easier to fix by motivated technical end users than the other.

At least in matrix a user choice of client codebase and binary can control which server they trust, and if they wish to automatically encrypt to new unverified room participants or not depending on their threat model. Technical users have total control over their rooms and the UX will improve for less technical users.

Also it is possible for someone to run the server daemon in a remotely attestable system like a Nitro enclave allowing it to prove to users what administrative features are enabled on a given server. This is something I am building foundations for right now.

Unlike Signal, any organization is free to run their own matrix servers with server-pinned channels adjusted for different threat models while still having access to the wider network. You get to choose the server that can decide your room membership, including choosing a server that does not grant a central administrator any significant trust.

If forced to pick between two flawed protocols, I will choose an open network controlled by democracy that gives individual users total freedom to make it better over a dictatorship for the long run.

[Arathorn]

fwiw https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the ongoing work to solve the problem of server-controlled group membership. unfortunately it’s not a trivial problem in a decentralised network (which is why we punted it so far), but it’s starting to shape up.