Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Federated E2EE is possible but won't achieve widespread adoption.

Signal's choices optimize usability of E2EE messaging for the masses.



Federated E2EE can work. Matrix did it. But it took lots of extra time, a time cost imposed structurally on the project by being open to third parties who had to coordinate to get things deployed. It's especially painful when you run up against protocol vulnerabilities, doubly so when the fixes for those vulnerabilities involve policy decisions that are their own coordination problems, which is a jam I think Matrix is in right now. All of this is stuff Moxie Marlinspike more or less predicted in his post.

Again: you can get past this stuff, and Matrix will. But Matrix is going to get through this because their use cases (more or less: replace IRC and Slack) are forgiving. Signal's aren't.

My gripe isn't that HN users refuse to tough out Signal's rough edges; I certainly don't ask my own family to use Signal to talk to me (I use Signal for things that matter, and little else). My gripe is that HN people who should know better don't seem to respect, or at least understand, the painful decisions that Signal made to support its use cases, and instead write weird little essays about how Moxie Marlinspike, the "brilliant cryptographer", built Signal this way because it was fun. It doesn't look super fun to me.


Claiming that Matrix did it is even a stretch. Only a few core features are covered and just about every new feature ships without E2EE. Room topics aren't encrypted, sticker packs aren't encrypted, reactions aren't encrypted...

The devs will tell you that requiring every feature to be E2EE will slow down adoption too much, that can always be added later as another MSC (Matrix Spec Change).


This is not true :| We do everything to encrypt new features - eg voice messages, polls, location share etc are all encrypted. It’s the old features which predate e2ee (state events like topics or sticker packs and aggregations like reactions) which need to be brought in line, and MSC3414 is addressing that.

> The devs will tell you that requiring every feature to be E2EE will slow down adoption too much, that can always be added later as another MSC (Matrix Spec Change).

No?


I'll give you a pass for state events but sticker packs are still going through MSC and it seems that people on the team are happy to add E2EE later?

https://github.com/matrix-org/matrix-spec-proposals/pull/254...

Or is that out of date and there is a new proposal with encryption?


I assume you’re talking about https://github.com/matrix-org/matrix-spec-proposals/pull/254.... There is nobody from the spec core team or for that matter the matrix core team on that thread; Sorunome, deepbluev7 and Cadair are community contributors. You can spot the folks who actually are project members (ie core team) by the “member” label next to their names in Github. It is unlikely that the MSC will pass review (when we finally get to it) unless it’s e2ee… unless MSC3414 automatically handles it.


Well that's good to hear. Maybe it would be good to drop an "official" note on the RFC to make it clear that it is unlikely to be accepted without E2EE since I seem to be the only voice mentioning that and was quickly dismissed.

I understand that the core team is busy but if big problems like this could be pointed out early it could save a lot of time all around.


Do you mean that they send it unencrypted or that it isn't end-to-end encrypted?

Please be precise.

This is probably the most annoying thing about HN lately, the insistence on pretending that only end to end encryption matters.

Meanwhile we see end-to-end encrypted solutions like WhatsApp being cheered forward but ultimately failing badly because all incentives are aligned against security.


>Federated E2EE can work. Matrix did it

Kind of hard to claim they've done it given their current level of adoption.


Quite easy actually when you look at the number of governments who rely on Matrix - https://element.io/case-studies/tchap, https://element.io/case-studies/bundeswehr and many more (US, UK, Sweden, Ukraine, Luxembourg, Finland…). But if your friends aren’t on it, i guess that means nothing.


> But if your friends aren’t on it, i guess that means nothing.

Well... yes, actually. Governments use a lot of things that don't have widespread adoption outside of governmental use cases.

If your goal is to build for that market -- for environments with very specific needs -- then you're doing a great job. But governmental use isn't the ringing endorsement that you seem to think, because it has no bearing on actual widespread adoption.


Back in the day, I used to use BBSes via local dial-up. Everyone did, so you could expect BBSes were on the rise from so much usage. Meanwhilr, governments were stuck on ArpaNet and futzing around with some newfangled "TCP/IP" protocol. What good does government support even provide???


His entire point is that Matrix went for and is in the process of getting the larger goal right for the sake of long-term adoption at the cost of development time -- whereas Signal opted for worst-is-better limited-scope pragmatism for the sake of near-term adoption.

Whatever lesson you want to derive from this technical trade-off is up to you, but yeah the psychobabble about Moxie is absolutely tiresome.


I don't understand why you use Signal only for things that matter. If you use Whatsapp, all your metadata is available to Facebook, which can learn a lot about you and your personal networks and use that information for personal advertising.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: