> 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.
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.
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/ )
> 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?
we ran our own XMPP server for over 10 years using the "off the record" plugin for end to end encryption. Development seem to basically stop on open chat clients a few years ago and everything started getting crufty. (I see Pidgin dev has apparently picked back up again to some extent, as has Adium, to a much lesser extent).
"off the record" mostly worked ok, between Pidgin users, but failed with other clients.
A couple of OMEMO plugins came along but making them work (and keeping them working) was a continual drain - and we're only a small team with only 2 operating systems (Linux and OSX)!
My hunch is that enough people just moved to things like Whatsapp and Slack etc that developers were no longer using chat clients they could hack on. People stopped being able to scratch their itches.
Not to mention lack of any/decent XMPP client support for syncing histories between multiple clients, or handling inline images and things. All that modern stuff people expect.
Things like Mattersmost tried to fit in here but we just didn't get along with them.
Eventually Element/Matrix matured enough and while it was far from perfect, it worked and we sadly finally gave up on XMPP.
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.
Encryption fan here, bridging is one more avenue for failure, is why I won't buy in. Security is about odds, and nothing is 100% safe. I'm pretty sure signal is way better than anything I could come up with, so I choose it.
> 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.
As someone who used trillian, you should recognize that you're likely to need to follow someone to a new trendy messaging service within a few years, regardless of an aggregator taking off.
> why would you trust ANY 3rd party with your so sensitive data instead of running your own service?
Because end to end encryption means you don't have to trust a third party? The channel goes out of the equation, at least with reference to the content of your messages. Metadata is definitely handled differently by different services but that's a question of threat model.
I wrote a bridge between signald and prosody (without spectrum) so I can use xmpp clients with signal. Async python, only non-standard library dependency is slixmpp. It's working well.
> These bridges are actually just an intermediate step. Since Matrix itself is an amazing chat network, eventually as more people start using bridges on Matrix, they’ll notice that their friends are already on Matrix, eliminating the need for bridges gradually over time.
> I really believe that the world will be a better place when everyone is in the Matrix. Matrix is the non-proliferation treaty of chat.
I dont have a PhD in crypography and am not sure I will do a good enough job in covering even potential mid-level vulnerabilities. I still care about privacy and so use Signal.
The point of encryption in the first place is to allow an untrusted transport. If you trust the transport, you don't need encryption.
OMEMO nor XMPP provide trusted transport.
Perhaps the point you are reaching for is that encryption and transport should be different parties. The message should be encrypted before you hand it to the Western Union agent. After that, the decision between Western Union, Union Pacific, or Pony Express hinges on other concerns.
Because your own service is not an alternative if you actually need to secure-message others because of the line of work you're in, or the regime you're under. The idea that "just do it yourself" is more secure than a company that can't just be walked into and have their computers taken without it causing a huge problem for everyone from your mom to heads of state is a bit naive.
Not sure if it's still around, but bitlbee for a long time provided an IRC gateway for almost every chat protocol around at the time (including following Twitter feeds, and Google/Facebook chat via xmpp when they still supported it)
Exactly - someone could be running a (the?) third-party Signal client, or they could be intercepting the Google push notifications that Signal sends using one of those Play Services compatibility layers, or they could do one of the low-tech things of showing their device with your messages on it to someone else in-person.
Although, to be fair, all of those things are far more difficult than using Element One, so there's an argument to be made about reasonable expectations and the actual likelihood of your messages being private...
(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 :)
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
If privacy is truly important to you, then you'll manually encrypt messages in your head using a one-time pad. Can't trust any program you didn't write yourself, including the compiler! /s
> Security and convenience are almost always in conflict
I think this is less true than people tend to think. See e.g. Signal/WhatApp rolling out relatively seamless E2EE to billions of people -- that was hard to imagine just a few decades 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)
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.
> 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.
It's worth remembering again why we don't do this. Even if you fully trust whoever is running the MITM server, being that it's MITMing all of your comms, and it's on a server so it's actually a lot of people's comms, it's a massively tempting target for all sorts of bad actors. Plenty of governments and criminal gangs would just love to compromise that for all sorts of reasons. Odds are one of them will eventually.
For all you know, someone else on the server is a high-value target for somebody, and if they compromise the server to get their comms, they may not be very picky about what happens to the private communications of everyone else on that server.
It is a service, because the bridge is a software that need to be keep operational 24/24h and sometimes this is not so trivial (if I don't get wrong WA need an Android emulator running).
Of course the protocols Pidgin bridged were only used for real-time communication, rather than for leaving messages which could be attended to (or delivered) later.
> I see the same thing here. While it's interesting, I'm failing to see what the use case is. What's the niche that needs this solved in a big way?
I used Pidgin a lot. I always found it very convenient to have everything in one place and UI. Better one client than MSN + AOL + ICQ + IRC + Yahoo! + XMPP.
In the last few years I haven't used it much, but that's because it just doesn't support the popular messaging apps of the day (or maybe it now does, I haven't checked in a while).
Also, as others have pointed out, Pidgin is not and never has been a "service", it's just a library (libpurple) that implements various protocols, with Pidgin as the GUI (they also make Finch, a TUI).
I thought about all that libpurple did back then, including OTR encryption that worked perfectly fine with others.
These days I think that most services try to make money with stuff that was built decades ago already, and they're just keeping the reinventing cycle spinning.
Anyone remember the franz app [1] ...which finally led to the hardfork of ferdi? [2] I feel that element one is franz all over again.
> Back in the day before the rise of Facebook, there was an open source service that combined all the popular messaging protocols
It was not a not a service which was always on and synced between units.
It was a client you had to run on your machine and keep connected. And it obviously didn’t roam.
Pretty much an apples to oranges comparison.
Matrix and Element aims to bring all those things you mention to a single protocol, to which you can connect any client you like, on any device you like, and roam as you like with all your clients always in sync.
It’s what Pidgin used to deliver, levelled up and connected to the “modern” (read: closed) IM-silos the majority of people are using.
It’s definitely different and it’s definitely interesting.
Back in the day and for a little while platforms companies thought to at least have a common language (xmpp). Then they thought it would be a better idea if we all had 10 different apps on our phones for text messages.
There's no reason for standardization and interoperability not to be forced on these companies.
When you sent a physical letter you have to follow some standards on the envelope addresses, when you make a phone call to the other side of the world people can still hear your voice, same for sms, same for email, but apparently sending a string of text via internet in a standard protocol is an unsolvable problem.
Companies must be forced to implement a subset of their features as part of some interoperability standard. The rest they can keep for their competitive advantage. I can't recall any industry who ever volunteered for this. Car makers didn't, telecoms didn't, software makers won't. No one did and they all exploited their users/customers to the fullest until they were forced to do so.
> While it's interesting, I'm failing to see what the use case is.
I'm unclear if it supports relay mode, but if so, you can invite Matrix, Signal, and WhatsApp users into the same group chat! [1] Edit: Relay mode is not currently supported in Element One, I tried it out. I contacted support and they said "we will discuss this internally and possibly enabled it later"
I've been using this on my self-hosted version of the bridge and it does wonders for those friends who are on Signal but don't want to try another app.
Also, a lot of people just don't want to swap between apps for direct messaging people on different services. This means you can use any Matrix compatible app [2] to chat with anyone on Matrix/WhatsApp/Signal/Telegram.
The Glory days, when both Google Talk and Facebook used XMPP, and you can run one client to chat with all of them. We ran Prosidy and Pidgin at my old job, and it worked great for our company chat server.
I think this is more like XMPP transports in that is is centralized at the server. Such things tended to end up centralized as it is a lot of work to keep up with the efforts of the people running the services to remain incompatible with the bridges. These days few XMPP servers bother with transports to commercial IM services. I suspect the same thing will happen in the Matrix case.
Now there is another open source alternative: Matterbridge (https://github.com/42wim/matterbridge) connecting: Mattermost, IRC, Gitter, XMPP, Slack, Discord, Telegram, Rocketchat, Twitch, SSH-chat, Zulip, WhatsApp, Keybase, Matrix, Microsoft Teams, NextCloud, Mumble, VK and more.
The use case is simple: instead of using plethora of IM apps, have all your conversations in one place.
Agreed, not sure what the use case is. It’s super trivial to switch between messaging apps and it’s not often that you are having a conversation with multiple people over multiple apps at once and even then it’s still manageable.
The only thing I can think of is people who do not wish to have the app installed for privacy / open source reasons.
- Not tech-savvy and easily confused by keeping 6 different messengers around.
- People for whom multiple clients becomes a cognitive burden.
- Waste of storage space, memory and CPU power that those (hugely bloated, most of the time) clients incur, especially on mobile devices.
- People like me, with diminished executive functioning capacity, who are fucking tired of bad ergonomics of all those clients together and each individually, and who'd prefer a single, consistent, ergonomic and powerful UI to manage the torrent of messages they receive.
I really love libpurple plugins for pidgin and how they can be combined.
For example, I was able to communicate using OTR on vk.com (russian facebook clone). Probably other niche messaging plugins work with OTR too (it's just plaintext messages, after all).
Pidgin is an IM client, not a service. A service would be something like XMPP servers (Google Talk used to be one and even federated until it went sideways).
Brief history: when Hangouts was going away and Google Chat coming in, I pitched Matrix to my friends as a better alternative that didn't require unique phone numbers, awkward desktop limitations, and a better federated future. We stuck with Google Chat because inertia and networks suck that way.
I revisited the instance I had setup and got the mautrix-googlechat bridge working. It's pretty nice but one friend lamented that he did not have the technical skills to self-host such a thing. And here comes this announcement! Sadly, there is a major hurdle: neither Google Chat nor SMS/GVoice are listed here and those are the major protocols that my social group uses.
At the same time, my social group is conservative in adopting new core technologies and wary of cloud lock-in for critical roles (Google being both an unfortunate anchor and precipitator of that). I'm not sure adding those protocols would tip the balance.
The fact that content sent to signal and Whatsapp resides unencrypted at the matrix homeserver makes this product completely useless to me.
I don't think I want to sacrifice the security for having all my chats in one place.
If they can fix that I might reconsider.
They already reverse engineered the Whatsapp protocol. I see little reason why it can't live in the client? I don't really follow why they move the bridge to the homeserver.
> They already reverse engineered the Whatsapp protocol. I see little reason why it can't live in the client? I don't really follow why they move the bridge to the homeserver.
Matrix bridges are rather complex. They rely on a combination of private APIs (WhatsApp), Chrome extension scraping (LINE), bots (Telegram), mobile clients (Android SMS), and jailbroken iPhones (iMessage).
This is all very interesting from a technological perspective but it sounds incredible brittle. Do I break any terms with these 3rd parties by paying Matrix to scrape them?
So the encryption is there so that you can't access your own data (and migrate to a competing app/service), rather than to protect your privacy. I kind of ran into this issue myself when I was helping a family member move to iPhone. Since Whatsapp uses Drive on Android and iCloud on iOS, there was no way to transfer the data.
I wonder if you can get them via one of those data access requests?
I'm happy to see that element found another potential revenue stream, but will people pay the 5$/month to unify their messaging?
I don't know about others but it's not that much of a pain point for me, and I'm using all of the apps they mention - WhatsApp, Signal, Telegram as well as few others like IRC and Discord.
I have nowhere near the same reach and marketing capacity as Element, but if my experience running a managed hosting service [0] for Matrix (and other messaging/social media services) is anything to go by: individuals really don't care enough about that to the point of paying $5/month, but there is a growing opportunity for business that want to have some control over their communications.
These bridges can be amazing if you want to have a chatbot, or a support desk that can put all their conversations in one place, etc, but to replace the mainstream apps it is too much of a tall order. At the moment the mobile clients have so many bugs that makes it hard even for me to go when offering support for my "customers", which at this point is just the couple dozen friends and family that I managed to rope into it. They don't even have feature parity with any of the competitors, so for end-users it's just easier to switch apps on their phone depending on who they want to talk and their will have a better experience doing so.
I still use and support Matrix, but their clients still need to improve a lot if they ever hope to reach mainstream. I am focused now on another project [1], but when/if I ever get to work back on communick, I will pivot away from end-users and into SMB.
Exactly. The Element UI isn't the best selling point of Matrix right now and that would be a requirement for someone to switch from all those apps to Element.
Does anyone know what this product is based on? Is it just a ready-made image with all the bridges preconfigured (and prerequisites such as a small android vm for a viable whatsapp bridge), or has there been some evolution on the existing package? Is there documentation on what was done to achieve this?
Purely on the content of the article: Given that the messages are not stored encrypted locally and that this service is connected to the US, I do not see how it can be viable for the privacy-conscious.
> Purely on the content of the article: Given that the messages are not stored encrypted locally and that this service is connected to the US, I do not see how it can be viable for the privacy-conscious.
Matrix chats (direct and group) are E2E by default. There is no bridge that will let you keep E2E encryption between Signal/WhatsApp and another service - it has to be broken somewhere. I believe Element is a UK company.
> However, in addition to being a fast, snappy Matrix account, it also comes with unlimited personal bridging to Whatsapp, Signal and Telegram thanks to mautrix-whatsapp/signal/telegram!
> There is no bridge that will let you keep E2E encryption between Signal/WhatsApp and another service - it has to be broken somewhere
Yes, but it doesn't have to be stored plain on a completely untrusted (because again, the company touches the US - that is an ideologically privacy-hostile space) server. This makes data collection much easier, including data collection of data in the past (as opposed to only communication from a certain point in time, as with an ongoing tap of the machine itself).
From there Terms of Service: Where you read 'Element' or 'we' or 'us' below, it refers to Element, a trading name of New Vector Ltd., its French subsidiary: New Vector SARL, its U.S. subsidiary: Element Software Inc, and their agents. https://element.io/terms-of-service
I've been running the Signal bridge for a couple of months and it seems pretty unstable. Sometimes it stops delivering messages and I have to restart either signald or the bridge. At other times, it broke completely and started working again only after a couple of days, when I updated signald.
I haven't tried the WhatsApp bridge yet because it needs to go through my phone or an Android VM. WhatsApp recently announced support for using WhatsApp Web without the need to have your phone online, but I don't think it's available for everyone yet.
I've just signed up (after reading this message). My hope is that as a paid service effort will be made to make it reliable (through development, configuration, whatever). Having some users paying for it should hopefully make issues much more visible (through complaints to support if nothing else!).
That's a bummer. I was excited about running a home instance to bridge my (many) chat platforms. To me the point of such a thing is you can set it up and mostly leave it alone, so if it needs frequent fiddling it is mostly not fit for purpose.
I've had the opposite experience. I've run a signal bridge for ~6 months with 0 interaction at all from me. This is the mautrix signal bridge, pantalaimon, and Synapse.
It is not, according to this comment[0] "although Element One doesn’t use slavi’s ansible playbooks but instead the Element Matrix Services hosted infra"
So this service consists basically in paying to compromise E2EE, adding an attack vector, storing my otherwise encrypted conversations on centralised servers, using an arguably worse client with less features just for the convenience of not having to open 3 separate apps? Who is this for?
I just have a really hard time understanding who this is targeting. If you're on average more willing to sacrifice privacy over ease of use, you're very likely not using Signal or Matrix anyway. So if you're not, but you're using both WhatsApp and Telegram, how is using two apps a big enough problem to set up a third one?
Even if we disregard that, I can honestly say that I don't think using four separate apps is a problem. I don't even think using ten different apps is a problem, because it's mostly transparent to the user anyway. You get (configurable) notifications from all of them when you need to care about something, and the "sharing" feature on both iOS and Android these days is normally smart enough to figure out who, or at least which app, you want to share something to -- so for me this "multi app confusion" is already pretty well solved on an OS level, at least on mobile.
I think "on average more willing to sacrifice privacy over ease of use" is probably a reasonable description of me. I'm not a fan at all of FB though, I have absolutely no trust in them at all. As such, I tried to get my world moved from WhatsApp to Signal. Inevitably I didn't succeed completely (although more than I expected) but now I'm split between those two. Plus I have some people who only communicate via FB messenger, and a few friends on Discord.
To message someone I first have to remember which platform they prefer and then find it in my folder of chat apps. It's not an insurmountable problem obviously, but it does add friction. If I can have that all in one place, cross-platform with a decent UX then that's definitely worth $5 a month to me, plus all the bonuses:
* I am actually moving in a more privacy focused direction. Yes I understand the caveats with bridges, but being on Matrix means that I can start a (slow) process of moving my interactions onto it
* I don't have to worry about backing up my Signal messages (which is a pain to have automatically sync 'offsite' from your phone)
* I can use it as my IRC client (with message history hanging around), etc.
Let me put it another way - I've wanted to be on Matrix for a while but haven't quite managed it. I like the decentralised philosophy, both from a technical perspective and a privacy one but every time I've signed up it hasn't been worth it and/or it's too painful. This gets it over the hump for me (if it's as promised).
I constantly miss messages on TG, WA and Signal because I forget to check them regularly. It also really irks me that my conversations are trapped in those platforms without a public API, and I’d like to gather them together on an open platform like Matrix, and access them from every/any Matrix client i choose. Hence the use case for Element One :)
Why do you need to “check them” in the first place though?
And yes, I can understand that for some people the inability to easily transfer and collect those conversations is a problem, but for many people (imo probably more people) the ephemeral nature of these messages is a feature, not a problem to be solved. At least that’s why I use Signal over Messenger, for example.
If I can enhance understanding on any level, FYI FWIW I will sign up for this likely.
1. Yes - In this context I prefer convenience over impractical/unrealized encryption. (Not privacy - I find Whatsapp, which hinges on my personal private phone number, far less "private", than other traditional messenger apps which I can sign up for anonymously; and for my use cases it's not a realized encryption, as people I talk to have no concept of security and I should assume anything I send to them has been scrubbed by malware and any other apps they've intentionally installed and agreed to).
2. Dozen apps are annoying impractical and I darn tooting well do Not have their notifications enabled. I'll agree that Android sharing is awesome; my experience with iPhone sharing has been Far more limited.
3. Whatsapp is darn near impossible to effectively use multi-device. If this will let me chat to my in-laws (who are stuck on Whatsapp not for any privacy or encryption reasons but because "everybody uses it") from comfort of my computers and keyboards, reliably, then this is a shut up & take my money proposition.
3a. Anybody about to comment "But whatsapp works on computers", see my other replies:)
Readit News
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.
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://gitlab.com/nicocool84/spectrum2_signald , but sadly 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/ )
Because trust is not a binary value and I don't have the time to do literally everything myself
we ran our own XMPP server for over 10 years using the "off the record" plugin for end to end encryption. Development seem to basically stop on open chat clients a few years ago and everything started getting crufty. (I see Pidgin dev has apparently picked back up again to some extent, as has Adium, to a much lesser extent).
"off the record" mostly worked ok, between Pidgin users, but failed with other clients.
A couple of OMEMO plugins came along but making them work (and keeping them working) was a continual drain - and we're only a small team with only 2 operating systems (Linux and OSX)!
My hunch is that enough people just moved to things like Whatsapp and Slack etc that developers were no longer using chat clients they could hack on. People stopped being able to scratch their itches.
Not to mention lack of any/decent XMPP client support for syncing histories between multiple clients, or handling inline images and things. All that modern stuff people expect.
Things like Mattersmost tried to fit in here but we just didn't get along with them.
Eventually Element/Matrix matured enough and while it was far from perfect, it worked and we sadly finally gave up on XMPP.
As someone who used trillian, you should recognize that you're likely to need to follow someone to a new trendy messaging service within a few years, regardless of an aggregator taking off.
Because end to end encryption means you don't have to trust a third party? The channel goes out of the equation, at least with reference to the content of your messages. Metadata is definitely handled differently by different services but that's a question of threat model.
> These bridges are actually just an intermediate step. Since Matrix itself is an amazing chat network, eventually as more people start using bridges on Matrix, they’ll notice that their friends are already on Matrix, eliminating the need for bridges gradually over time.
> I really believe that the world will be a better place when everyone is in the Matrix. Matrix is the non-proliferation treaty of chat.
https://medium.com/@ericmigi/the-universal-communication-bus...
OMEMO nor XMPP provide trusted transport.
Perhaps the point you are reaching for is that encryption and transport should be different parties. The message should be encrypted before you hand it to the Western Union agent. After that, the decision between Western Union, Union Pacific, or Pony Express hinges on other concerns.
Then don't. I have none of those things save for IRC. I get all my work done and live a full life.
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.
I.e. the bridge is a vulnerability that enables man in the middle attacks.
Although, to be fair, all of those things are far more difficult than using Element One, so there's an argument to be made about reasonable expectations and the actual likelihood of your messages being private...
But as far as I know, signal wants to be walled garden. So then it is expected that people create work arounds.
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 :)
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.
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.
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.
Quick question, is the code for the bridge opensource?
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.
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.
I didn't dive into it, but can you also self-host this? Looking forward to some docker-compose snippets in that case :)
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.
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.
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.
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.
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/ [1] https://www.wired.com/story/signal-foundation-whatsapp-brian... [2] https://github.com/signalapp
> Security and convenience are almost always in conflict
I think this is less true than people tend to think. See e.g. Signal/WhatApp rolling out relatively seamless E2EE to billions of people -- that was hard to imagine just a few decades ago!
Deleted Comment
Deleted Comment
> 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.
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.
It was called Pidgin[0], and it never got particularly big.
I see the same thing here. While it's interesting, I'm failing to see what the use case is. What's the niche that needs this solved in a big way?
[0] https://www.pidgin.im/
The main difference between this and Pidgin seems to be that you pay a monthly fee for someone to man-in-the-middle all your communications.
All Matrix homeservers and bridges are open source. I self host some of them myself. Have been doing that long before Element One was a thing.
For all you know, someone else on the server is a high-value target for somebody, and if they compromise the server to get their comms, they may not be very picky about what happens to the private communications of everyone else on that server.
I used Pidgin a lot. I always found it very convenient to have everything in one place and UI. Better one client than MSN + AOL + ICQ + IRC + Yahoo! + XMPP.
In the last few years I haven't used it much, but that's because it just doesn't support the popular messaging apps of the day (or maybe it now does, I haven't checked in a while).
Also, as others have pointed out, Pidgin is not and never has been a "service", it's just a library (libpurple) that implements various protocols, with Pidgin as the GUI (they also make Finch, a TUI).
These days I think that most services try to make money with stuff that was built decades ago already, and they're just keeping the reinventing cycle spinning.
Anyone remember the franz app [1] ...which finally led to the hardfork of ferdi? [2] I feel that element one is franz all over again.
[1] https://meetfranz.com
[2] https://github.com/getferdi/ferdi
It was not a not a service which was always on and synced between units.
It was a client you had to run on your machine and keep connected. And it obviously didn’t roam.
Pretty much an apples to oranges comparison.
Matrix and Element aims to bring all those things you mention to a single protocol, to which you can connect any client you like, on any device you like, and roam as you like with all your clients always in sync.
It’s what Pidgin used to deliver, levelled up and connected to the “modern” (read: closed) IM-silos the majority of people are using.
It’s definitely different and it’s definitely interesting.
There's no reason for standardization and interoperability not to be forced on these companies.
When you sent a physical letter you have to follow some standards on the envelope addresses, when you make a phone call to the other side of the world people can still hear your voice, same for sms, same for email, but apparently sending a string of text via internet in a standard protocol is an unsolvable problem.
All my friends have since moved to Discord now which is way nicer than any other user experience.
I'm unclear if it supports relay mode, but if so, you can invite Matrix, Signal, and WhatsApp users into the same group chat! [1] Edit: Relay mode is not currently supported in Element One, I tried it out. I contacted support and they said "we will discuss this internally and possibly enabled it later"
I've been using this on my self-hosted version of the bridge and it does wonders for those friends who are on Signal but don't want to try another app.
Also, a lot of people just don't want to swap between apps for direct messaging people on different services. This means you can use any Matrix compatible app [2] to chat with anyone on Matrix/WhatsApp/Signal/Telegram.
[1]: https://github.com/mautrix/docs/blob/master/bridges/python/s...
[2]: https://matrix.org/clients/
https://trillian.im/https://www.miranda-ng.org/en/
The use case is simple: instead of using plethora of IM apps, have all your conversations in one place.
The only thing I can think of is people who do not wish to have the app installed for privacy / open source reasons.
- Not tech-savvy and easily confused by keeping 6 different messengers around.
- People for whom multiple clients becomes a cognitive burden.
- Waste of storage space, memory and CPU power that those (hugely bloated, most of the time) clients incur, especially on mobile devices.
- People like me, with diminished executive functioning capacity, who are fucking tired of bad ergonomics of all those clients together and each individually, and who'd prefer a single, consistent, ergonomic and powerful UI to manage the torrent of messages they receive.
[0] https://latenightlinux.com/late-night-linux-extra-episode-32...
For example, I was able to communicate using OTR on vk.com (russian facebook clone). Probably other niche messaging plugins work with OTR too (it's just plaintext messages, after all).
https://github.com/petermolnar/awesome-pidgin-plugins
Real Scotsmen used bitlbee and irssi to enable their IRC addiction, long after everyone else had moved on to harder stuff.
:)
https://apps.kde.org/kopete/
Brief history: when Hangouts was going away and Google Chat coming in, I pitched Matrix to my friends as a better alternative that didn't require unique phone numbers, awkward desktop limitations, and a better federated future. We stuck with Google Chat because inertia and networks suck that way.
I revisited the instance I had setup and got the mautrix-googlechat bridge working. It's pretty nice but one friend lamented that he did not have the technical skills to self-host such a thing. And here comes this announcement! Sadly, there is a major hurdle: neither Google Chat nor SMS/GVoice are listed here and those are the major protocols that my social group uses.
At the same time, my social group is conservative in adopting new core technologies and wary of cloud lock-in for critical roles (Google being both an unfortunate anchor and precipitator of that). I'm not sure adding those protocols would tip the balance.
https://www.beeper.com/
I'm just yelling here to take my money, but nobody answers.
I don't think I want to sacrifice the security for having all my chats in one place.
If they can fix that I might reconsider.
They already reverse engineered the Whatsapp protocol. I see little reason why it can't live in the client? I don't really follow why they move the bridge to the homeserver.
Because Whatsapp crushes any client other than their official client. Everyone else is confined to scraping Whatsapp Web.
Matrix bridges are rather complex. They rely on a combination of private APIs (WhatsApp), Chrome extension scraping (LINE), bots (Telegram), mobile clients (Android SMS), and jailbroken iPhones (iMessage).
* Encrypted with a private key which Google have access to.
I wonder if you can get them via one of those data access requests?
I don't know about others but it's not that much of a pain point for me, and I'm using all of the apps they mention - WhatsApp, Signal, Telegram as well as few others like IRC and Discord.
These bridges can be amazing if you want to have a chatbot, or a support desk that can put all their conversations in one place, etc, but to replace the mainstream apps it is too much of a tall order. At the moment the mobile clients have so many bugs that makes it hard even for me to go when offering support for my "customers", which at this point is just the couple dozen friends and family that I managed to rope into it. They don't even have feature parity with any of the competitors, so for end-users it's just easier to switch apps on their phone depending on who they want to talk and their will have a better experience doing so.
I still use and support Matrix, but their clients still need to improve a lot if they ever hope to reach mainstream. I am focused now on another project [1], but when/if I ever get to work back on communick, I will pivot away from end-users and into SMB.
[0] https://communick.com
[1] https://hub20.io
As one data point, I probably would pay $5 a month just for that. Combining that with all the other Matrix goodness is a bonus.
Purely on the content of the article: Given that the messages are not stored encrypted locally and that this service is connected to the US, I do not see how it can be viable for the privacy-conscious.
Matrix chats (direct and group) are E2E by default. There is no bridge that will let you keep E2E encryption between Signal/WhatsApp and another service - it has to be broken somewhere. I believe Element is a UK company.
The blog post on This Week In Matrix states it uses modified versions of the open source (and self hostable) Mautrix bridges which are primarily built by tulir [2] of Beeper [3]: https://matrix.org/blog/category/this-week-in-matrix#element...
> However, in addition to being a fast, snappy Matrix account, it also comes with unlimited personal bridging to Whatsapp, Signal and Telegram thanks to mautrix-whatsapp/signal/telegram!
[2]:https://github.com/tulir [3]: https://www.beeper.com/
Yes, but it doesn't have to be stored plain on a completely untrusted (because again, the company touches the US - that is an ideologically privacy-hostile space) server. This makes data collection much easier, including data collection of data in the past (as opposed to only communication from a certain point in time, as with an ongoing tap of the machine itself).
> The blog post on This Week In Matrix
Thank you :)
So UK, French and US.
Dead Comment
I haven't tried the WhatsApp bridge yet because it needs to go through my phone or an Android VM. WhatsApp recently announced support for using WhatsApp Web without the need to have your phone online, but I don't think it's available for everyone yet.
It's very likely based on https://github.com/spantaleev/matrix-docker-ansible-deploy
[0]: https://news.ycombinator.com/item?id=29000978
Even if we disregard that, I can honestly say that I don't think using four separate apps is a problem. I don't even think using ten different apps is a problem, because it's mostly transparent to the user anyway. You get (configurable) notifications from all of them when you need to care about something, and the "sharing" feature on both iOS and Android these days is normally smart enough to figure out who, or at least which app, you want to share something to -- so for me this "multi app confusion" is already pretty well solved on an OS level, at least on mobile.
I think "on average more willing to sacrifice privacy over ease of use" is probably a reasonable description of me. I'm not a fan at all of FB though, I have absolutely no trust in them at all. As such, I tried to get my world moved from WhatsApp to Signal. Inevitably I didn't succeed completely (although more than I expected) but now I'm split between those two. Plus I have some people who only communicate via FB messenger, and a few friends on Discord.
To message someone I first have to remember which platform they prefer and then find it in my folder of chat apps. It's not an insurmountable problem obviously, but it does add friction. If I can have that all in one place, cross-platform with a decent UX then that's definitely worth $5 a month to me, plus all the bonuses:
* I am actually moving in a more privacy focused direction. Yes I understand the caveats with bridges, but being on Matrix means that I can start a (slow) process of moving my interactions onto it * I don't have to worry about backing up my Signal messages (which is a pain to have automatically sync 'offsite' from your phone) * I can use it as my IRC client (with message history hanging around), etc.
Let me put it another way - I've wanted to be on Matrix for a while but haven't quite managed it. I like the decentralised philosophy, both from a technical perspective and a privacy one but every time I've signed up it hasn't been worth it and/or it's too painful. This gets it over the hump for me (if it's as promised).
And yes, I can understand that for some people the inability to easily transfer and collect those conversations is a problem, but for many people (imo probably more people) the ephemeral nature of these messages is a feature, not a problem to be solved. At least that’s why I use Signal over Messenger, for example.
1. Yes - In this context I prefer convenience over impractical/unrealized encryption. (Not privacy - I find Whatsapp, which hinges on my personal private phone number, far less "private", than other traditional messenger apps which I can sign up for anonymously; and for my use cases it's not a realized encryption, as people I talk to have no concept of security and I should assume anything I send to them has been scrubbed by malware and any other apps they've intentionally installed and agreed to).
2. Dozen apps are annoying impractical and I darn tooting well do Not have their notifications enabled. I'll agree that Android sharing is awesome; my experience with iPhone sharing has been Far more limited.
3. Whatsapp is darn near impossible to effectively use multi-device. If this will let me chat to my in-laws (who are stuck on Whatsapp not for any privacy or encryption reasons but because "everybody uses it") from comfort of my computers and keyboards, reliably, then this is a shut up & take my money proposition.
3a. Anybody about to comment "But whatsapp works on computers", see my other replies:)