[dead]
Re:Element raises $30M to boost Matrix
by emptysongglass on Tuesday July 27, 2021 @10:02AM
(#27972577)
I downvoted you (I'm not an employee or affiliated with Matrix in any way except that I selfhost Synapse because it's cool) because you've veered off the good faith criticism path into paranoia and what looks like a personal vendetta, which I can't understand what for.
This is a tech chat product but the way you dig into it makes it sound like you have bones to pick with someone who came to your house and killed your cat.
[dead]
Re:Element raises $30M to boost Matrix
by kazoomonger on Tuesday July 27, 2021 @11:51AM
(#27973878)
Looking at https://matrix.org/faq/, I see this:
Can I run my own identity server?
See also: What is an identity server?
Yes - the reference implementation is sydent and you can run your own ID server cluster that tracks 3rd party to Matrix ID mappings. This won't be very useful right now, though, and we don't recommend it.
If you want your server to participate in the global replicated Matrix ID service then please get in touch with us. Meanwhile, we are looking at ways of decentralising the 'official' Matrix identity service so that identity servers are 100% decentralised and can openly federate with each other. N.B. that you can use Matrix without ever using the identity service - it exists only to map 3rd party IDs (e.g. email addresses) to matrix IDs to aid user discovery.
The Element app even supports QR codes... It is super easy to start a chat with someone new
You come into every matrix comment section to grief Arathorn, you come off as the bad guy.
I think those "phonehome stats" are exactly what most people are up in arms about. Particularly the exhaustive non-depersonalized nature of them. [0]
It appears that the data which is collected includes [1]:
Message senders
Message senders are never encrypted
Session/device IDs
Due to Matrix's design, encrypting this would break verification
Message timestamps
It's impossible to prevent timestamps from leaking, since the server can simply note when an event is received anyway
Room members (join/leave/invite events)
Join/leave/invite and other room events are never encrypted
Message edit events
While contents are not leaked, an attacker can know when messages are edited
Message reactions
Reactions are never encrypted
Read receipts
Read receipts are never encrypted
Nicknames
Nicknames are never encrypted
Profile pictures
Profile pictures are never encrypted
The Matrix ID of users, usually including their username.
Email addresses, phone numbers of the user and their contacts.
Associations of Email, phone numbers with Matrix IDs.
Usage patterns of the user.
IP address of the user, which can give more or less precise geographical location information.
The user’s devices and system information.
The other servers that users talks to.
Room IDs, potentially identifying the Direct chat ones and the other user/server.
[0] <https://www.hackea.org/notas/matrix.html>
[1] <https://serpentsec.1337.cx/matrix>
[2] <https://www.hackea.org/notas/matrix.html#facing-the-real-and...>
no, the "phonehome stats" i was referring to are the opt-in anonymous aggregated usage stats that synapse provides: https://github.com/matrix-org/synapse/blob/master/synapse/ap... etc.
All the stuff you enumerate is metadata that your server stores in order to store your conversations. Until P2P Matrix lands, if you're worried about metadata, only talk to people on servers whose admins you trust.
Thanks for the clarification.
Congrats on your round. Best wishes for turning that into a robust truly decentralized E2EE communications platform that the average person won't shy from. Btw, I hope SNEK sticks!
Thanks :) Also, another improvement to protect metadata that we're working on is https://github.com/matrix-org/matrix-doc/blob/rav/proposal/r... (and relatedly https://github.com/matrix-org/matrix-doc/blob/neilalexander/...). By giving each sender in a given room its own public key, you can de-correlate the identities between rooms by blowing away the mapping that links a matrix ID to an identity in a given room. (Of course, a malicious actor could deliberately monitor this and de-de-correlate - to which P2P is the longer term solution.)
Oh yes, great. I was wondering yesterday if you'd looked at an approach like this, but hadn't gotten to looking at docs/code. Thanks for the pointers! It's definitely a good start for obfuscation.
Re:Element raises $30M to boost Matrix
by kitkat_new on Tuesday July 27, 2021 @11:11AM
(#27973375)
> Associations of Email, phone numbers with Matrix IDs.
Collected hashed at a identity server (you can choose) in case you decide that other people should be able to use the identity server to discover you via phone number
The lobsters comment is from me, a year ago, talking about the spec and implementation work published by the Matrix core team - i.e. the contents of https://github.com/matrix-org. Matrix started in 2014, and the core team formed Element in 2017 to fund its work, so it should hardly be surprising that much of that code comes from Element employees. Just as if Linus had chosen to fund himself to work on the linux kernel by creating a startup, the balance of code in the kernel would be different. Nowadays I'd guess it's more like 75% of the code at github.com/matrix-org which comes from Element employees contracted to work on Matrix by the Matrix.org Foundation.
However, across the wider ecosystem, Element's contributions are an increasingly small minority. There are completely new independent implementations out there like Conduit.rs (rust server) or the whole FluffyChat stack (cross-platform flutter clients) which have almost no contributions from Element and build on entirely different codebases to the reference implementations at https://github.com/matrix-org. So, where it counts, I'd guess that Element probably does <20% of the overall code in the Matrix ecosystem?
> Likewise, the vast majority (>80% anecdotally) of users on the main Matrix federated network live on a single instance centrally administered by matrix.org.
Looking at the phonehome stats, it's more like 30%.
> My worry is that the fate of Matrix rests on Element Co, which seems to be a default-dead start up
Nope, if you read the Element blog post at https://element.io/blog/element-raises-30m-as-matrix-explode..., you'll see that Element is explicitly default-alive.
> repeatedly needs to seek funding
Nope, we didn't need to seek funding in this instance; we consciously chose to. We could have just continued profitably at a slower rate, but we wanted to go faster in order to compete with Discord & Teams etc.
> and nearly went bust in the past.
Nope, Element was formed after we lost funding for the original Matrix work... which is why we formed the company.