7 ms·

(Element CEO here). Honestly, it depends on your threat profile. Any kind of bridge has to inevitably MITM your conversations in order to work, and we’ve tried

(Element CEO here). Honestly, it depends on your threat profile. Any kind of bridge has to inevitably MITM your conversations in order to work, and we’ve tried to spell that out in all the product info about Element One. If you want to avoid your E2EE conversations on Signal or WhatsApp being relayed via a service like Element One (because you’re an activist or whatever), then your options are to not bridge at all, or run a bridge yourself. Clientside bridging may be an option in future, but reliably running a bridge in the background on mobile is somewhere between non-trivial and impossible. Finally, we are currently crunching on getting E2EE to work nicely between the bridges and the Matrix clients (so bridged conversations are stored E2EE on the Element One server) and it should be coming in the coming weeks. It’s worth noting again that even when that lands the bridge will still necessarily be able to see bridged conversations at the point of bridging. TL;DR: if you don’t trust Element with your Signal conversations for whatever reason, don’t hook up Signal to your Element One account :)

acomar 5y ago
because "trust us" has such a great track record.
fsflover 5y ago
> Any kind of bridge has to inevitably MITM your conversations in order to work Can't you just pass the encrypted message further without decrypting it? Of course, there needs to be the same decryption mechanism on both sides, but it doesn't make it impossible.
- Arathorn 5y ago
  At that point it’s basically clientside bridging (or multihead messagering), given having decrypted the message (even if you had the right keys available) you’d need to speak the protocol of the remote service.
- KingMachiavelli 5y ago
  It's possible but a lot harder. If the keys/tokens for fetching messages are similar/interlinked to those used to decrypt the messages then you can't separate the two. In this case you would have to do the message 'fetching' and decryption on the client side which would be very difficult for any JS based clients. Then there's the issue of syncing those messages between Element One clients which means the client now has to re-encrypt the messages and send them back to the server. And if the client is responsible for fetching messages then providing push notifications will be very difficult. So if you can actually decouple polling/listening for messages from decryption then it would probably be possible. A brute force approach would be to provide an open source, self-hostable server but can be configured from the centralized Element One service. This server would hold the actual service tokens & decryption keys and would just be sending re-encrypted messages back to Element/Matrix.
  - knocte 5y ago
    > A brute force approach would be to provide an open source, self-hostable server The server/bridge is not opensource? I see their github account has lots of code.
KAMSPioneer 5y ago
That's all well and good, but I believe the original complaint was more concerning the second party in the conversation. There's no way for me, a hypothetical person who wants to keep my Signal messages 100% encrypted in the Signal ecosystem, to opt out of my contacts using an Element bridge. Sure, I can go around and tell everyone I know that they shouldn't bridge Signal to Element One because <cryptonerd rant>, but there's no way for me to tell that my advice has been followed. Previously, the chances that someone had set up such a bridge were small, but by nature of making these things accessible, Element One also increases the risk of my conversations being (benevolently?) MITM'd. I think it's a great offering, but I share GP's reticence about a system that puts what used to be zero-knowledge conversations in plaintext on a third-party server...all without me realizing.
- xanaxagoras 5y ago
  > I think it's a great offering, but I share GP's reticence about a system that puts what used to be zero-knowledge conversations in plaintext on a third-party server...all without me realizing. Element CEO here, you must be a tinfoil hat crazy person, everyone should communicate in cleartext, you're not a terrorist are you
  - dunefox 5y ago
    Element CEO here, why won't anybody think of the children?!
    - 0xdeadb00f 5y ago
      Element CEO here, this comment thread made my day!
      - drummer 5y ago
        Element CEO here, I don't know wtf got into us breaking Signal E2EE, I am stepping the fuck down.
xanaxagoras 5y ago
> (because you’re an activist or whatever) How about because I'm a regular person, and I don't want everything I say analyzed by the federal government and stored in perpetuity? I'm increasingly repulsed by this notion that unless I'm doing something illegal or in opposition the the ruling party, encryption is just a luxury. Encryption is for anyone with any desire to express themselves honestly without modifying their behavior because someone is watching. People flock to Signal for a reason and a lot of them will use this "bridge" without understanding what they're giving up. You're doing more harm that good to try to usher people towards your platform.
- fsflover 5y ago
  > People flock to Signal for a reason Why would you go to a walled garden if you want more freedom/control? You should just go to Matrix and host it yourself (and keep all the metadata to yourself, too!).
  - xanaxagoras 5y ago
    People available to communicate with is a key metric of a communications platform. All of these services lack a large number of regular people. For better or for worse, Signal is the one with the most.
    - Steltek 5y ago
      If you self-host Matrix, you can still bridge to Signal while avoiding the walled garden trap and having complete control of your data? If you don't want to self-host, then you must be comfortable extending trust to someone. SaaS Matrix and Signal seem to be two sides of the same coin, in that case.
      - xanaxagoras 5y ago
        Except my messages are E2EE and signal can't read them. This bridge breaks that encryption before it's reached the intended recipient, which if that recipient is me, I very much don't appreciate it.
superdisk 5y ago
Sure, but this defeats the entire point of Signal. You don't use it to get the maximum amount of reach to other contacts, you use it because you're confident that what you send ISN'T being MITMed... that's the entire value of the app! So unfortunately if this takes off, you never know if the reason you're even using the application is just being violated. It destroys the entire purpose. That said, I love Matrix more than Signal and enjoy its E2EE capabilities.... but I also wish this doesn't take off.
- dunefox 5y ago
  It's still a chat app and if I can't reach enough people it's useless.
- tshaddox 5y ago
  > You don't use it to get the maximum amount of reach to other contacts, you use it because you're confident that what you send ISN'T being MITMed... Sure, but this doesn't actually introduce a new party in the middle of two Signal clients. Someone has to just decide to authorize a Signal client running on a server somewhere to receive messages from you and forward them onward outside of Signal.
asymmetric 5y ago
> TL;DR: if you don’t trust Element with your Signal conversations for whatever reason, don’t hook up Signal to your Element One account :) AFAIU GP’s point was that even if I don’t bridge, the recipient of the message might, thereby diluting the trust all users have in E2E on Signal, since you can’t know who’s bridging and who isn’t.
- monkeywork 5y ago
  That has always been the case no? You can't know what the person you are sending the message to is doing with it, the status of their device, or anything else. I fail to see anything that Element is doing "wrong" here, the issues you are describing are issues between you and your conversation partner
  - asymmetric 5y ago
    That is true, but there is a difference between some messages being screenshotted, and a service that acts as a bridge storing all communication that passes through an account. It's a matter of how likely it is that the assumption "my communication is not going to leak beyond the two participants" is broken. Every step in the wrong direction counts, IMO. Also, AFAIK it wouldn't be trivial to extract all the Signal chat histories from an iPhone device - this new service makes that much, much easier (not least because they'd be remotely accessible).
    - ThatGeoGuy 5y ago
      It seems like you're trying to hold Element to some kind of impossible standard here. It's not like the tech they used to build the bridge didn't already exist. The bridge itself serves a specific purpose (opening up Signal to the Matrix API, allowing for the use of a single app), and succeeds at that. Of course there's a trade-off, and the team (at least allegedly) appears to be working on encrypted bridges so that even if the bridge decrypts from Signal, it re-encrypts on the homeserver at rest in a way that only the user (not the bridge) can decrypt in the future. I think the complaint here is "you advertised a service doing a thing that was already possible, people might use this." I may be mis-characterizing that, but I think it's worth stepping back and thinking a bit more on the actual threat model you face, and how the proposed product (Element One) somehow subverts that. Sure it can do so at scale, but that just means this is one incremental improvement that needs more work, not that the idea needs to be thrown out entirely.
allset_ 5y ago
Your cavilier tone here about casually introducing a MiTM threat that many people won't understand to the e2e encrypted messaging ecosystem is pretty disgusting. As others have noted, the issue is that I can't opt out of other people using this which breaks the security guarantees of the chat system.
- stryan 5y ago
  That's not part of the security guarantee; The message was encrypted from user-controlled end to user-controlled end. It's neither Signal nor Element's fault that your conversation partner has decided to move conversations un-encrypted afterward. That was always allowed.
sneak 5y ago
You misunderstood what he said if that is your TLDR. Furthermore, this is not the first time privacy issues with Matrix have been brought up to you and dismissed without understanding. I am going to begin recommending that people actively avoid adopting Matrix/Element.
- tentacleuno 5y ago
  Could you expand on the "privacy issues", please? Not sealioning or whatever, I am genuinely interested.
  - colbyhub 5y ago
    Not sure what exactly they were referring to, but here are some of them: https://github.com/libremonde-org/paper-research-privacy-matrix.org/blob/master/part1/README.md https://github.com/libremonde-org/paper-research-privacy-mat...
    - Arathorn 5y ago
      sneak’s pet issue is https://github.com/vector-im/element-web/issues/11655 https://github.com/vector-im/element-web/issues/11655: that element web assumes that you want to log into the matrix.org homeserver by default unless you change its config to default to a different one. The libremonde research is over 2 years old now, and the valid bits of it were addressed at the time (https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 https://matrix.org/blog/2019/09/27/privacy-improvements-in-s...)
      - tentacleuno 5y ago
        > element web assumes that you want to log into the matrix.org homeserver Ahh. Seems like an easier problem to fix then. Doesn't Element Android remove that assumption and let you choose?
      - sneak 5y ago
        I've user accounts on 3 different servers, run by 3 different groups. Every single one of them has a configuration, despite a selfhosted instance, that phones home to centralized servers run by your for-profit company. I'm not sure if this systemic problem is in your config files, your documentation, your defaults, your js client, or what. It's a failing of some part (or multiple parts) of the process.
gfodor 5y ago
Signal's core value proposition is radically increasing the expectation that one is having an e2e encrypted conversation. I love Element's product and mission, but a product which explicitly is eroding and complexifying privacy around a 3rd party product which is about privacy seems to be a bad tradeoff, and also stands to undermine the public perception of what Element is all about. I would suggest either carving out the e2e platforms (particularly Signal), or introduce functionality that will ensure conversations had through the bridge inform the counter party that the messages are not e2e encrypted. It's the right thing to do.
knocte 5y ago
> or run a bridge yourself Quick question, is the code for the bridge opensource?

acomar 5y ago

because "trust us" has such a great track record.

fsflover 5y ago

> Any kind of bridge has to inevitably MITM your conversations in order to work Can't you just pass the encrypted message further without decrypting it? Of course, there needs to be the same decryption mechanism on both sides, but it doesn't make it impossible.

Arathorn 5y ago
At that point it’s basically clientside bridging (or multihead messagering), given having decrypted the message (even if you had the right keys available) you’d need to speak the protocol of the remote service.
KingMachiavelli 5y ago
It's possible but a lot harder. If the keys/tokens for fetching messages are similar/interlinked to those used to decrypt the messages then you can't separate the two. In this case you would have to do the message 'fetching' and decryption on the client side which would be very difficult for any JS based clients. Then there's the issue of syncing those messages between Element One clients which means the client now has to re-encrypt the messages and send them back to the server. And if the client is responsible for fetching messages then providing push notifications will be very difficult. So if you can actually decouple polling/listening for messages from decryption then it would probably be possible. A brute force approach would be to provide an open source, self-hostable server but can be configured from the centralized Element One service. This server would hold the actual service tokens & decryption keys and would just be sending re-encrypted messages back to Element/Matrix.
- knocte 5y ago
  > A brute force approach would be to provide an open source, self-hostable server The server/bridge is not opensource? I see their github account has lots of code.

KAMSPioneer 5y ago

That's all well and good, but I believe the original complaint was more concerning the second party in the conversation. There's no way for me, a hypothetical person who wants to keep my Signal messages 100% encrypted in the Signal ecosystem, to opt out of my contacts using an Element bridge. Sure, I can go around and tell everyone I know that they shouldn't bridge Signal to Element One because <cryptonerd rant>, but there's no way for me to tell that my advice has been followed. Previously, the chances that someone had set up such a bridge were small, but by nature of making these things accessible, Element One also increases the risk of my conversations being (benevolently?) MITM'd. I think it's a great offering, but I share GP's reticence about a system that puts what used to be zero-knowledge conversations in plaintext on a third-party server...all without me realizing.

xanaxagoras 5y ago
> I think it's a great offering, but I share GP's reticence about a system that puts what used to be zero-knowledge conversations in plaintext on a third-party server...all without me realizing. Element CEO here, you must be a tinfoil hat crazy person, everyone should communicate in cleartext, you're not a terrorist are you
- dunefox 5y ago
  Element CEO here, why won't anybody think of the children?!
  - 0xdeadb00f 5y ago
    Element CEO here, this comment thread made my day!
    - drummer 5y ago
      Element CEO here, I don't know wtf got into us breaking Signal E2EE, I am stepping the fuck down.

xanaxagoras 5y ago

> (because you’re an activist or whatever) How about because I'm a regular person, and I don't want everything I say analyzed by the federal government and stored in perpetuity? I'm increasingly repulsed by this notion that unless I'm doing something illegal or in opposition the the ruling party, encryption is just a luxury. Encryption is for anyone with any desire to express themselves honestly without modifying their behavior because someone is watching. People flock to Signal for a reason and a lot of them will use this "bridge" without understanding what they're giving up. You're doing more harm that good to try to usher people towards your platform.

fsflover 5y ago
> People flock to Signal for a reason Why would you go to a walled garden if you want more freedom/control? You should just go to Matrix and host it yourself (and keep all the metadata to yourself, too!).
- xanaxagoras 5y ago
  People available to communicate with is a key metric of a communications platform. All of these services lack a large number of regular people. For better or for worse, Signal is the one with the most.
  - Steltek 5y ago
    If you self-host Matrix, you can still bridge to Signal while avoiding the walled garden trap and having complete control of your data? If you don't want to self-host, then you must be comfortable extending trust to someone. SaaS Matrix and Signal seem to be two sides of the same coin, in that case.
    - xanaxagoras 5y ago
      Except my messages are E2EE and signal can't read them. This bridge breaks that encryption before it's reached the intended recipient, which if that recipient is me, I very much don't appreciate it.

superdisk 5y ago

Sure, but this defeats the entire point of Signal. You don't use it to get the maximum amount of reach to other contacts, you use it because you're confident that what you send ISN'T being MITMed... that's the entire value of the app! So unfortunately if this takes off, you never know if the reason you're even using the application is just being violated. It destroys the entire purpose. That said, I love Matrix more than Signal and enjoy its E2EE capabilities.... but I also wish this doesn't take off.

dunefox 5y ago
It's still a chat app and if I can't reach enough people it's useless.
tshaddox 5y ago
> You don't use it to get the maximum amount of reach to other contacts, you use it because you're confident that what you send ISN'T being MITMed... Sure, but this doesn't actually introduce a new party in the middle of two Signal clients. Someone has to just decide to authorize a Signal client running on a server somewhere to receive messages from you and forward them onward outside of Signal.

asymmetric 5y ago

> TL;DR: if you don’t trust Element with your Signal conversations for whatever reason, don’t hook up Signal to your Element One account :) AFAIU GP’s point was that even if I don’t bridge, the recipient of the message might, thereby diluting the trust all users have in E2E on Signal, since you can’t know who’s bridging and who isn’t.

monkeywork 5y ago
That has always been the case no? You can't know what the person you are sending the message to is doing with it, the status of their device, or anything else. I fail to see anything that Element is doing "wrong" here, the issues you are describing are issues between you and your conversation partner
- asymmetric 5y ago
  That is true, but there is a difference between some messages being screenshotted, and a service that acts as a bridge storing all communication that passes through an account. It's a matter of how likely it is that the assumption "my communication is not going to leak beyond the two participants" is broken. Every step in the wrong direction counts, IMO. Also, AFAIK it wouldn't be trivial to extract all the Signal chat histories from an iPhone device - this new service makes that much, much easier (not least because they'd be remotely accessible).
  - ThatGeoGuy 5y ago
    It seems like you're trying to hold Element to some kind of impossible standard here. It's not like the tech they used to build the bridge didn't already exist. The bridge itself serves a specific purpose (opening up Signal to the Matrix API, allowing for the use of a single app), and succeeds at that. Of course there's a trade-off, and the team (at least allegedly) appears to be working on encrypted bridges so that even if the bridge decrypts from Signal, it re-encrypts on the homeserver at rest in a way that only the user (not the bridge) can decrypt in the future. I think the complaint here is "you advertised a service doing a thing that was already possible, people might use this." I may be mis-characterizing that, but I think it's worth stepping back and thinking a bit more on the actual threat model you face, and how the proposed product (Element One) somehow subverts that. Sure it can do so at scale, but that just means this is one incremental improvement that needs more work, not that the idea needs to be thrown out entirely.

allset_ 5y ago

Your cavilier tone here about casually introducing a MiTM threat that many people won't understand to the e2e encrypted messaging ecosystem is pretty disgusting. As others have noted, the issue is that I can't opt out of other people using this which breaks the security guarantees of the chat system.

stryan 5y ago
That's not part of the security guarantee; The message was encrypted from user-controlled end to user-controlled end. It's neither Signal nor Element's fault that your conversation partner has decided to move conversations un-encrypted afterward. That was always allowed.

sneak 5y ago

You misunderstood what he said if that is your TLDR. Furthermore, this is not the first time privacy issues with Matrix have been brought up to you and dismissed without understanding. I am going to begin recommending that people actively avoid adopting Matrix/Element.

tentacleuno 5y ago
Could you expand on the "privacy issues", please? Not sealioning or whatever, I am genuinely interested.
- colbyhub 5y ago
  Not sure what exactly they were referring to, but here are some of them: https://github.com/libremonde-org/paper-research-privacy-matrix.org/blob/master/part1/README.md https://github.com/libremonde-org/paper-research-privacy-mat...
  - Arathorn 5y ago
    sneak’s pet issue is https://github.com/vector-im/element-web/issues/11655 https://github.com/vector-im/element-web/issues/11655: that element web assumes that you want to log into the matrix.org homeserver by default unless you change its config to default to a different one. The libremonde research is over 2 years old now, and the valid bits of it were addressed at the time (https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 https://matrix.org/blog/2019/09/27/privacy-improvements-in-s...)
    - tentacleuno 5y ago
      > element web assumes that you want to log into the matrix.org homeserver Ahh. Seems like an easier problem to fix then. Doesn't Element Android remove that assumption and let you choose?
    - sneak 5y ago
      I've user accounts on 3 different servers, run by 3 different groups. Every single one of them has a configuration, despite a selfhosted instance, that phones home to centralized servers run by your for-profit company. I'm not sure if this systemic problem is in your config files, your documentation, your defaults, your js client, or what. It's a failing of some part (or multiple parts) of the process.

gfodor 5y ago

Signal's core value proposition is radically increasing the expectation that one is having an e2e encrypted conversation. I love Element's product and mission, but a product which explicitly is eroding and complexifying privacy around a 3rd party product which is about privacy seems to be a bad tradeoff, and also stands to undermine the public perception of what Element is all about. I would suggest either carving out the e2e platforms (particularly Signal), or introduce functionality that will ensure conversations had through the bridge inform the counter party that the messages are not e2e encrypted. It's the right thing to do.

knocte 5y ago

> or run a bridge yourself Quick question, is the code for the bridge opensource?