> 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.
For the past two years; I've been using Conversations (Android), Dino (Linux), and friends of mine have been using Gajim (Windows), Monal/Siskin (iOS).
All of these work fine with OMEMO (the iOS ones gained better OMEMO and push support in the past few months) and message history retrieval between clients. Gajim doesn't do inline images, but the rest do.
I occasionally use profanity as a console client and that recently had message archive support land in Git.
So, yeah, no idea what you mean by developers giving up - if anything, the ecosystem has greatly improved (minus group OMEMO on iOS).
Maybe not developers in general, but development of Pidgin certainly stalled, which is why I stopped using it. Too man features not implrmnted in XMPP and no working support for e.g. Skype.
I didn't say developers "gave up", but even as of 2019 it didn't seem like things were moving forward in any meaningful way.
Even just for OMEMO support, we all had to compile a plugin for libpurple/Pidgin, and it didn't even have full UI support so was very difficult to use when things didn't work automatically.
We used a gajim but iirc, to get OMEMO support we had to compile that too.
But I'm truly glad to hear the ecosystem has improved - I would have much preferred to have stuck with XMPP. But in 2019/2020, Matrix offered all this and more and worked very well. It was impossible to make the case for us to stay on XMPP.
I use Conversations and Dino daily, they're awesome. When I'm stuck on MacOS or iOS I use BeagleIM and ChatSecure, though Monal looks a little more slick...maybe I should try that.
There are a few options yet for XMPP clients, I have some hope for the ecosystem...!
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.
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.
But Signal is better than Signal over these bridges, and it's easy too. Just because you don't want to run your own service doesn't mean you have to choose a poor option over a pretty good one.
But not everyone I talk to is on Signal. And I don't want to remember which app to open to message a certain person.
What's the difference between Element offering these bridges, people deploying their own bridges or others having 3rd party clients that you can't trust with your E2E encryption?
Nothing makes that better, you're right. I prefer to just remember who uses what and act accordingly, but you choose convenience instead — and both are reasonable choices.
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.
I recently had my internet snapped last month and I did not want reddit to know "last 90 days IP access log" so I had a dormant account and I wrote a post locally, called a friend living overseas and made him login to that dormant account and I dictated the text.
And you want utmost security for your body, which is why you go to the doctor instead of self threat. And also doctors go to other doctors when they are ill.
The sad reality is that things are complex and you probably get suboptimal results trying to do everything yourself, what other spend their lives trying to accomplish the same.
WhatsApp scaled to 1B users with only 50 engineers, but there were 50 people working full time to provide what people think they can provide in their spare time?
Also as the other end of any communication is quite scaring thinking I am communicating securely with someone, but then finding out that their server is compromised because of an out of date library or service.
If you've ever used Docker or deployed an nginx server - then you can very easily deploy a chat server. Pretty much the same thing but over a different protocol.
Server getting compromised - that's largely unimportant with end-to-end encryption through OMEMO. Distros also apply security patches (just keep things up to date).
You do not require 50 engineers to run a chat server for <200 of your friends. In my experience, once you have the software configured and running - it pretty much runs itself.
You're right, it isn't the same. Instructions on how to build a car don't change every week. As a hobbiest I wouldn't trust my life on getting in a car if that was a requirement. There's more in my life than that single hobby that I need to do and I only have so much time.
Why? Specialization is a thing. Not everyone specializes in security. Which let's be real, being an expert in security is really difficult, especially since it's a constantly moving goal post. Unless you're an expert it's probably not a good idea to roll your own.
Also, to run your own service you must specialize in security AND devops. The two thing overlaps a bit, but not 100%. And you must hope that every contact you are talking to has the same knowledge.
so much this - you can make a service 100% secure - by shutting it down. But if you want to stay online and be secure at the same time, there's always some resource tradeoff between the two
If you know a problem is hard and the consequences for doing it wrong are potentially serious, it would be irrational to not consider selecting a well-managed third party solution. Being a hacker doesn't mean being all-knowing and the best hacks are done with the knowledge of human limits (both of the hacker and of the maker of the system being hacked).
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.
Maybe it’s not for you but more for those of us forced onto FB’s WhatsApp and their phone book scanning/uploading by social conventions. This presents a way out without giving up the benefits.
You know people that have the FB app installed. And all their messages and SMS running through the FB app. And you can't get all of them to stop this madness.
Just don't install it. I've never used it. People ask why, I answer that I do not accept the spying in their terms of service. Far more people are sympathetic to that line than you might expect.
If you live in the Netherlands and have young kids in school this really isn't option. It's how kids' parties are arranged, sports schedules are communicated, parents are kept informed about school. And then it is also often the most convenient way to contact any help desk.
The annoying thing is is that WA became the standard for communications when they were not owned by FB and had a privacy focus. This is why I have no qualms abut trying to cheat out of their horrible system.
> 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.
I've seen your project! Congrats, it is very nice.
I stopped fiddling with transports because signald doesn't compile/run on freebsd (some of the java libs behind it rely on native libs which have problems compiling), and for now I've put it aside.
> 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.
I'm pretty sure my server at home is less secure since I'm not a professional security expert. I can recognize that I'm dumb and going to make a lot of mistakes.
The disadvantage of having your server at your home is that you don't know if it's compromised from day one. I may never even find out and just fool myself the entire time.
there is a news by arstechnica that updates by cisco who deny the same but these curbs were imposed and i personally suffered so i am not sure if "have their computers taken without it causing a huge problem for everyone from your mom to heads of state is a bit naive"... even a big company like cisco must bow down and bend rules to a dictatorial country like india.
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)
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.
> 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.
Not even close. I can evaluate the likelyhood of my partner being compromised. I can’t evaluate the likelyhood of a gateway I may not even know about being compromised.
The introduction of these gateways makes the entire system less trustworthy.
Honestly I can’t see how Matrix/Element can stand behind this in good conscience. It is strictly a harm to the goal of enabling private communications. I literally found myself thinking it was a joke when I read it, and I no longer think matrix/element are serious.
> Not even close. I can evaluate the likelyhood of my partner being compromised. I can’t evaluate the likelyhood of a gateway I may not even know about being compromised.
Why? It is your partner that is deciding to use what is essentially a Signal client installed on a remote server controlled by Element. If it is true that you are able to estimate this likelihood for your partner, this fact should already have been accounted for in the calculation.
> This is only true now that Element have introduced this compromised way to access signal.
It's never not been true since Signal is just a protocol which you can use programatically. It's certainly not been true at least since signald became a thing. And Element is not the first one to come out with such an offering (see e.g. Beeper).
That makes as much sense as saying nuclear war was as likely before the Manhattan project as afterwards.
It was always possible to build nuclear bombs. It was just ‘better known’ after they were dropped on Japan.
And in this case “better known” is what is being criticized. It’s one thing for someone who understands how to do so to build their own proxy and take their own risks.
It’s another thing entirely to make a consumer product that does this and normalize the practice.
this is extremely not true. federal authorities can compel the bridge operators to log messages sent over the bridges and disclose them on receipt of a national security letter or other sealed warrant. this is just not the case right now - messages sent between parties on signal cannot be intercepted. that the communication endpoints are vulnerable is and remains true but this creates a new vulnerability in the interlink.
worse:
> currently bridged conversations are not stored end-to-end encrypted in Matrix (they will be in the future)
suggests some kind of re-encryption for storage which appears to resolve the issue but does literally nothing to solve the problem. if the bridges have your keys and can decrypt your messages, you're exposing yourself to attacks on the bridges themselves.
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.
like google and apples notification systems? or the state of whatsapp backups encryption?
whataboutism for sure but i uphold the view that the expectation of privacy from smartphone based internet chat should be very low for tech-literate people.
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...
The messages are encrypted end to end so compromising push notifications doesn't get you anything. That's the problem with this bridge, it adds a new server with access to the unencrypted messages.
come on. can we just drop this end to end encrypted bs on whatsapp atleast ? when you report a message, you allow admins to see the last 3-4 messages. if only you and your receipent is supposed to see the messages, "e2e", how can an admin see them?
While I can't vouch for WhatsApp's implementation of course, the capability could easily maintain e2e encryption by just forwarding those 5 messages directly to WhatsApp admins. E2E just means it gets to your recipient without being exposed on the way. It doesn't mean they can't take and then re-distribute it to others.
That is a slippery slope. Are you SURE WhatsApp doesn't auto forward all communications to itself AFTER the users read them? That too silently so you have no way of knowing
As I said, I'm not vouching for WhatsApp's implementation. What I'm saying is that having the ability to report messages does not mean they're not doing e2e exactly like they say. It doesn't provide any information on that point.
If they were going to look at all your messages, of course, waiting until the end user gets it is somewhat unnecessary, they could just get them straight from the sender since they're both "E's" in the e2e. But that's true of any messaging client. Unless you're inspecting the code and building your own binaries, you either have to choose to trust what they're saying or not (or I guess just don't care if it's not relevant to you). But again, that's not WhatsApp specific.
(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.
>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.
This sounds like a made-up concern.
How do you stop me from screenshotting your convo and posting on twitter, or just copying and pasting from one app to the next?
Those are distinct from my concern. In your scenarios, I have trusted you to keep the conversation secret, and you betrayed that trust.
My concern is about giving messages in an automatic fashion to a third party, which I'm completely unaware of and have no way of making an informed decision about. The third party could be breached (they run an online service, which is much, much easier to attack than some dude's iPhone).
How much do you know about your conversation partner's cyber hygiene? They might leave their phone unlocked at the library or even unknowingly install malware.
All of that is true, and remains true if they're using a bridge service as well. The bridge service is strictly reducing the security of messages.
Look, I'm not up in arms or anything, I just can immediately see a drawback to bridging Signal specifically. There exist many other services (Telegram, Slack, Discord, the list goes on) that can be bridged to Matrix without compromising the security posture in any terrificly meaningful way, IMO. So the idea is great in principle.
> The bridge service is strictly reducing the security of messages.
Perhaps in some sense, yes, but in precisely the same sense that you reduce the security of your messages each time you send a new message, or each time you start a conversation with a new person, or each time any of your contacts reads a message on the train where someone might be looking over their shoulder. None of these things strike me as a meaningful reduction in security, at least in the threat models that are appropriate for most average people (namely where you don't expect to be personally targeted by an attacker with resources).
The Matrix bridge service is compromised (their infra has been successfully attacked before, and other similar platforms have had catastrophic data breaches as well)? That doesn't require a targeted attack, involves complete history disclosure and probably far more metadata than Signal even stores on their servers.
An Element bridge is just a Signal client hosted on Element's infrastructure. Them using an Element bridge is no different than them using an extra device you didn't know about. That device could've well been insecure, or shared by many people, or hosted in the cloud. If you care about this, you should ask.
> Them using an Element bridge is no different than them using an extra device you didn't know about.
It is different in a big way. That extra device would most likely only transit this one user's messages. The Element bridge transits a ton of users and as such is an attractive target for mass surveillance.
> That device could've well been [..] hosted in the cloud.
The capability of self-hosting is very niche. Only technical people could pull that off. Element is working hard to make using this bridge so easy that your grandmother could do it.
I thought I addressed that in my original comment: I _could_ go to each of my contacts and explain why I don't want them to do things like use the cool new Element service with Signal. But 1) I (finally) have a lot of contacts using Signal, so that would be a pain to manage; 2) to me, the entire idea of Signal is that I can pretty much set it and forget it on any relatively-modern smartphone for friends, family, etc. and not have to worry about anything but the biennial phone migration for my mother.
In the end it isn't a huge deal, as most conversations are extremely innocuous, and those I care about I'll take the time to verify. But after all the trouble to proselytize Signal, I get nervous about large public projects that could, in my opinion, strictly reduce the security of my secure messaging system.
> I _could_ go to each of my contacts and explain why I don't want them to do things like use the cool new Element service with Signal. But 1) I (finally) have a lot of contacts using Signal, so that would be a pain to manage; 2) to me, the entire idea of Signal is that I can pretty much set it and forget it on any relatively-modern smartphone for friends, family, etc. and not have to worry about anything but the biennial phone migration for my mother.
Yes, I totally agree that this would be a huge hassle. But what's your proposed alternative? Reaching out to every programmer in the world and convincing them to never write any software that can act as a Signal client? Or pushing for legal prohibition on any non-Signal developers creating software that can act as a Signal client?
Hahaha of course not. I don't really propose an alternative. I'm just lamenting the situation and trying to provide context to the Element CEO about why the original commenter, and people like him, might not be 100% jazzed about the democratization of technology that, in terms of message _security_, is a step backwards.
Doesn't mean I'm in favor of such ridiculous things as you've suggested here.
Many of us have, and painfully if I might add, finally convinced people to abandon insecure messengers and move to something like Signal. Now the solution is to tell them to abandon Signal in favor of Matrix? I'll pass.
The problem is Signal is not a standard unless they open up their ecosystem, so we're not actually increasing the number of standards here.
I've been through the pain of convincing people to Signal due to lack of better alternatives at the time. And I've done it yet again for Matrix. In this case, each move brought us closer to a global optimum so I'm not sorry for it.
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.
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!).
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.
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.
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.
> 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.
Making encryption and privacy a common thing is important to maintain the anonymity of those who have something to hide for various reasons. It's the same as law enforcement using dubious methods: We don't object because we're criminal, we object because we're not (i.e. and don't want to risk false charges).
All your comments appear dead to me, I think it's because you're a fresh account and have been shadow banned. Just guessing, I'm not sure about that but I saw similar behavior for another user on a different topic. I vouched because it looks like you're making points in good faith.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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
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).
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.
Companies whose mission is centered on user control and privacy can be held to a higher standard than other companies when it comes to these kinds of questions. It's perfectly reasonable to suggest that Element should have tossed out the idea of supporting Signal for this specific software offering, given the potential for collateral damage in the form of person A using it without person B being aware of this, particularly if person A does not grok that they are compromising person B's communications if they are using it.
Disclaimers and warnings are not universal solutions to questions on ethics since they are not certain to be read or understood and will have some failure %. If the residual negative effects are likely to exceed the kinds of outcomes a company's core values can tolerate, then making those states unrepresentable by abandoning product ideas is sane.
sneak’s pet issue is 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.
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.
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.
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.
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.
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.
“Regret”. You don’t sell an app that barely makes money for $19B actually believing its most valuable asset won’t be used. Not like he isn’t currently keeping most of the billions he made from such “blood money” too.
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.
Following up on this... I was Miranda user. With it I was able to run ICQ, MSN Messenger and other instant messengers with an encrypted layer slapped on top (as long as I was able to talk my friends out of using the official client). Today it's called Miranda NG[1] and it seems alive and kicking[2].
My problem with the self-hosted model is that I don't trust myself to get it right and/or keep it updated. My problem with the 3rd-party model is that I don't trust them, either. So, lacking trust in either myself or the third-party, I'm just one of those people you can get only via secure e-mail, clear-text SMS, or whatever well-supported encrypted service happens to be the one with a plurality of users in my friend/family group. Clear-text sucks, but it can be used to negotiate a secure channel.
Unfortunately, the levels of spam in my traditional telephony services have dramatically increased in recent years, and as a tradeoff, I've just gotten harder and harder to get in touch with directly as I increasingly default to ignoring more and more methods of communication. I don't even think I'm someone with anything to hide or anything to fear my communications being in the public, there's just too much information to manage.
I feel the same way, I don't fully trust hosted solutions but don't completely trust myself to host my own -- which is where E2E encryption comes into play, but a malicious host would still have access to loads of metadata (timestamps, IPs, etc.).
Blockchain-based solutions like Status.im appear to do away with these sorts of issues through decentralization -- but you still have to put trust into their network.
Solutions like TLS & OMEMO over Tor for XMPP seem to be a very strong privacy-centered solution outside of blockchain-based applications.
I'm excited about NixOS (/GuixSD) because they would seem to provide a straightforward path to running secure services (self-compiled from publicly reviewable source) while keeping them automatically updated (build rules administered by a third party). I'm not saying this is a good approach for you personally right now, but I can definitely see it becoming popular in several years.
How can you verify what the latest update of Google Play Services is doing on your Android that's running a proprietary WhatsApp client just so you feel happy you have "E2E" encryption?
Reproducible builds allow verifying that your build is correct by rebuilding it
It doesn't help you verify that the server you're connected to is running the binary you've been given.
I'ved heard that pitch before. It's always true only for some length of time. Protocols change, services evolve, companies transform, products are deprecated and people are fickle.
I've used all-in-one messengers before. They come and go like the wind. You'll be downloading a shiny new all-in-one messenger periodically anyway.
Just trading one kind of inconvenience for another.
Perhaps if we normalized messenger interoperabiltiy, there would be less churn in "all-in-one" clients. That churn exists mostly because platforms actively fight their users on this.
And still, periodically changing an all-in-one messenger is still better than keeping and changing half a dozen messengers.
And the downside of an all-in-one client is that they are going to have to port/shim/polyfill features from a hostile, proprietary, changing API.
Once again, the problem is not technical, it's political. Until interoperability is enforced by government, I expect companies to keep building their siloes. Network effect and tragic commons and all 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).
Pidgin doesn't use a "bridge"... it is just a generic local client that supports plugins for various protocols that are implemented via adversarial interoperability.
And because of that Pidgin is horribly unreliable. Don’t get me wrong, I used it for years, but over time all the plug-ins broke for one reason or another.
Law makers are required here to solve the situation, as platforms themselves refuse to work with each other. If Facebook and Google had to operate a common protocol (just like IMAP), Pidgin would work much better or wouldn't even be needed.
But no, they want to prevent people from talking with each other via other platforms because "we're best" or whatever.
It's probably because they don't want to lose users.
If you have FB, and I have Twitter, and we can chat, why would I ever make a FB profile or you a Twitter profile?
The mutual exclusivity is the competitive advantage. All these companies are competing with one another for your eyes. It wouldn't make sense for them to give that up for no return value.
Exactly! Providing a walled garden just for the sake of keeping users should not be legal, just like abusing any other market position wouldn't be legal.
I get that they want their "network effect" and keep it to themselves, but this is no good for users and the industry doesn't "regulate itself" as we've heard so many times, so time for law makers to step up finally.
My point is that the walled garden is the competitive advantage.
A law like this could regulate businesses out of existence.
Which websites fall under it? Only social? What about forums, etc. What if the companies just rebase to non-US jurisdictions? Even if you make this law, it's unlikely it would actually compel anyone to comply.
> A law like this could regulate businesses out of existence.
Only if they didn't change their business model to something less incredibly antisocial than walling people in and serving them ads.
There are many ways to operate a communications business on-line. That only the bad one is used in practice is a consequence of it being the most profitable of available options. If it weren't available (say, because of being regulated away), companies would pick the next most profitable one.
Yes — this line of argument sounds exactly like the people who very confidently said that the economy couldn’t survive ditching asbestos or CFCs, emissions laws would destroy California, etc.
The key part is having regulations apply the rules evenly so everyone prices it into their decisions. Trying to limit specific companies makes that feedback cycle less effective.
Yes, but what if this is the only way to have a profitable business such as these? Are you okay losing them entirely?
More generally, my view of regulation is that it should only exist if there is some quantifiable harm to an involuntary third party (negative externality). Where is the demonstrative harm here, and who is it impacting? Having one friend on FB and another on MySpace, requiring the user to log into each platform separately isn't harm. The effect is the same as having one friend call you on a phone to communicate and the other only use text.
Every single person using these platforms makes a conscious decision to use them given their limitations. Nobody is forcing anyone to use these platforms. The government still runs a post office. You could use that to communicate with people if you wanted.
Instead of passing legislation to fix your problem, how about you just talk to your friends and get them to agree on using a single platform?
> Yes, but what if this is the only way to have a profitable business such as these? Are you okay losing them entirely?
But it isn't. We know it isn't - exchanging text, audio and video messages wasn't invented by adtech giants. Two prime examples:
1) Telephony and mobile telephony operators have strong businesses to this day, despite being made interoperable by law.
2) Non-adtech e-mail providers exist and make money, despite being interoperable and not subsidized by advertising and personal data misuse.
> Where is the demonstrative harm here, and who is it impacting? Having one friend on FB and another on MySpace, requiring the user to log into each platform separately isn't harm.
In my opinion, there is harm - creating unnecessary burden and confusion for everyone, especially non-tech-savvy people. It is tying people down to services via network effects, and then further harming them by exfiltrating their personal data and exposing them to advertising (either directly or indirectly, making the ads more potent thanks to aforementioned personal information).
> The effect is the same as having one friend call you on a phone to communicate and the other only use text.
No, it isn't. It's just having one friend text you, another friend write you a Messenger message, yet another a WhatsApp message, yet another a Telegram message...
> Every single person using these platforms makes a conscious decision to use them given their limitations. Nobody is forcing anyone to use these platforms.
But that's not true at all. People are coerced to use these services, and coerced to stay with them. That's the literal definition of network effect. I have to use WhatsApp/Facebook/whatever because my mom is there and doesn't want yet another chat app, and my local plumber only communicates through it. I have to stay, because neither my mom nor my plumber will move. The more people are trapped in the net, the stronger its hold.
Contrast that with phone and e-mail service: I can communicate with anyone regardless of the provider they use. I don't even need to know what provider they use. And I can switch my providers at any time, and nobody else has to know, or care.
> Instead of passing legislation to fix your problem, how about you just talk to your friends and get them to agree on using a single platform?
These platforms are as successful as they are exactly because your proposed solution is impossible to implement by most people. Again: network effect.
WA works with a pure go-based bridge. No Android required.
The rest of your comment is true though. Keeping these bridges up 24/7 is quite a bit of work. Most people (even technical ones) probably won’t bother with that.
You need WhatsApp to be installed on a real device or a VM for mautrix-whatapp [1] (the bridge) to work. You also need to connect to that real device using WhatsApp web [2].
With enough motivation, competitors can reverse their efforts. Reversing (competitors' job) is finding just only one flaw in a system. Hardening (WhatsApp's job) is thinking about all the possible ways it could be flawed. It can be an endless cat and mouse game though I guess.
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 don't think anything got "shot in the end"; the protocols of old were often just reverse-engineered too. Few bothered publishing anything about it, which is why Jabber/XMPP was created.
Since then encryption made things a lot harder; specifically, E2E encryption. You can't "just" login to a server and send messages, you need to encrypt and decrypt things on the device with the right keys, and how do you handle things like message history WhatsApp and Signal solve this for the desktop/web versions by designating your phone as the only device that can connect to their service, and everything else communicates via that phone. Telegram solves it by having regular chats not be E2E encrypted, and having a special "secret chat" feature for it.
That's not 100% accurate. Signal handles message history per device. If you link a new device, you can only see messages that were sent/received after that. There is no way to sync messages between devices, they all get the messages from the signal servers directly.
This also means that you can use signal on linked devices if your phone is offline; you just need the phone for initial sign-on.
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.
Transports work for you when you're an upstart, because it makes it less risky for users to adopt your platform. They work against you only once you get significant market share.
See e.g. Slack, which propelled itself to success by offering an IRC transport, which prevented strong opposition for technically inclined people, and then promptly killing it when they became a major player in the office IM space.
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.
The first two are not well solved by Matrix as the default client is far less user friendly than the proprietary alternatives.
Storage space might be an issue on very low end phones but these days phones are starting with 128gb of storage which no IM app is close to filling. Mobile OSs are extremely good at sleeping apps and can receive messages while the app is not running at all using notification services. I would say that resource bloat is actually much more of an issue on desktop where you have 10 instances of chrome running and none can be closed while still receiving notifications.
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?
I've been using Beeper.com for a while and it's surprisingly stable despite how brittle one would expect these bridges to be.
Given that puppeteering should be indistinguishable from real application usage and that $5/month/user should be more than enough to diversify IP addresses, I suspect the model can actually be sustainable in the long term.
I'm kind of curious how Beeper will handle some of these - they claim to soon support WeChat, and emulating WeChat is a bit insane, because it collects so much data that it's a walking GDPR violation, there's no way to stop it, and we are talking things like "please repeat the numbers in chinese, then english, while looking straight into your phone" at login.
It's a Chinese chat app (that is also used for payments, thus linked to bank accounts). Getting an account more or less requires ID or similar. They go to extraordinary lengths, similar to Tiktok, to block automation, bot accounts, etc.
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?
Yes, in the same way that you need to trust Whatsapp not to MITM you. What's your perceived difference between these trust levels, other than one is something you pay for with money, and the other doesn't require money?
Aj, my bad. I skimmed over the part where it says they are hosting the bridge for you. Since matrix is focused on privacy etc I assumed this is available as a container/VM I can run at home or on a VPS.
Indeed then very weird why I should trust them more with my personal data than anybody else.
As far as I can tell, the messages don't live in plaintext on Element's servers - they are bridged in plaintext to Matrix, which is end to end encrypted.
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 cannot use this service in good conscience because it touches the US, the fact that they were willing to launch a paid service made me wonder about the viability of the components.
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.
> Why do you need to “check them” in the first place though?
I have this problem; most Android apps send background notifications via Google's Firebase Cloud Messaging instead of rolling their own services. (Signal is an exception to this.)
So, if you're unwilling to use Google Play services (or us an OS which doesn't support it), you're fucked and will not receive background notifications. The primary reason I use bridges with Matrix is not to unify my messaging experience into one app, it's to get notifications on my phone.
> So, if you're unwilling to use Google Play services (or us an OS which doesn't support it), you're fucked and will not receive background notifications.
I don't know about WhatsApp, but at least Telegram and Threema can fallback to polling if push notifications aren't available. With polling there is of course the trade off between battery usage and message delay, but you shouldn't miss any messages.
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:)
What's the point of this? Matrix, Signal, and Telegram all have open source clients, so you could make a client that used the native protocols and not route your messages through this third party's servers. Like Pidgin, Miranda IM, Trillian, and others. But I guess a monthly fee and cloud services are the more modern approach.
> 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).
They store everything encrypted but this may open the door for legal requests to get access.
While the software support is there to run bridges to many other communications services, the actual bridges are direct agreements worked out between the various comporations and non-profits. You would have to be important enough to start such a dialog and relationship if you wanted to run the bridging features locally. So, don't expect to bridge to Libera IRC just because there's a software option.
You can always run bots, but that's not a real bridge like what is being described here.
How safe is this to use? Couldn't WhatsApp or Signal detect you're routing everything to a shared hosting server somewhere and ban your account as a bot, stating the fact you're probably breaking some ToS clause?
I can't speak to WhatsApp, but I've been using the self hosted Signal bridge [1] and it is brilliant, no bot troubles at all. Behind the scenes it uses signalid [2].
I am wondering the same. Did WhatsApp ok this or will it get shut down the moment it gets any traction?
Their terms of service [1] clearly state:
> You must not (or assist others to) directly, indirectly, through automated or other means, access, use [..] our Services in impermissible or unauthorized manners [...] including that you must not directly or through automated means: [...]
> (g) sell, resell, rent, or charge for our Services or data obtained from us or our Services in an unauthorized manner;
> (h) distribute or make our Services available over a network where they could be used by multiple devices at the same time, except as authorized through tools we have expressly provided via our Services;
> (i) create software or APIs that function substantially the same as our Services and offer them for use by third parties in an unauthorized manner
Conspiracy: Element has been taken over secretly by the US government, and Element One bridges will now have access to all the encrypted messages across multiple platforms that people assume are only destined for the recipient.
It's brilliant actually. The more I think about it, the more that Matrix bridges seem like a perfect NSA tool. It's a man-in-the-middle attack of grand proportions, hidden in plain sight.
It doesn't look to be as good as it sounds. Privacy matters aside, you still have to keep WhatsApp installed on your phone.
> To connect your WhatsApp account, scan the QR code below:
> Open WhatsApp on your mobile device.
> Go to "Linked devices"
> Press "Link a device".
> Scan the code below.
Would pay money to get rid of Facebook software in my devices.
This kind of stuff never works reliable of even fully. Because? There is no standard. And especially Telegram and WhatsApp will have absolutely no interest in keeping it working reliable. If you send your data anyway over this questionable services you're already in a concerning situation adding more possibilities for failure doesn't help.
I use Matrix and it is certainly a good thing and the connections to other stuff like IRC, too. The fix is getting rid of WhatsApp. Signal is fine, the non-native desktop applications (i.e. fat and ugly Electron with Chrome behind) needs a rewrite with Gtk and Qt.
> especially Telegram and WhatsApp will have absolutely no interest in keeping it working reliable.
Telegram at least seems to have pretty decent libraries available to communicate with their API. I don't know how often it breaks, but I've been using the "tg" CLI Telegram client in the last week, and it seems to work fairly well (better than their own web interface anyway).
I looked a bit at writing my own as I have some issues with the tg UI; I haven't written the code yet but just looked at the options, and overall it seems fairly decent.
> And especially Telegram and WhatsApp will have absolutely no interest in keeping it working reliable.
One of these is not like the others:
Telegram both provides a library to bootstrap alternative clients and prior to that they also sponsored a competition to create a second semi official Telegram client for Android, Telegram X.
So I guess Telegram won't be a big problem.
But of course, saying something bad about Telegram, true or not, feels pretty safe here.
Telegram actively goes out of their way every day to support third party clients , and even keep their systems open to risk of heavy botting/spam , just to support third clients. (And they do have to fight against a lot of malicious bot activity).
I use their client api to build cool stuff for my userbot all the time, i have great respect for telegram and matrix.
Signal and Whatsapp are more apt when considering walled gardens, not telegram.
I fully understand that for many, this is not an acceptable security risk. It may have technical compromises.
For me, Whatsapp is used by my non-technical in-laws for the simple reason of "because everybody uses it". I find whatsapp extremely impractical (I communicate better via large ergonomic keyboard on my computer, vs via 1.5"-wide screen; to each their own), so anything that makes Whatsapp and other proliferation of incompatible annoying chat services easier... yes, yes, please yes :)
And they're broken broken broken, and such by design.
Current app uses Phone as primary and allows for one other-non-phone-device. If you try to log in on e.g. your tablet and computer, or switch between them often, you'll hit any amount of trouble and will get locked out of account.
The current beta has enhancements for multi-device support which may support several non-phone-devices at the same time, even if your phone is offline for short period of time. But it's buggy and your Phone is still your primary and it still won't allow you to sign up without one (it assumes Phone is Me and my life centers around my phone, which is true for my in-laws but not for me:), and the list of limitations is sky high and likely to remain that way.
Whatsapp fundamentally prioritizes end to end encryption; primacy of phone; and convenience of contacts for privacy-non-conscious, over everything else. It is good for those who highly value end to end encryption, for reasons of need or principles.
For those who need multi-device support, Whatsapp is way way way worse than other chat services of today or 1990s. Right now, I am logged in to Hangouts on three computers, tablet, phone and Galaxy Note (whatever we call that these days:). I am available via Hangouts whatever I do and wherever I am. And frankly I find it more private as it doesn't advertise my existence to all my contacts and siphon them off, doesn't require my phone number which is one of my most private pieces of identifying information, and provides me actual privacy and anonymity if I choose, but that's a whole other discussion.
Whatsapp does not, and will for foreseeable future not support my use case. It may or may not be rare, it may or may not be something anybody else thinks is important, but Phone is not the centre of my existence or my sole & preferred method of communication, and as such whatsapp is completely unusable for me. I may be 1% or 0.00001%, and I'm open about that, but this whole notion of "Whatsapp totally works on multi-device" is just getting tiring to misspell - it's right on their FAQ that it is counter-indicated by design by current production version.
Note that the Matrix WhatsApp bridge is fundamentally pretending to be the WhatsApp web client (as I understand it at least). The phone is still the interconnection point and if you turn off your phone no WhatsApp messages would get through to Element. It is improved by being a once off 'pairing' though and you don't need to switch between multiple web clients.
Of course the new 'multi-device' beta might improve the situation but that's not leveraged yet.
There seems to be little information about the company/people who runs Texts on the website which is strange - where did you find the info of who runs it?
Both the Android and web clients are promising, it's clear there's been a lot of work put into it, but they're also way too buggy and unpolished to recommend. As such, I'm really not eager to use this feature.
I would pay/donate just for them to improve the clients, regardless of this "Element One" service. It's an extremely important project.
I am in the Beeper beta. Beeper supports Matrix, Whatsapp, Signal, and Telegram, but also Slack, Discord, Hangouts, Instagram, Linkedin, Facebook Messenger, SMS, Twitter, and crucially, iMessage on non-Apple devices! It is a beta but it works pretty well so far. AMA
One thing I didn't spot, does this tier allow you to use a custom domain name on Matrix, or will you be :matrix.org still? $5/mo is an interesting price point for me if it can do that, I don't need the bridges but I could support the project this way.
Sadly I don't have a single friend on Matrix that I could consider doing this with, and it's unlikely I could convince my wife to use it either. So it would be double the money for only that piece of flair.
You don't need to convince your wife to switch, you can start by helping her setup the app on her phone and tell her to use this app when talking to you.
Lower the stakes and the expectations. Even if she is starting conversations with you on any other app, you can still start the conversations on Element. There will be bugs and quirks she will find, you just offer help and ask her for patience.
With time, they get used to the app and will be okay with starting the conversation with you there.
That's what I did with my wife, my parents, closer family and friends. Then you get one day like the recent Facebook outage, and they will come to you to ask if you can help their friends to sign up to it.
Slow and steady is the way I found to run this race. I already managed to get rid of WhatsApp and Messenger on my phone, it's only telegram for the odd group chat that is still resisting a full change.
Element's regular matrix services are bring-your-own-domain, and I use them for our family's hosting. Unfortunately it seems they've decided that bring-your-own-domain is a feature for companies, and also given it "contact sales" pricing.
The plan I'm on pre-dates "Element Home" and sits at the same price-point.
Unfortunately a side-effect of the split is that I can't use the new bridging product without moving back to a shared domain, and the billing model for bridges on custom domains really doesn't work for consumers, at $0.50 per month per person who talks to you.
The newer products are good upgrades for someone on the regular matrix.org server, but not so good for people who already upgraded :P.
The very story of each of WhatsApp, Signal, etc. is a testament to why interoperability across apps matters much less than user reach and feature velocity within an app ecosystem. Most people don't actually mind using different apps for different things once their friends are there, because functionality tends to break at the edges (even creating a simple group chat becomes a pain across non-cooperative networks)
The biggest things going for Element:
Integration with other services could be a gateway drug!
Works everywhere (any of the 5 devices I use), and can see all messages once I've entered my encryption key, while maintaining a good day-to-day level of privacy (I'm no expert but this is what I understood). This unlocks the potential to use the app as a go between for reminders and note taking! Without exposing that data or having it censored.
All the flexibility of Discord, Signal and Telegram for organizing chats, people and contexts.
The biggest let downs so far:
Voice channels work like traditional VOIP calls, making it unsuitable as a replacement for discord. Integration with other platforms to solve this seems insufficient. To become de-facto it needs to offer the discord experience of joining a voice "room" or being in a voice room by yourself without needing additional set up.
Confusion about spaces vs rooms etc. The interface is fine, but it could use some polish to distinguish between the different situations.
Launching with bridges to already-encrypted messengers, then immediately admitting this has to MITM them to work, doesn't make a good first impression...especially since users of these messengers will likely be more privacy-minded than most.
This is also making a bet that the inconvenience of juggling these 3 particular messengers is worth $5 a month.
IMO the real value in Matrix bridging that's been neglected (and has been mentioned elsewhere in these comments) is connecting different messengers _to each other_. Being able to connect friends/family scattered across different, otherwise-isolated protocols with a single "just works" tool is a much clearer value proposition than what feels like just another multi-protocol client.
Alas, getting that kind of multi-connectivity is tricky...as is VoIP bridging, which this doesn't support either, but should be considered as crucial for any Matrix bridge.
I don't doubt Matrix/Element will get there at some point, but for now this feels a tad premature.
Now, I miss Miranda. It was a multi protocol messenger I used for icq, aim, and jabber. Friends were more into trillian. But one always had bittlebee, I somehow envied this...
It’s for power users (assuming it actually works as advertised) - people who constantly keep messaging across apps; either for personal or professional needs. They already have multiple apps on their phones and they have to use them.
Not for people who find two messaging apps too much to have on a phone, or for people who’re talking about privacy.
iOS notifications unifies all my chat apps pretty nicely already, but I would still be really interested in running this on my own host, to keep a live archive of all my chats.
The thing I don’t have centralized is search, and too often some critical piece of information — which in the past would have been sent and later found by email — is buried in an IM from two years ago. If Element One’s search tools are up to scratch that could be killer. Support for Instagram DMs would be a must too.
Dare I say it, support for email too? I’ve often wondered what that would look like, especially with buffering so that I can send a few messages and have them batched into one email. Most emails these days begin with one round of “Dear X, … All the best Y” but quickly become one liners, trying to get something done.
Why are so many people trying to "solve" messaging? It's not a problem for 99.999% people in the world. They use SMS/Whatsapp/Telegram/Messenger. It works splendidly. We are happy. Please stop expending effort on this useless endeavour. Do something else.
> hosted by Element Matrix Services; constantly maintained to the highest standard and best practices by the experts who created Matrix - giving an infinitely better experience than the typical free-for-all of public homeservers.
The only experience I have with EMS is that their bridge to the libera.chat IRC network doesn't work. Specifically, the libera.chat homeserver that they host sends like 10% of the events that it should be sending to my (self-hosted) homeserver. I know it's not a problem with my homeserver because multiple other (non-EMS-hosted) homeservers work with mine just fine.
And there's no way to get help about it; none of the folk who run it are active in the #libera-matrix channel, and the libera.chat folks themselves don't have any knowledge of it because it's entirely maintained by EMS.
People who use matrix.org as their homeserver reported no problems with it when I asked, but at least one other person using their own homeserver said it was broken in the same way for them too.
My concern is whether Element One is in it for the long haul. If I stick with using Whatsapp and Signal I can be fairly certain they'll still be working in five or maybe even ten years. Is Element One committed?
this has been around since at least january of 2021.
i looked into using something like this or setting up my own synapse+bridges and ultimately thought the synapse server had way too much in the way of complexity and attack surface for something that would ultimately end up being a consolidation of all my encrypted messaging. (it was also a bit weird to see public internet protocols using grpc, but i guess that's what people do now)
that's the world we live in i guess. you either dedicate a bunch of time to watching your own infra, let tech giants read your messages or let hackers read your messages.
Do they also host the WhatsApp native instance (Android VM)? That'd be great for those using Pinephones who still want easy access to WA. Otherwise the WA bridge would only work if you run a client yourself.
Correct me if I am wrong, but this means that you have to trust the people running the bridging server with not just the content of your messages but your account identity/login information as well?
Yes, for bridged chats. Matrix <-> Matrix direct & group chats are E2E by default.
> but your account identity/login information as well
Yes, however identity/login does not permit access to E2E messages (and cross signing prevents E2E compromise [1]). Matrix supports migrating accounts to other servers [2] while keeping your data/social graph (depending on your history viewability settings I believe, someone please correct me if I'm wrong!).
I wonder why Facebook Messenger is not included? From experience, the Messenger Matrix bridge has been surprisingly robust, moreso than the signald bridge.
I already have a way to unify my messaging across different apps. It's called MacOS and cmd+tab. Sometimes on the road I use something called iOS. Sure it's not the same. But is it that different either?
All messaging apps have their own native features, some have E2E encryption etc. Not sure if there's a common subset that is enjoyable enough to use that it's worth it.
That being said, I do wonder what will be the "Facebook Events" (invite all your friends to an event) equivalent in the future when everyone is in a closed garden chat platform instead of Facebook.
There is definitely a benefit to having a unified interface. The vast majority of the time I don't want to use each chat apps specific features, I just want to message people. And then sometimes I want to be distraction free and turn off notifications. This is much easier if everything is routed through one app.
I'm also on macOS but I've been using Texts[1] for a few months and it has been a great experience.
Do they deal with the hassle of maintaining phone numbers for me?
I obviously want different numbers for my messengers and for the phone I walk around.
It is possible. I've been running my own for a year, but it takes quite a hefty server at least with Synapse, and it's not cheaper compared to the quite nice 5 euros a month pricing here.
sadly, discord ToS forbid "self-botting", so the only legal option is to use a Discord bot, and that's far from seamless and requires guild admin cooperation, I assume that's why they aren't advertising it
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.