Hacker News Reader

Comment by tao_oat | Hacker News Reader

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

View on HN

I want this to take off. I'm tired of having to follow trends because people suddenly think there's a new shinyshinytrendy thing around: IRC to ICQ to MSN to Skype to Google Talk to Facebook Messenger to Whatsapp to Signal.

Pidgin is good (I also miss the ancient Trillian, even though it was closed source), but limited to a local device.

There are XMPP Transports as well for these (see https://git.eta.st/eta/whatsxmpp , https://gitlab.com/nicocool84/spectrum2_signald , but sadly https://spectrum.im/ is surprisingly finicky to set up.)

EDIT: for encryption fans, I've been wondering for a long time now: why would you trust ANY 3rd party with your so sensitive data instead of running your own service? Are you not aware of OMEMO for XMPP? (See https://omemo.top/ )

Trillian was awesome! It's just a shell of its former self now.

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.

No, this is not the same. You want the utmost privacy, yet you still decide to trust someone over it.

The threat model is vastly different, though.

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.

Then these bridges are fine. Virtually everything is better than raw SMS.

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.

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.

remember that xkcd https://xkcd.com/538/

yeahh. thats not exactly a meme but i am personally facing these same state sponsored actions read here https://thekashmirwalla.com/not-pegasus-kashmiris-are-worrie...

Yeah, infosec has its limits. But if you’re gonna challenge the state, it does help keep things quiet until you are numerous and armed.

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.

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.

I also want utmost security for my money, which is why I put it in a bank rather than holding the cash myself.

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.

Here's a guide on how to install everything needed onto a raspberry pi: https://samhobbs.co.uk/2016/09/installing-prosody-instant-me...

As with anything else, it's a fun learning experience and something new to try.

That is the kind of comment that freaks me out on HACKER news.

Not everybody hacks on everything. Many of us pick and choose our hobbies. I don't sysadmin my phone for the same reason.

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

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

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.

https://www.freshports.org/net-im/signald/

Huh. I wasn't aware of this. I tried for quite a long time to compile it myself a while ago and failed, I'll give it another go, thank you!

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.

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.

The advantage of having your servers at home is that when the police shows up with a search warrent you know you can't trust that server anymore.

If you use a 3rd party, it can be compromised and you only find out when it is too late.

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.

what about when cisco or "someone" helped india government impose censorship on aroun 8 million people so that they cannot use a vpn or access only whitelisted websites? https://theprint.in/india/us-firm-helps-jk-build-firewall-to... https://tech.hindustantimes.com/tech/news/this-us-firm-is-re...

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.

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

Oh, and Dino got support for doing encrypted calls to Conversations a few months ago: https://fosstodon.org/@dino/106228549009869402

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 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 think Monal can't do encrypted group chat yet.

> minus group OMEMO on iOS

siskin.im has support for OMEMO encrypted group chat

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.

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.

Doesn't grapheneos allow some type of sandboxing to wall off your true contacts, etc. for exactly this purpose?

https://www.reddit.com/r/privacy/comments/nkyzdw/what_is_the...

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.

Maybe. I probably don't relate well because I talk to maybe 10ish people regularly.

Everyone else, if they don't migrate to a secure and preferred method, I just use email (with pgp if possible) and call it good.

Shelter can be used for this purpose if desired.

https://github.com/PeterCxy/Shelter

Thanks!

I believe Insular can do this as well. I prefer Insular since it allows me to open the app directly and more quicker.

  > forced onto FB’s WhatsApp

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.

> why would you trust ANY 3rd party with your so sensitive data

Because trust is not a binary value and I don't have the time to do literally everything myself

I'd go further -- absent pressure, there is never any reason to trust anyone. The more pressure one faves, the more one has to trust people.

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.

> 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'm tired of having to follow trends

Then don't. I have none of those things save for IRC. I get all my work done and live a full life.

I remember when I first installed Trillian around 2000, it was so cool!

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

Eric Migicovsky, Pebble founder who now runs https://www.beeper.com/:

> These bridges are actually just an intermediate step. Since Matrix itself is an amazing chat network, eventually as more people start using bridges on Matrix, they’ll notice that their friends are already on Matrix, eliminating the need for bridges gradually over time.

> I really believe that the world will be a better place when everyone is in the Matrix. Matrix is the non-proliferation treaty of chat.

https://medium.com/@ericmigi/the-universal-communication-bus...

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)

You don't know that when you message someone on Signal it's for their eyes only.

What you know is that unless their device is compromised, it is up to them to decide who can read the messages that you send to them.

Thus the situation with the bridge is not in reality different from the situation now.

No - the bridge could be compromised without your conversation partner’s involvement.

I.e. the bridge is a vulnerability that enables man in the middle attacks.

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.

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.

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.

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

So yes, Element have introduced a new fact that downgrades everyone’s estimate.

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

It's just better known now.

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.

That hadn’t been done before by anyone credible.

Your conversation partner's device could also be compromised remotely.

Yes, but that’s in no way comparable to a centralized server where potentially millions of conversations can be compromised at the same time.

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.

Well, not entirely true, because sginal has sent random images out to wrong contacts before.

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?

edit:https://www.huaweicentral.com/new-whatsapp-report-feature-wi...

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.

In theory, signal could work with matrix people to support bridging with e2e encryption.

But as far as I know, signal wants to be walled garden. So then it is expected that people create work arounds.

(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 :)

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

> A brute force approach would be to provide an open source, self-hostable server

The server/bridge is not opensource? I see their github account has lots of code.

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

Just ask your conversation partner?

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.

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.

> jazzed about the democratization of technology that, in terms of message _security_, is a step backwards.

Well, you can always switch to Matrix and have democratized and secure native messaging which uses a cryptographic protocol comparable to Signal. ;)

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.

Also, obligatory xkcd: https://imgs.xkcd.com/comics/standards.png

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.

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

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.

> (because you’re an activist or whatever)

How about because I'm a regular person, and I don't want everything I say analyzed by the federal government and stored in perpetuity? I'm increasingly repulsed by this notion that unless I'm doing something illegal or in opposition the the ruling party, encryption is just a luxury. Encryption is for anyone with any desire to express themselves honestly without modifying their behavior because someone is watching.

People flock to Signal for a reason and a lot of them will use this "bridge" without understanding what they're giving up. You're doing more harm that good to try to usher people towards your platform.

> People flock to Signal for a reason

Why would you go to a walled garden if you want more freedom/control? You should just go to Matrix and host it yourself (and keep all the metadata to yourself, too!).

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.

https://news.ycombinator.com/item?id=29001070

I very much agree with you.

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

It's still a chat app and if I can't reach enough people it's useless.

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

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

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.

You misunderstood what he said if that is your TLDR.

Furthermore, this is not the first time privacy issues with Matrix have been brought up to you and dismissed without understanding.

I am going to begin recommending that people actively avoid adopting Matrix/Element.

Could you expand on the "privacy issues", please? Not sealioning or whatever, I am genuinely interested.

Not sure what exactly they were referring to, but here are some of them: https://github.com/libremonde-org/paper-research-privacy-mat...

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.

The libremonde research is over 2 years old now, and the valid bits of it were addressed at the time (https://matrix.org/blog/2019/09/27/privacy-improvements-in-s...)

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.

> element web assumes that you want to log into the matrix.org homeserver

Ahh. Seems like an easier problem to fix then. Doesn't Element Android remove that assumption and let you choose?

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

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.

> or run a bridge yourself

Quick question, is the code for the bridge opensource?

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.

I won't use it for signal indeed, for whatsapp though... can't wait to throw it of my phone!!

I didn't dive into it, but can you also self-host this? Looking forward to some docker-compose snippets in that case :)

All the bridges (and the matrix server itself of course) are self-hostable.

Here you go: https://docs.mau.fi/bridges/go/whatsapp/setup/docker.html

Element One uses a modified mautrix-whatsapp, which means that your phone needs to be connected to the internet for the bridge to work - so you can't quite throw it off your phone. I don't have to regularly open the app or anything, though.

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.

Spare phone method should work, I've barely used whatsapp so I'm not sure if it needs a SIM after setup.

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.

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

If you believe that, then I have a bridge to sell you. :^)

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 like saying "If you don't sweep the bathroom for bugs/cams, you don't really care about privacy. Why do you bother closing the door"

This is a very all or nothing mentality. It's also kind of like saying you should put locks on your locks. Signal's core reason for existing is that it puts a focus on privacy. They say this all over their homepage [0].

One of the founders of WhatsApp donated $50M to Signal [1] out of regret for how WhatsApp shifted away from privacy after being acquired by Facebook.

The entire project is freely visible to anyone on github [2]. They've made it so even if you don't trust their servers, you can set up your own server and clone your own android/ios app, change some settings and have everything hosted yourself.

There's no reason not to expect Signal to maintain the focus on privacy that they've put in thus far.

[0] https://www.signal.org/ [1] https://www.wired.com/story/signal-foundation-whatsapp-brian... [2] https://github.com/signalapp

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.

Your method delivers optimal conversation privacy by ensuring no-one would want to jump through the hoops to talk to you.

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 self-host. I suspect they use this: https://github.com/spantaleev/matrix-docker-ansible-deploy

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.

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

Um, how do they do that?

> All integrations were implemented in-house using the Texts Platform SDK. The SDK will be open sourced at a later date.

Seems like a big nope.

https://texts.com/privacy says:

> Messages, contacts, auth credentials, account information never touch Texts servers.

> Your messages are sent directly to the messaging platforms.

> All end-to-end encryption is preserved when the platform supports it.

> Texts is a client and works like the official app.

Apparently all the code runs on the user's device.

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

Reply on news.ycombinator.com