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