The only practical issue raised by https://nebuchadnezzar-megolm.github.io/ which we didn’t already fix is the question over whether servers or clients should control group membership. Our position is that it’s okay for the server to control it as long as clients are warned if malicious users/devices are added. Fixing it properly is Hard: for instance, if you are chatting in a room and it turns out that a remote user kicked another remote user, but the kick was delayed in reaching you, you could keep chatting away encrypting messages for a user who is no longer in the room and theoretically should not be receiving them. Is this a security flaw? Or is this just how causality works? So we’re dealing with problems similar to that; hopefully we will be able to switch to client controlled membership by end of year.
It is my understanding that this mostly works with rooms/channels over bridges - not with individual, 1-on-1 communication. Do you have a hint how to set this up?
I have set up a bridge on my own server. I bridge 1-on-1 chats and group chats equally and have set up spaces to separate the different clients for ease of overview.
Bridging chats of different technologies doesn't work well/at all (i.e. Signal bridge + WhatsApp bridge users in a single room) but bridging external chats (DM or group) into Matrix works very well. Some services need a daemon running on a phone (i.e. WhatsApp) and that's very annoying, but where possible these bridges all run in the cloud.
If you trust third parties, you can also go the easy route by getting a subscription from EMS (https://element.io/matrix-services/ems-pricing) or Beeper (https://www.beeper.com/). I personally prefer to keep my messages and encryption keys on devices I control, but others prefer to let someone else take care of it all and I respect that.
If you use the Ansible playbook, all you should really need to do is run through the setup, fire up a Matrix client, start chats with bot accounts, and follow the instructions on the guide (usually sending /login to a bot and authenticating your account with whatever service you're bridging).
Your Matrix account doesn't have to be on the same server as your bridges, which is a setup some seem to prefer. You can set up a Matrix server just for bridging so that you don't need to set up all the VoIP features and performance tricks while keeping your own server dedicated to just bridging stuff. This does break some nice features (i.e. double puppeting, a bridge feature) but it also makes your own server less of a single point of failure if you ever do get talking on Matrix.
Most bridges work by running a program that will emulate a client. For example, with Telegram/Whatsapp/Signal you will authenticate the bridge bot using a qr-code just like if you were authenticating on a computer.
Also see [1], they have every bridge's features well documented.
Matrix has fundamental security problems that they seem unwilling to fix. Almost a polar opposite to Signal.
This is categorically not true, as per https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en....
The only practical issue raised by https://nebuchadnezzar-megolm.github.io/ which we didn’t already fix is the question over whether servers or clients should control group membership. Our position is that it’s okay for the server to control it as long as clients are warned if malicious users/devices are added. Fixing it properly is Hard: for instance, if you are chatting in a room and it turns out that a remote user kicked another remote user, but the kick was delayed in reaching you, you could keep chatting away encrypting messages for a user who is no longer in the room and theoretically should not be receiving them. Is this a security flaw? Or is this just how causality works? So we’re dealing with problems similar to that; hopefully we will be able to switch to client controlled membership by end of year.
tptacek’s derision is not very constructive.
What security problems?
Genuinely curious, not trying to be antagonistic.
Commentry from tptacek: https://twitter.com/tqbf/status/1575259743278563329
on this paper: https://nebuchadnezzar-megolm.github.io/
3 replies →
https://arstechnica.com/information-technology/2022/09/matri...
It is my understanding that this mostly works with rooms/channels over bridges - not with individual, 1-on-1 communication. Do you have a hint how to set this up?
I have set up a bridge on my own server. I bridge 1-on-1 chats and group chats equally and have set up spaces to separate the different clients for ease of overview.
Bridging chats of different technologies doesn't work well/at all (i.e. Signal bridge + WhatsApp bridge users in a single room) but bridging external chats (DM or group) into Matrix works very well. Some services need a daemon running on a phone (i.e. WhatsApp) and that's very annoying, but where possible these bridges all run in the cloud.
If you trust third parties, you can also go the easy route by getting a subscription from EMS (https://element.io/matrix-services/ems-pricing) or Beeper (https://www.beeper.com/). I personally prefer to keep my messages and encryption keys on devices I control, but others prefer to let someone else take care of it all and I respect that.
It's relatively straight-forward to set up a bridging server if you're comfortable with Docker and YAML files. You can read how to set up a Matrix server here: https://matrix.org/docs/guides/free-small-matrix-server and here: https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
If you use the Ansible playbook, all you should really need to do is run through the setup, fire up a Matrix client, start chats with bot accounts, and follow the instructions on the guide (usually sending /login to a bot and authenticating your account with whatever service you're bridging).
Your Matrix account doesn't have to be on the same server as your bridges, which is a setup some seem to prefer. You can set up a Matrix server just for bridging so that you don't need to set up all the VoIP features and performance tricks while keeping your own server dedicated to just bridging stuff. This does break some nice features (i.e. double puppeting, a bridge feature) but it also makes your own server less of a single point of failure if you ever do get talking on Matrix.
Most bridges work by running a program that will emulate a client. For example, with Telegram/Whatsapp/Signal you will authenticate the bridge bot using a qr-code just like if you were authenticating on a computer.
Also see [1], they have every bridge's features well documented.
[1] https://matrix.org/bridges/