Hacker News Reader

Comment by KAMSPioneer | Hacker News Reader

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

View on HN

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.

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.

Reply on news.ycombinator.com