Notes on privacy and data collection of Matrix.org (2019) • Hacker News Board

Re: Notes on privacy and data collection of Matrix.org (2019)

#21

Post by junon » Thu, Nov 04, 2021, 11:58 AM UTC

vorejdajo wrote: post #18

rglullis wrote: post #8

Earlier quoted context omitted.

I know it is going to sound like an ad-hominem, but once I realized that this is from the same person behind the "Grid protocol", I immediately closed the tab. This guy seems to be on a quixotic vendetta against msxid. It is the third or fourth persona (first it was from a personal account, then from his company, now he has even a non-profit advocating for privacy) that he created to re-hash the same old, outdated an…

It is ad-hominem and bias

Ad hom would be saying the author smells like moldy cheese and therefore we should disregard his opinion.

The parent comment is not using ad hom. They're critiquing the author's work and assessing their credibility based off of that. It's perfectly fine, and a great viewpoint to consider.

Re: Notes on privacy and data collection of Matrix.org (2019)

#22

Post by GekkePrutser » Thu, Nov 04, 2021, 12:35 PM UTC

southerntofu wrote: post #19

capableweb wrote: post #14

Earlier quoted context omitted.

> So, with that in mind: Kudos for such an analysis, but be mindful that such a lengthy document that discusses minor issues can actually harm the matrix project. Under "Purpose and Scope": > This document is a research paper by Libre Monde ASBL, nonprofit dedicated to protecting people's privacy. We had the need to document privacy points for The Grid Protocol project, fork of the Matrix protocol. So seems that they…

> So seems that they probably won't have issues with that it might harm Matrix, as they are a direct competitor. I was not aware of the Grid project, but they seem to make good points. Matrix is developed by a restricted group of people with a startup vibe and some cringy/questionable actions: - spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have be…

The Jitsi thing is going away, matrix already has its own video chat for 1:1 chats, and it's coming for rooms soon too. The Jitsi option was a temporary setup.

The clean rooms approach is a good thing I think. Xmpp is becoming a pileup of different add-ons and suffers from the same issues you mention for matrix (not all features supported by all clients). Probably in a worse way.

I know the reluctance of IRC operators to allow (global) matrix bridges is often a case of different paradigms. On IRC a conversation can only be seen by users who are present at the time. A user joining a bridged matrix room can see the entire history from before they joined. This changes the privacy model a lot (insofar as IRC has any semblance of privacy, but whatever is there is regarded as very important). People running their own Heisenbridge puppeting bridges solves this issue though.

I'm not a matrix dev but I do like it, especially the phenomenon of bridges.

Re: Notes on privacy and data collection of Matrix.org (2019)

#23

Post by gefhfff » Thu, Nov 04, 2021, 12:36 PM UTC

southerntofu wrote: post #19

capableweb wrote: post #14

Earlier quoted context omitted.

> So, with that in mind: Kudos for such an analysis, but be mindful that such a lengthy document that discusses minor issues can actually harm the matrix project. Under "Purpose and Scope": > This document is a research paper by Libre Monde ASBL, nonprofit dedicated to protecting people's privacy. We had the need to document privacy points for The Grid Protocol project, fork of the Matrix protocol. So seems that they…

> So seems that they probably won't have issues with that it might harm Matrix, as they are a direct competitor. I was not aware of the Grid project, but they seem to make good points. Matrix is developed by a restricted group of people with a startup vibe and some cringy/questionable actions: - spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have be…

> which takes us to the situation where Matrix has the exact same selling points which XMPP had 20 years ago... and keeps on reinventing the wheel

I don't get it. XMPP had MEGOLM, cross signing, decentralized chat rooms, good iOS support in practice, very simple sync of e2ee chat history, ... 20 years ago?

> spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have been a "simple" decentralized room extension of XMPP or any other established protocol) ;

This simply so wrong: Matrix was created exactly because if the failure of existing protocols [0]. And the mentioned extension was one failure in their mind.

[0]: https://matrix.org/faq/#why-has-no-one-done-this-before%3F

And imho it was the best thing to do. You don't repair a car if repairing costs much more than getting a new one

> pushing for a broken state resolution algorithm (decentralized consensus) without a formal analysis, which means it's now reached its 5th or 6th version and Matrix

In fact there are 9 versions today. Though afaik only one of them was due to a broken consensus algorithm. Others exist for new features. Strangely I can use even the latest ones with alternative clients such as Fluffy Chat - contrary to your claims

> but why is a Jitsi considered a decent extension mechanism

It is? Source needed

Native Matrix video chat is being implemented as of now

> putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms

Also wrong: Element has a native Android and a native iOS clie t

Re: Notes on privacy and data collection of Matrix.org (2019)

#24

Post by Zash » Thu, Nov 04, 2021, 12:38 PM UTC

southerntofu wrote: post #17

ThePhysicist wrote: post #12

IMHO, aspects like metadata and application security are often much more important than the cryptographic protocol when assessing the security of a system like a messenger. People e.g. love to celebrate the Signal protocol because of its double-ratchet key rotation scheme, which is of course great and provides a little bit of additional security, but the other technical and organizational aspects of the system are ju…

Unless something has changed in the past years, Signal and Matrix have this in common that any room you join displays your identifier for every one to see (phone number / MXID) publicly, leading to problems of harassment/spam. But i entirely agree with your point that relying on a single actor for updates/security is really the worst.

One of the nice things with XMPP, where in public channels your address is generally only shown to room moderators, not to all participants.

Re: Notes on privacy and data collection of Matrix.org (2019)

#25

Post by ajvs » Thu, Nov 04, 2021, 12:40 PM UTC

These issues I'd consider pretty crucial to approaching Signal-like privacy and there's not been much progress on them unfortunately: https://github.com/matrix-org/matrix-doc/pull/1769 https://github.com/vector-im/element-web/issues/11655 https://github.com/vector-im/element-web/issues/2320 https://github.com/vector-im/element-web/issues/2772 https://github.com/vector-im/element-web/issues/2458

Re: Notes on privacy and data collection of Matrix.org (2019)

#26

Post by fsflover » Thu, Nov 04, 2021, 12:47 PM UTC

ajvs wrote: post #25

These issues I'd consider pretty crucial to approaching Signal-like privacy and there's not been much progress on them unfortunately: https://github.com/matrix-org/matrix-doc/pull/1769 https://github.com/vector-im/element-web/issues/11655 https://github.com/vector-im/element-web/issues/2320 https://github.com/vector-im/element-web/issues/2772 https://github.com/vector-im/element-web/issues/2458

Unfortunately Signal is a walled garden actively fighting against alternative clients and servers. This is enough for me to avoid it and recommend Matrix. If you feel that those issues are critical, please donate your money or time to solve them.

Re: Notes on privacy and data collection of Matrix.org (2019)

#27

Post by EGreg » Thu, Nov 04, 2021, 12:54 PM UTC

fsflover wrote: post #26

ajvs wrote: post #25

These issues I'd consider pretty crucial to approaching Signal-like privacy and there's not been much progress on them unfortunately: https://github.com/matrix-org/matrix-doc/pull/1769 https://github.com/vector-im/element-web/issues/11655 https://github.com/vector-im/element-web/issues/2320 https://github.com/vector-im/element-web/issues/2772 https://github.com/vector-im/element-web/issues/2458

Unfortunately Signal is a walled garden actively fighting against alternative clients and servers. This is enough for me to avoid it and recommend Matrix. If you feel that those issues are critical, please donate your money or time to solve them.

In terms of closed centralized services, I’d say Telegram is my top pick, followed by Signal. But I would take open source decentralized networks over them anyday, and my favorite is Freenet, or the much newer network, MaidSAFE because it is the most secure thing I have ever seen (but that’s not mainstream yet).

Re: Notes on privacy and data collection of Matrix.org (2019)

#28

Post by mikro2nd » Thu, Nov 04, 2021, 12:54 PM UTC

ThePhysicist wrote: post #12

IMHO, aspects like metadata and application security are often much more important than the cryptographic protocol when assessing the security of a system like a messenger. People e.g. love to celebrate the Signal protocol because of its double-ratchet key rotation scheme, which is of course great and provides a little bit of additional security, but the other technical and organizational aspects of the system are ju…

An project that looks interesting to me is Cwtch, precisely for its focus on metadata leak-resistance. It seems to be more of a research-focussed project right now, but I think looking in exactly the right direction.

Re: Notes on privacy and data collection of Matrix.org (2019)

#29

Post by fsflover » Thu, Nov 04, 2021, 12:56 PM UTC

EGreg wrote: post #27

fsflover wrote: post #26

Earlier quoted context omitted.

Unfortunately Signal is a walled garden actively fighting against alternative clients and servers. This is enough for me to avoid it and recommend Matrix. If you feel that those issues are critical, please donate your money or time to solve them.

In terms of closed centralized services, I’d say Telegram is my top pick, followed by Signal. But I would take open source decentralized networks over them anyday, and my favorite is Freenet, or the much newer network, MaidSAFE because it is the most secure thing I have ever seen (but that’s not mainstream yet).

How about Ricochet instant messenger or I2P?

Re: Notes on privacy and data collection of Matrix.org (2019)

#30

Post by ulzeraj » Thu, Nov 04, 2021, 1:01 PM UTC

INTPenis wrote: post #9

akvadrako wrote: post #5

Earlier quoted context omitted.

I've never heard of Tox, but it doesn't even have an iOS client. That's a good reason to ignore it.

That's such a silly statement when you're a slave to Apple, which is closed source. You could be using an open source, non-googled, android OS with an open source Tox or Briar client.

I do care about all those things but after that response I might keep ignoring Tox for a while.