14 ms·

> It’s also worth noting that end-to-end encryption is necessarily broken as messages to (and from) WhatsApp, Signal and Telegram pass across the bridge(s). The

> It’s also worth noting that end-to-end encryption is necessarily broken as messages to (and from) WhatsApp, Signal and Telegram pass across the bridge(s). The bridge(s) operates in Element’s trusted EMS environment, with no content scanning or datamining, but currently bridged conversations are not stored end-to-end encrypted in Matrix (they will be in the future). As a Signal user, I kind of don't want this to take off. I like knowing that when I message someone on Signal, it's for their eyes only. It feels like this service starts fragmenting some of the privacy guarantees of the bridged providers.

deleted 5y ago
[deleted]
yosito 5y ago
> this service starts fragmenting some of the privacy guarantees There is no guarantee of privacy with communication between two consumer smartphones. Encrypted Signal-to-Signal messages have always been susceptible to capture on either end, by something like this bridge or a rogue (or non-rogue) app on either end with access to read device notifications. I'm not saying that this service doesn't expose your messages to some additional risk, and should be used cautiously. But it is an illusion that just because the messaging protocol is using end-to-end encryption that the messages can't be intercepted.
lvass 5y ago
I concur. I really wouldn't mind anyone using this for whatsapp as I consider any message I send there is also available to 14-eyes, but bridge usage really should be disclosed to Signal users.
pmlnr 5y ago
I want this to take off. I'm tired of having to follow trends because people suddenly think there's a new shinyshinytrendy thing around: IRC to ICQ to MSN to Skype to Google Talk to Facebook Messenger to Whatsapp to Signal. Pidgin is good (I also miss the ancient Trillian, even though it was closed source), but limited to a local device. There are XMPP Transports as well for these (see https://git.eta.st/eta/whatsxmpp https://git.eta.st/eta/whatsxmpp , https://gitlab.com/nicocool84/spectrum2_signald https://gitlab.com/nicocool84/spectrum2_signald , but sadly https://spectrum.im/ https://spectrum.im/ is surprisingly finicky to set up.) EDIT: for encryption fans, I've been wondering for a long time now: why would you trust ANY 3rd party with your so sensitive data instead of running your own service? Are you not aware of OMEMO for XMPP? (See https://omemo.top/ https://omemo.top/ )
- txtsd 5y ago
  Trillian was awesome! It's just a shell of its former self now.
- loriverkutya 5y ago
  I don’t run my own service for the same reason I don’t build my own car or I don’t do accounting for my company, I don’t have the time to learn how to do it nor doing it.
  - pmlnr 5y ago
    No, this is not the same. You want the utmost privacy, yet you still decide to trust someone over it.
    - lxgr 5y ago
      The threat model is vastly different, though.
    - noirbot 5y ago
      I don't want "the utmost privacy". I want something better than raw SMS. I'm not an international secret agent. I encrypt things out of principal more than because I really care if some government force reads them. If a nation-state decides I'm of interest to them for malicious reasons, I'm probably screwed either way.
      - jeltz 5y ago
        Then these bridges are fine. Virtually everything is better than raw SMS.
        grassjumper 5y ago
        That depends a lot. In a civilized country with low risk of 2G downgrade attacks and sensible telecom laws/law enforcement restrictions, SMS is a lot more secure and private than many other options. Obviously still a long way off actual secure communication though.
Iv 5y ago
You can self-host. I suspect they use this: https://github.com/spantaleev/matrix-docker-ansible-deploy https://github.com/spantaleev/matrix-docker-ansible-deploy
- Arathorn 5y ago
  You can indeed self host (although Element One doesn’t use slavi’s ansible playbooks but instead the Element Matrix Services hosted infra we use to host Mozilla, FOSDEM, HOPE, KDE, GNOME etc)
trenchgun 5y ago
You don't know that when you message someone on Signal it's for their eyes only. What you know is that unless their device is compromised, it is up to them to decide who can read the messages that you send to them. Thus the situation with the bridge is not in reality different from the situation now.
- zepto 5y ago
  No - the bridge could be compromised without your conversation partner’s involvement. I.e. the bridge is a vulnerability that enables man in the middle attacks.
  - TeMPOraL 5y ago
    From your POV, the threat model is equivalent to your partner being compromised themselves, and reporting your conversation to criminals/terrorists/law enforcement/intelligence agencies/boogeyman du jour. Bridges don't install themselves in place of platform's messengers - it's the user that has to make an active choice to use one. If you don't trust your partner making a right choice for both of you, you can't really trust them not to tattle on your conversation, or get their computer compromised by generic system-wide malware. And if the bridges themselves are shoddy? Well, I kind of blame the platforms like Signal and WhatsApp, for forcibly bundling their messaging service and their chat client. Were they to open up their APIs to alternative frontends, they could make it so that those alternative frontends identify themselves to the other party in the conversation, and it would remove the need to develop fully transparent bridges for legitimate use.
    - ruined 5y ago
      the threat model is not the same, there is an additional vector. it's not hard to see how a bridging service provides a single point of compromise and is a high value target compared to a million independent endpoints it is literally a step back towards the centralized unencrypted messenger model say what you will about the centralized e2e model, but you can't argue that the previous situation was better.
    - 5y ago
Arathorn 5y ago
(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.
teekert 5y ago
I won't use it for signal indeed, for whatsapp though... can't wait to throw it of my phone!! I didn't dive into it, but can you also self-host this? Looking forward to some docker-compose snippets in that case :)
- stryan 5y ago
  All the bridges (and the matrix server itself of course) are self-hostable.
- broodbucket 5y ago
  Here you go: https://docs.mau.fi/bridges/go/whatsapp/setup/docker.html https://docs.mau.fi/bridges/go/whatsapp/setup/docker.html Element One uses a modified mautrix-whatsapp, which means that your phone needs to be connected to the internet for the bridge to work - so you can't quite throw it off your phone. I don't have to regularly open the app or anything, though.
  - teekert 5y ago
    Hmm, ok, but I could keep it on a spare, empty, old phone at home then perhaps. Still, would have been nice to get rid of it entirely, but I see how that is impossible indeed.
    - broodbucket 5y ago
      Spare phone method should work, I've barely used whatsapp so I'm not sure if it needs a SIM after setup.
ergl 5y ago
For all you know your Signal contacts are using a CLI client and then forwarding the messages through SMS to their feature phones :^)
- dane-pgp 5y ago
  If you believe that, then I have a bridge to sell you. :^)
phicoh 5y ago
In theory, signal could work with matrix people to support bridging with e2e encryption. But as far as I know, signal wants to be walled garden. So then it is expected that people create work arounds.
pkulak 5y ago
> I like knowing that when I message someone on Signal, it's for their eyes only. That's not how it works at all. E2E encryption only guarantees that your message is securely delivered to the other party, not that the other party can't do as they please with it. Signal messages are still stored in plain text on the end devices. They can still be backed up to the cloud (when I used Signal, all my chats were). Hell, photos/screenshots can still be taken of the app. If you want total security, you have to trust the delivery AND the end user. Bridging doesn't really change any of that.
freeopinion 5y ago
If privacy mattered that much to you, you wouldn't depend on Signal to encrypt your messages. You would encrypt them before handing them to Signal. So you should have an encrypted message that you hand to Signal. Signal encrypts it again and hands it to the bridge. Eventually, whether at the bridge or at the other end or wherever, something decrypts the Signal message. Then the person you are communicating with applies the final decryption outside of Signal, Matrix, or whatever. If this sounds terribly inconvenient to you, perhaps privacy is not as important as you claim. Security and convenience are almost always in conflict.
- grassjumper 5y ago
  This is like saying "If you don't sweep the bathroom for bugs/cams, you don't really care about privacy. Why do you bother closing the door"
- idrios 5y ago
  This is a very all or nothing mentality. It's also kind of like saying you should put locks on your locks. Signal's core reason for existing is that it puts a focus on privacy. They say this all over their homepage [0]. One of the founders of WhatsApp donated $50M to Signal [1] out of regret for how WhatsApp shifted away from privacy after being acquired by Facebook. The entire project is freely visible to anyone on github [2]. They've made it so even if you don't trust their servers, you can set up your own server and clone your own android/ios app, change some settings and have everything hosted yourself. There's no reason not to expect Signal to maintain the focus on privacy that they've put in thus far. [0] https://www.signal.org/ https://www.signal.org/ [1] https://www.wired.com/story/signal-foundation-whatsapp-brian-acton/ https://www.wired.com/story/signal-foundation-whatsapp-brian... [2] https://github.com/signalapp https://github.com/signalapp
  - freeopinion 5y ago
    For most people, privacy is a nice-to-have thing. When it's just nice to have, Signal checks that box. If your life depended on it, you would be foolish to depend solely on Signal. How nice it is that encryption has emerged from the dark corners of life and death to become a fashion accessory. But for those that still exist in the world beyond fashion, your criticism seems naive.
barbazoo 5y ago
I got so excited for this until I read that, too. I wish there wasn't fragmentation like there is now but MITMing all my comms is definitely not a smart choice if I chose any of the comm systems it bridges based on privacy.
deleted 5y ago
[deleted]
ElijahLynn 5y ago
Very good point on not wanting this to take off so that you know if you send it to someone, it is for their eyes only. It does seem like since both Signal and Matrix are open source, including the servers, that there should be a path to let one a Signal user know if they are sending it to a Matrix bridge and the encryption is no more. Also worth noting is that you do need to trust the person on the other end for Signal to have a chance at working, e.g. they can take screenshots or real camera pictures of the messages. So establishing trust with the recipient is rule #1, and this should go for if they are using a Matrix bridge with Element One too.
- grassjumper 5y ago
  There's a difference between malice and ignorance, though. My mom in her 70s is using Signal, and I don't think I can blame her for not realizing the vulnerability. I doubt most people will read the Element webside that carefully.
mindslight 5y ago
So then advocate for Signal to fully support third party clients, so that such functionality can be widely supported by multi protocol clients (ala pidgin) rather than needing centralized non-E2E bridges to cope with the administrative overhead of maintaining interoperability.
zuck9 5y ago
Been using https://texts.com https://texts.com — they preserve E2E for Signal/WhatsApp.
- lvs 5y ago
  Um, how do they do that? > All integrations were implemented in-house using the Texts Platform SDK. The SDK will be open sourced at a later date. Seems like a big nope.
  - zuck9 5y ago
    https://texts.com/privacy https://texts.com/privacy says: > Messages, contacts, auth credentials, account information never touch Texts servers. > Your messages are sent directly to the messaging platforms. > All end-to-end encryption is preserved when the platform supports it. > Texts is a client and works like the official app. Apparently all the code runs on the user's device.
toastal 5y ago
This reminds me how absurd it is that OSS projects are bridging Matrix, Discord, and IRC. These all have vastly different ToS and forms of encryption and user privacy. By doing this you can be taking an encrypted message on Matrix and implicitly agree to the ToS and reposting their message to something closed-source and with sketchy privacy like Discord, which defeats the purpose on why one would choose Matrix.
ymolodtsov 5y ago
Come on. E2E encryption is about transmitting the content in transit and in the cloud (if there's a cloud). After people receive your text they can do anything with it.

deleted 5y ago

[deleted]

yosito 5y ago

> this service starts fragmenting some of the privacy guarantees There is no guarantee of privacy with communication between two consumer smartphones. Encrypted Signal-to-Signal messages have always been susceptible to capture on either end, by something like this bridge or a rogue (or non-rogue) app on either end with access to read device notifications. I'm not saying that this service doesn't expose your messages to some additional risk, and should be used cautiously. But it is an illusion that just because the messaging protocol is using end-to-end encryption that the messages can't be intercepted.

lvass 5y ago

I concur. I really wouldn't mind anyone using this for whatsapp as I consider any message I send there is also available to 14-eyes, but bridge usage really should be disclosed to Signal users.

pmlnr 5y ago

I want this to take off. I'm tired of having to follow trends because people suddenly think there's a new shinyshinytrendy thing around: IRC to ICQ to MSN to Skype to Google Talk to Facebook Messenger to Whatsapp to Signal. Pidgin is good (I also miss the ancient Trillian, even though it was closed source), but limited to a local device. There are XMPP Transports as well for these (see https://git.eta.st/eta/whatsxmpp https://git.eta.st/eta/whatsxmpp , https://gitlab.com/nicocool84/spectrum2_signald https://gitlab.com/nicocool84/spectrum2_signald , but sadly https://spectrum.im/ https://spectrum.im/ is surprisingly finicky to set up.) EDIT: for encryption fans, I've been wondering for a long time now: why would you trust ANY 3rd party with your so sensitive data instead of running your own service? Are you not aware of OMEMO for XMPP? (See https://omemo.top/ https://omemo.top/ )

txtsd 5y ago
Trillian was awesome! It's just a shell of its former self now.
loriverkutya 5y ago
I don’t run my own service for the same reason I don’t build my own car or I don’t do accounting for my company, I don’t have the time to learn how to do it nor doing it.
- pmlnr 5y ago
  No, this is not the same. You want the utmost privacy, yet you still decide to trust someone over it.
  - lxgr 5y ago
    The threat model is vastly different, though.
  - noirbot 5y ago
    I don't want "the utmost privacy". I want something better than raw SMS. I'm not an international secret agent. I encrypt things out of principal more than because I really care if some government force reads them. If a nation-state decides I'm of interest to them for malicious reasons, I'm probably screwed either way.
    - jeltz 5y ago
      Then these bridges are fine. Virtually everything is better than raw SMS.
      - grassjumper 5y ago
        That depends a lot. In a civilized country with low risk of 2G downgrade attacks and sensible telecom laws/law enforcement restrictions, SMS is a lot more secure and private than many other options. Obviously still a long way off actual secure communication though.

Iv 5y ago

You can self-host. I suspect they use this: https://github.com/spantaleev/matrix-docker-ansible-deploy https://github.com/spantaleev/matrix-docker-ansible-deploy

Arathorn 5y ago
You can indeed self host (although Element One doesn’t use slavi’s ansible playbooks but instead the Element Matrix Services hosted infra we use to host Mozilla, FOSDEM, HOPE, KDE, GNOME etc)

trenchgun 5y ago

You don't know that when you message someone on Signal it's for their eyes only. What you know is that unless their device is compromised, it is up to them to decide who can read the messages that you send to them. Thus the situation with the bridge is not in reality different from the situation now.

zepto 5y ago
No - the bridge could be compromised without your conversation partner’s involvement. I.e. the bridge is a vulnerability that enables man in the middle attacks.
- TeMPOraL 5y ago
  From your POV, the threat model is equivalent to your partner being compromised themselves, and reporting your conversation to criminals/terrorists/law enforcement/intelligence agencies/boogeyman du jour. Bridges don't install themselves in place of platform's messengers - it's the user that has to make an active choice to use one. If you don't trust your partner making a right choice for both of you, you can't really trust them not to tattle on your conversation, or get their computer compromised by generic system-wide malware. And if the bridges themselves are shoddy? Well, I kind of blame the platforms like Signal and WhatsApp, for forcibly bundling their messaging service and their chat client. Were they to open up their APIs to alternative frontends, they could make it so that those alternative frontends identify themselves to the other party in the conversation, and it would remove the need to develop fully transparent bridges for legitimate use.
  - ruined 5y ago
    the threat model is not the same, there is an additional vector. it's not hard to see how a bridging service provides a single point of compromise and is a high value target compared to a million independent endpoints it is literally a step back towards the centralized unencrypted messenger model say what you will about the centralized e2e model, but you can't argue that the previous situation was better.
  - 5y ago

Arathorn 5y ago

(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.

teekert 5y ago

I won't use it for signal indeed, for whatsapp though... can't wait to throw it of my phone!! I didn't dive into it, but can you also self-host this? Looking forward to some docker-compose snippets in that case :)

stryan 5y ago
All the bridges (and the matrix server itself of course) are self-hostable.
broodbucket 5y ago
Here you go: https://docs.mau.fi/bridges/go/whatsapp/setup/docker.html https://docs.mau.fi/bridges/go/whatsapp/setup/docker.html Element One uses a modified mautrix-whatsapp, which means that your phone needs to be connected to the internet for the bridge to work - so you can't quite throw it off your phone. I don't have to regularly open the app or anything, though.
- teekert 5y ago
  Hmm, ok, but I could keep it on a spare, empty, old phone at home then perhaps. Still, would have been nice to get rid of it entirely, but I see how that is impossible indeed.
  - broodbucket 5y ago
    Spare phone method should work, I've barely used whatsapp so I'm not sure if it needs a SIM after setup.

ergl 5y ago

For all you know your Signal contacts are using a CLI client and then forwarding the messages through SMS to their feature phones :^)

dane-pgp 5y ago
If you believe that, then I have a bridge to sell you. :^)

phicoh 5y ago

In theory, signal could work with matrix people to support bridging with e2e encryption. But as far as I know, signal wants to be walled garden. So then it is expected that people create work arounds.

pkulak 5y ago

> I like knowing that when I message someone on Signal, it's for their eyes only. That's not how it works at all. E2E encryption only guarantees that your message is securely delivered to the other party, not that the other party can't do as they please with it. Signal messages are still stored in plain text on the end devices. They can still be backed up to the cloud (when I used Signal, all my chats were). Hell, photos/screenshots can still be taken of the app. If you want total security, you have to trust the delivery AND the end user. Bridging doesn't really change any of that.

freeopinion 5y ago

If privacy mattered that much to you, you wouldn't depend on Signal to encrypt your messages. You would encrypt them before handing them to Signal. So you should have an encrypted message that you hand to Signal. Signal encrypts it again and hands it to the bridge. Eventually, whether at the bridge or at the other end or wherever, something decrypts the Signal message. Then the person you are communicating with applies the final decryption outside of Signal, Matrix, or whatever. If this sounds terribly inconvenient to you, perhaps privacy is not as important as you claim. Security and convenience are almost always in conflict.

grassjumper 5y ago
This is like saying "If you don't sweep the bathroom for bugs/cams, you don't really care about privacy. Why do you bother closing the door"
idrios 5y ago
This is a very all or nothing mentality. It's also kind of like saying you should put locks on your locks. Signal's core reason for existing is that it puts a focus on privacy. They say this all over their homepage [0]. One of the founders of WhatsApp donated $50M to Signal [1] out of regret for how WhatsApp shifted away from privacy after being acquired by Facebook. The entire project is freely visible to anyone on github [2]. They've made it so even if you don't trust their servers, you can set up your own server and clone your own android/ios app, change some settings and have everything hosted yourself. There's no reason not to expect Signal to maintain the focus on privacy that they've put in thus far. [0] https://www.signal.org/ https://www.signal.org/ [1] https://www.wired.com/story/signal-foundation-whatsapp-brian-acton/ https://www.wired.com/story/signal-foundation-whatsapp-brian... [2] https://github.com/signalapp https://github.com/signalapp
- freeopinion 5y ago
  For most people, privacy is a nice-to-have thing. When it's just nice to have, Signal checks that box. If your life depended on it, you would be foolish to depend solely on Signal. How nice it is that encryption has emerged from the dark corners of life and death to become a fashion accessory. But for those that still exist in the world beyond fashion, your criticism seems naive.

barbazoo 5y ago

I got so excited for this until I read that, too. I wish there wasn't fragmentation like there is now but MITMing all my comms is definitely not a smart choice if I chose any of the comm systems it bridges based on privacy.

deleted 5y ago

[deleted]

ElijahLynn 5y ago

Very good point on not wanting this to take off so that you know if you send it to someone, it is for their eyes only. It does seem like since both Signal and Matrix are open source, including the servers, that there should be a path to let one a Signal user know if they are sending it to a Matrix bridge and the encryption is no more. Also worth noting is that you do need to trust the person on the other end for Signal to have a chance at working, e.g. they can take screenshots or real camera pictures of the messages. So establishing trust with the recipient is rule #1, and this should go for if they are using a Matrix bridge with Element One too.

grassjumper 5y ago
There's a difference between malice and ignorance, though. My mom in her 70s is using Signal, and I don't think I can blame her for not realizing the vulnerability. I doubt most people will read the Element webside that carefully.

mindslight 5y ago

So then advocate for Signal to fully support third party clients, so that such functionality can be widely supported by multi protocol clients (ala pidgin) rather than needing centralized non-E2E bridges to cope with the administrative overhead of maintaining interoperability.

zuck9 5y ago

Been using https://texts.com https://texts.com — they preserve E2E for Signal/WhatsApp.

lvs 5y ago
Um, how do they do that? > All integrations were implemented in-house using the Texts Platform SDK. The SDK will be open sourced at a later date. Seems like a big nope.
- zuck9 5y ago
  https://texts.com/privacy https://texts.com/privacy says: > Messages, contacts, auth credentials, account information never touch Texts servers. > Your messages are sent directly to the messaging platforms. > All end-to-end encryption is preserved when the platform supports it. > Texts is a client and works like the official app. Apparently all the code runs on the user's device.

toastal 5y ago

This reminds me how absurd it is that OSS projects are bridging Matrix, Discord, and IRC. These all have vastly different ToS and forms of encryption and user privacy. By doing this you can be taking an encrypted message on Matrix and implicitly agree to the ToS and reposting their message to something closed-source and with sketchy privacy like Discord, which defeats the purpose on why one would choose Matrix.

ymolodtsov 5y ago

Come on. E2E encryption is about transmitting the content in transit and in the cloud (if there's a cloud). After people receive your text they can do anything with it.