[orblivion]

> Encryption is still opt-in and beta

This is the part that concerns me.

https://whispersystems.org/blog/the-ecosystem-is-moving/

Moxie lays out a challenge to federation enthusiasts to prove him wrong that federated chat can be secure and have good usability. I would respectfully note that Matrix seems to be responding to the challenge with a chat client that is neither. Instead they seem to be doubling down on federation and integrations. Usability can be fixed, but the federation and multiple clients makes it a challenge. Security on the other hand is, again, concerning because it feels tacked on. It's not on by default because, again, it makes it complicated when you have multiple clients. Last time I tried, you could put in your password on the web client (browser encryption!) and join an existing conversation, and see all future posts by the people in the conversation, because suddenly they've accepted your new public key. I had to dig a little bit in the configs to find the current public keys for the clients in the conversation. Either they have to make a UX-friendly way of warning everybody that there's a new client, or accept that stealing an account password will let you snoop on conversations. I really appreciate their enthusiasm, and I hope someone gets federation right, but it just seemed like a mess.

By contrast, I think that Signal recognized that you can work around the security vs usability tradeoff by trading off on a third vector: feature set. I think that we won't get a federated system until someone heeds Moxie's warnings and does some careful, creative thinking.

[Arathorn]

> It's not on by default because, again, it makes it complicated when you have multiple clients

This is simply not true. The reason it's not on by default is because we're still developing it and it's in beta. It's not tacked on; we've designed in E2E from the outset - but implementing it well in a decentralised manner is a huge amount of work; probably 5-6x more than in a centralised system like Signal. We're not going to enable it by default until we are 99.999% sure that it won't cause regressions over the non-e2e client.

> Either they have to make a UX-friendly way of warning everybody that there's a new client

I think you must have tried it a (very long) while ago - we've had the UnknownDeviceDialog since February. It looks like this (https://matrix.org/_matrix/media/v1/download/matrix.org/mOOj...), and warns you every time a new device is added to the room, and gives you the option of blacklisting it from receiving your messages if you don't trust it.

Now, totally agreed that this UX is ugly and needs work, but this is NOTHING to do with the decentralised or federated nature of the protocol. It's simply that we currently are very resource constrained currently for working on web front-end issues.

That said, if your ONLY priority is security, then Moxie's "the ecosystem is moving" probably has a point. After all, in an open ecosystem like Matrix, it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room. However, if you value freedom as well as privacy, Matrix or OMEMO are basically your only choices.

[orblivion]

> This is simply not true.

Alright, you make a convincing case that it's not tacked on and I'll give you the benefit of the doubt here. Unencrypted basically is just "dev mode".

Very glad to hear you patched up the hole with the unknown clients. Perhaps I'll try again down the line.

> Now, totally agreed that this UX is ugly and needs work, but this is NOTHING to do with the decentralised or federated nature of the protocol.

Well you have to design that dialogue that tells you new devices came on, right? And you have to deal with cases where some people accept a new client and some don't. And you have to explain to lay people what the heck an IRC bridge is. And so on. My point is just that you have a lot more things to explain to users, so you have a lot of UX work ahead that you wouldn't otherwise have. So I don't think it's unrelated. (Aside from the issue of explaining things, it's not particularly ugly actually, from what I remember).

> it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room

I appreciate that you acknowledge that. It signals that you have things in perspective.

I actually think some people do consider freedom to be a security issue. They don't want Signal servers to go down, or get into malicious hands.

Also: Nothing strictly stops people from using rogue Signal clients either. There's just social pressure deterring it. By that same token, perhaps you could use social pressure to deter developers from lying about what client they are, and then have a vetting process for secure clients. And then warn users when an insecure one comes on. (And perhaps count web as "not recommended for especially sensitive discussions")

Anyway, thank you for addressing my points and accepting critique. I do hope to see you succeed.

[solatic]

> After all, in an open ecosystem like Matrix, it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room.

Isn't this a case for building in some kind of system whereby clients can be signed and have their signatures revoked by their creators or, for lack of a better word, ostracized by the wider community? Sort of like a web of trust model, but for clients, not just users, to make it more clear when somebody is joining with an untrusted client and perhaps allow moderator control over whether to allow untrusted clients to join.

[Arathorn]

Possibly, but this is heading into seriously DRM territory. one would need to be running the app in some kind of secure enclave that could attest to the authenticity of the app (e.g. via SGX on Intel). There's something a bit unsavoury about saying that "only truly official signed apps are allowed to participate in this open network", and it gives a huge amount of power to those responsible for the secure enclave/trusted computing stuff. (There's also the approach that djb mentions in https://twitter.com/hashbreaker/status/732912508089032706)

It's possible that just relying on social mechanisms may be enough to discourage people from running known evil apps (similar to educating users not to install malware today, or do trusted operations with cybercafe computers, or whatever). Effectively, the verification process when going and explicitly trusting a new device needs to explicitly prompt the user to consider where on earth this app came from, and if it should be trusted.

The only alternative is really DRM, which just feels wrong.

[solatic]

>There's something a bit unsavoury about saying that "only truly official signed apps are allowed to participate in this open network", and it gives a huge amount of power to those responsible for the secure enclave/trusted computing stuff.

Maybe it's a bit naive, but isn't that what federation is supposed to solve? People who are more security-paranoid can forbid clients which don't have the highest security certification, and operators who aren't so diligent will be fine with signed clients being run on untrusted hardware.

I mean... is there any open-source software being developed today which enforces key security in secure hardware enclaves? Verifying the GPG signatures on binary packages is "good-enough" for most operators. Build reproduceability will help to further reduce trust of unverified hardware.

It seems to me the job of the protocol, and baseline/recommended UI/UX, is merely to help users make informed decisions. Security is a spectrum, and if signed clients improve security (while not fraudulently representing itself as perfect or near-perfect security, if it were running on trusted hardware), then that's a net benefit to the open network.

[Arathorn]

I may be missing something, but how do you prove that an app is running a trusted codebase? I know of no PGP clients for instance that sign messages to try to prove that they were sent from a trusted app (as opposed to a trusted user). The only way I know of to do this would be to hook into a trusted execution environment of some flavour like Intel's SGX or Apple's Secure Enclave, to let effectively the chip vendor sign off that you are running an official app installed by official means. You /could/ do this, but you are putting a lot of trust in the secure enclave implementation and those controlling it, and essentially putting all your eggs in one basket. It might also lure users into a false sense of security: just because a user is using an appstore signed copy of an app doesn't mean that app is actually trustworthy or bug free. And it would also artificially discriminate against legitimate apps which aren't part of a trusted execution environment, which seems dangerous - and effectively promoting DRM at the expense of FOSS.

This certainly needs more thought :)