[ncmncm]

Some current problems with Element, and with the Matrix protocol in general (there are a bunch of other clients, e.g Nheko, Fluffychat) include that you need a "homeserver" to store all your messages, and (1) there is no way to migrate to another homeserver (I gave up on Matrix after the third one went bust), (2) the homeserver has (!) plaintext access to all traffic on it, besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness, (3) there is no concept of identity independent of a homeserver, and (4) no effort at all to obscure metadata, who you communicate with and when. I don't know of any clients that let you manage separate identities at the same time, as many mail clients do. (I was running Element and Fluffy to manage two accounts, which is stupid. Maybe some do handle multiple accounts, now?)

Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients. [Some people are saying not: that homeservers don't see plaintext of E2EE traffic.]

There is talk about self-hosting in the client, but I don't know if it works yet, or ever will. Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.

If, in fact, messages are, or can now be, stored securely, I would welcome correction. Likewise, if client-side hosting works now, or message-store migration, or a stable address despite such a migration, or any effort at securing metadata. I have not kept up since abandoning Matrix, but still want a viable alternative to Signal.

The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.

Will we need to start all over again? A rigidly layered system, with a provably secure basis, probably in a single, sandboxed server talked to by all clients and gateways, with services built on top, seems needed if we want both security and features.

As it is, it seems like clients -- i.e. application services -- run in the same address space with what should be secure message transport, necessarily compromising all security with each bug added.

[mintplant]

> the homeserver has (!) plaintext access to all traffic on it, besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness

What do you mean? Signal is known for providing minimal information when requested by authorities, e.g., [0].

[0] https://signal.org/bigbrother/central-california-grand-jury/

[ncmncm]

Last I checked, it tied every single communication to a pair of phone numbers.

[2Gkashmiri]

oh, in my place, the police routinely stop you on the road, check your phone and if they see "whatsapp/signal" or "videos", they mercilessly beat you up, arrest you and charge you with sedition.

i know "whatsapp admins" who have been made to report to police stations because they operate "whatsapp news channels". there they are made to submit their phone and wait outside. then the phone is returned. i have suspected, for like past 3 years that pegasus style malware would have been installed during that time.

now, a lot of these issues and problems can be reduced/prevented if you were not required to mandatory link your mobile number. if they know me by a handle, rather than a phone, it would be a little bit harder to do mass surveillance and bullying.

[cormacrelf]

That's awful. Are there other "security by obscurity" measures you would like to see? For example, making these apps blend in with icon changes, fake splash screens/façades that look like games? Would people have done this already if it were common to build and use alternative clients to the major messaging services?

[2Gkashmiri]

https://thewire.in/tech/kashmir-police-vpn-smartphone-checki...

this was last yearand it continues. i have taught people to use launchers on android like evie that lets you hide apps. that saves you a lot of roadside quick grief. same for using password protected "gallery" like simple gallery to keep stuff behind a password. a thorough check will defeat all this but saves you in the field as you can be randomly picked.

whatsapp/signal/telegram as i said is more difficult, even clubhouse because since your phone is already public, the police do join groups, public or private using any means, lets say by surveillance, by getting access from company side or "borrowing" a phone from a member. then they just get a list of names and go knocking on doors. if the number was not there, it would have been much more difficult.

[IYasha]

And his is not the only example out there, unfortunately. ( Depending on country, measures can vary a lot.

[kelnos]

No, all they can provide to law enforcement is the time that you created your account, and the last time you connected to Signal's servers. That's it.

[lucgommans]

That's what they claim to store (and I believe it), but that's not all they can be forced to collect.

As a simple example, they could easily log whenever account xyz connects to do a token exchange for using sealed sender. Asking that of Signal won't be something I'd expect a judge would consider excessive if there is a legitimate reason.

[cormacrelf]

Yes, at the limit (not sure if US laws have caught up to Australian ones in this regard) they could potentially be forced to push an app update to carbon-copy all messages from specific people at the client side, unencrypted, to the government. This is generally why people care about having the app available on F-Droid, because you can more easily analyse DIY "supply chain security" on your own copy of the app. The other solution is what Matrix does, which is to encourage people to develop many different client implementations.

[kelnos]

Good point. It's unclear to me how much a government could require Signal does for future use of the service. Regulated telecoms are required to provide lawful intercept capabilities for phone calls. I'm actually surprised that the government hasn't argued against E2E encryption on those grounds.

[KennyBlanken]

Homeserver refers to matrix, and they're still wrong. If rooms and conversations are E2EE, they're E2EE.

Edit: grandparent comment can't seem to keep Matrix vs Signal straight.

[ncmncm]

I wonder why you would guess that.

Signal is the one that only works with Google Play, thus a Google account, and a phone number. It is easy for the spooks to connect that and its IP address to every subsequent communication, after the fact.

[einpoklum]

If it's known for providing some information upon request, then at the very least it is likely it provides lots of information upon demand - including secret demands like National Security Letters.

[Arathorn]

> Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.

This is categorically untrue. Matrix’s E2EE is between clients; homeservers can not see plaintext in encrypted rooms, and all private rooms are encrypted by default these days.

The parent is completely confused.

[p-e-w]

It's simply amazing to see you personally answer almost every single Matrix-related question on almost every single Matrix-related HN thread. You're literally the mastermind behind the most important internet protocol since HTTP, and yet you don't consider it beneath you to correct such basic misconceptions that nobody who so much as skimmed the spec would have had in the first place. Bravo!

[ncmncm]

I am corrected.

[ncmncm]

Still, with so much app-level code running in the same process with the encryption layer, any bug in that compromises security.

[feanaro]

You somehow got the wrong impression. The homeserver does most definitely not see the plaintext of messages sent into encrypted Matrix rooms.

It is proper end-to-end encryption using pretty much the same constructions as Signal.

[KennyBlanken]

> the homeserver has (!) plaintext access to all traffic on it,

Matrix homeservers have plaintext access to whatever is plaintext, though most matrix homeserver software doesn't include built-in functionality for admins to do that sort of thing; it would involve digging through the database(s). DMs are opportunistic e2ee and rooms can be plaintext or E2EE.

> besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness,

Signal is not Matrix...and Signal does not have any metadata except account creation and last-seen timestamps. Maybe the fact that you can't keep the two communications networks straight is a good sign you're not qualified to be critiquing them.

> The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.

That's not how that works.

Your comment is...seriously uninformed.

[up6w6]

> Signal does not have any metadata except account creation and last-seen timestamps

I hate the way Signal sells it, like there is zero trust involved and everything is solved by some magic encryption. There is a lot of data the Signal could store, like who is receiving the group message you just send to, that is only guaranteed by their server's source in Github (they could be hosting another thing and you will never know). That said, Signal is still much superior in terms of metadata protection, like the sealed sender feature for direct messages which will take time to arrive in Matrix [1]. I just wished they were more transparent about what they can't store and what they can store but is not storing.

[1] https://github.com/matrix-org/matrix-doc/issues/2318

[upofadown]

>Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.

Just clients I think. Otherwise it couldn't be E2EE. AFAIK, if you actually can manage to verify your correspondents with whatever the identity numbers are called in Matrix, you get effective E2EE.

[ncmncm]

If the homeserver sees plaintext, then it is by definition an End.

[nybble41]

By that definition all encryption would be end-to-end encryption, making the term useless.

The person sending the message and their intended recipient(s) are the "ends" in end-to-end encryption. The server is not an "end".

Incidentally, the client software is also not the "end": If the system includes a component designed to forward any data about the otherwise-encrypted content of the messages to someone who is not the sender or their intended recipient (unless at the direction of someone who is an intended party to the conversation) then the system does not implement end-to-end encryption. For example, Apple's iMessage app does this with their mandatory client-side scanning misfeature.

[nyuszika7h]

> For example, Apple's iMessage app does this with their mandatory client-side scanning misfeature.

There's a lot of incorrect information here. First of all, it is not mandatory, it's opt-in - parents have the ability to turn it on for children under 18 whose devices have parental controls enabled. (Technically you could argue that it is then mandatory for those children, but that's no different from other parental control features.) Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.

I think you're conflating it with the iCloud Photos CSAM detection, which would have been mandatory and sent results of on-device scans to Apple if you have iCloud Photos enabled, but they seem to have scrapped that (for now at least) as they quietly removed all mentions of it from their website.

[nybble41]

You're probably correct that I was thinking of the scrapped (or deferred) iCloud Photos proposal. Though this part:

> Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.

… suggests that there was something similar in iMessage at one point, even if it was later removed. The "on-device learning" (or rather, on-device classification) means you're effectively sharing the data with Apple's agent running on the device, and the user doesn't have the ability to turn that off. Though it wouldn't be unreasonable to consider the parent who authorized this to be one "end" of the conversation since there is a minor involved—assuming there actually is a minor involved. (These "parental controls" have been abused to monitor adults.) It would be best if that fact was somehow communicated to all the other participants, for example with a "parental control active" or "monitored account" badge on the user's icon & profile.

[kitkat_new]

it doesn't see the plain text of E2EE messages though...

[kitkat_new]

> (1) there is no way to migrate to another homeserver (I gave up on Matrix after the third one went bust)

partially true - while there isn't a protocol defined way, you can invite your new account to your rooms, import your encryption keys and leave the rooms with the old accounts

> (2) the homeserver has (!) plaintext access to all traffic on it

hmm, isn't that unavoidable?

> (4) no effort at all to obscure metadata, who you communicate with and when.

There is effort on it, e.g. by going P2P and eliminating dedicated homeservers

> I don't know of any clients that let you manage separate identities at the same time

FluffyChat, Syphon, and others I don't know the names by heart

> Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.

The ends are the sessions in a room. The homserver is not an end. How did you get that impression?

> Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.

Isn't encryption at rest usually done by the operating system?

[mananaysiempre]

>> (2) the homeserver has (!) plaintext access to all traffic on it

> hmm, isn't that unavoidable?

Not only is it avoidable, it’s not actually true AFAIU. It’s unfortunate (if historically justifiable) that Matrix has a non-E2EE mode, but the thing it brands as E2EE is actually deserving of the name, with messages accessible to clients only and the associated hurdles (you literally can’t get access to message history in encrypted chats from a new client on the same account unless you get one of your old clients to cross-sign, even if the homeserver will help mediate the prompt).

Matrix is not free of problems, but it does have federated, multi-party, multi-device, end-to-end encrypted chats with persistent history and forward secrecy. The underlying crypto goes by Megolm[1]. It’s slightly weaker[2] (in particular regarding backward secrecy) than the strictly two-party thing Signal does (however they brand it these days), but nowhere near the point of allowing the homeserver to eavesdrop.

[1] https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-...

[2] https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...

[heinrich5991]

> Not only is it avoidable, it’s not actually true AFAIU.

Note that new features apparently come unencrypted, even in otherwise encrypted rooms. For example reacting to messages with emoji sends the reaction non-E2E-encrypted for both all home servers to see: https://news.ycombinator.com/item?id=29656282.

[feanaro]

This is an accident of history and will eventually be corrected: https://github.com/matrix-org/matrix-doc/issues/2678.

It is certainly not intended that new features are unencrypted, but unfortunately sometimes it happens in order for features to get added sooner.

[heinrich5991]

Some random comments: I'd say this is something that wouldn't have happened for Signal. The comment I linked didn't make it sound accidental. In the linked issue thread, they talk about aggregation done by the server, which means that the server would still be able to tell that person A, B and C reacted with the same emoji. That sounds like a lot of information leakage to me, e.g. for people who do votes via reactions.

[feanaro]

Signal's and Matrix's position is quite different because Signal doesn't attempt to be a distributed eventually-consistent data store but simply a message transport. This is a trade-off which costs you some metadata leakage and is what leads to aggregations being a thing that is relevant for Matrix. It also gives you a lot of power, because you can now construct generic, distributed E2EE-enabled apps for "free".

That being said, there is still a lot of it that is up in the air. From what I've gathered, there's been talk about leaving aggregations to be done client-side specifically for reactions.

[kitkat_new]

> Note that new features apparently come unencrypted, even in otherwise encrypted rooms.

I checked that. While reactions are not encrypted indeed, a very recent feature - polls which are available in labs on Element Android - is encrypted.

[kitkat_new]

I understood it as the traffic that is received by clients and other homeservers wether it contains encrypted data or not.