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

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

#81

Post by Arathorn » Thu, Nov 04, 2021, 6:03 PM UTC

ryukafalz wrote: post #38

southerntofu wrote: post #19

Earlier quoted context omitted.

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

> 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 clients are all incompatible with one another (because only Element implements them all) and once they have been upgraded rooms cannot be downgraded so in many places only Element can chat This is false. Clients don't do state res, servers do. Clients do…

Meanwhile on the serverside, there have only been two versions of state resolution; the original beta version that turned out to be buggy, and the current fixed one which has been heavily scrutinized and is okay: https://matrix.org/blog/2020/06/16/matrix-decomposition-an-i....

The amount of incorrect info in the GP post is very unfortunate - although I too wish that open standard comms protocols spent more time collaborating than spitting at each other.

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

#82

Post by fsflover » Thu, Nov 04, 2021, 6:27 PM UTC

shapefrog wrote: post #70

m-p-3 wrote: post #34

Earlier quoted context omitted.

And Signal forces you to use your phone number as your identifier, which can be traced relatively easily to a person or at least a geographical position by the authorities. The content of the message might be encrypted, but metadata can provide valuable intelligence insights. At least Matrix can be used mostly anonymously through a user-generated identifier, without an email address or phone number, and can be used t…

> And Signal forces you to use your phone number as your identifier Signal forces you to use "a" phone number as your identifier. It does not have to be your primary phone number, or home phone number or office phone number. Just a phone number that you have control of.

> Just a phone number that you have control of.

In most parts of the world, you cannot get "just" a phone number not tied to your real identity.

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

#83

Post by fsflover » Thu, Nov 04, 2021, 6:30 PM UTC

EGreg wrote: post #78

XorNot wrote: post #41

Earlier quoted context omitted.

Telegram is not encrypted E2E by default at all.

I don’t need it encrypted BY DEFAULT. If I want to encrypt something, I can. It also means the chats aren’t available on other devices and you lose other capabilities

> It also means the chats aren’t available on other devices

Not, it doesn't. You would just need to copy the private key to the other devices.

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

#84

Post by tptacek » Thu, Nov 04, 2021, 6:37 PM UTC

fsflover wrote: post #75

tptacek wrote: post #71

Earlier quoted context omitted.

I agree that security isn't everything there is to want from a messenger. But when the question being asked is "which messengers are secure", it is the only question that matters .

No, there is also a question "how long can this messenger stay secure?" In case of Signal, IMHO, the answer is "not very long".

None of what you've said to support that argument sounded persuasive to me. I think it's a pretty transparent rhetorical sleight of hand to say "the only way things can actually be secure in the long run is for them to be federated the way I want them to be". I get it, you want to run federated systems that you can build your own clients for. The evidence for those kinds of systems being the most private runs strongly in the opposite direction.

Would you like an example that's especially relevant to this thread? Because I can provide you with one.

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

#85

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

tptacek wrote: post #84

fsflover wrote: post #75

Earlier quoted context omitted.

No, there is also a question "how long can this messenger stay secure?" In case of Signal, IMHO, the answer is "not very long".

None of what you've said to support that argument sounded persuasive to me. I think it's a pretty transparent rhetorical sleight of hand to say "the only way things can actually be secure in the long run is for them to be federated the way I want them to be". I get it, you want to run federated systems that you can build your own clients for. The evidence for those kinds of systems being the most private runs strongl…

> "the only way things can actually be secure in the long run is for them to be federated the way I want them to be"

I never mentioned any particular kind of federation that I prefer. I also never mentioned word "private", which is mostly tangential to federation.

My point is that, in the long run, only federated systems are sustainable, because nobody is able to fund huge servers with millions of users without infinite money. For example, Signal and Telegram are both struggling with that currently; the latter introduced advertisement recently. On the other hand, Mastodon does not seem to have such problem (you could argue that it's too early though).

I do not want to build my own clients, I'm not even a programmer. I want a sustainable network, which could be achieved by a large number of self-hosted instances federated with (possibly) large servers. It has been working fine with email for decades. Also, the competition of various independent clients improves the user experience (like any other healthy competition elsewhere).

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

#86

Post by snark42 » Thu, Nov 04, 2021, 7:20 PM UTC

fsflover wrote: post #82

shapefrog wrote: post #70

Earlier quoted context omitted.

> And Signal forces you to use your phone number as your identifier Signal forces you to use "a" phone number as your identifier. It does not have to be your primary phone number, or home phone number or office phone number. Just a phone number that you have control of.

> Just a phone number that you have control of. In most parts of the world, you cannot get "just" a phone number not tied to your real identity.

Prepaid cellular phones and Google Voice aren't available in most parts of the world with a little effort?

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

#87

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

snark42 wrote: post #86

fsflover wrote: post #82

Earlier quoted context omitted.

> Just a phone number that you have control of. In most parts of the world, you cannot get "just" a phone number not tied to your real identity.

Prepaid cellular phones and Google Voice aren't available in most parts of the world with a little effort?

I was speaking about the prepaid cellular phones. Again, in most parts of the world, you cannot get an anonymous sim-card. AFAIK you also cannot create a Google account without a phone number.

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

#88

Post by growse » Thu, Nov 04, 2021, 7:48 PM UTC

fsflover wrote: post #85

tptacek wrote: post #84

Earlier quoted context omitted.

None of what you've said to support that argument sounded persuasive to me. I think it's a pretty transparent rhetorical sleight of hand to say "the only way things can actually be secure in the long run is for them to be federated the way I want them to be". I get it, you want to run federated systems that you can build your own clients for. The evidence for those kinds of systems being the most private runs strongl…

> "the only way things can actually be secure in the long run is for them to be federated the way I want them to be" I never mentioned any particular kind of federation that I prefer. I also never mentioned word "private", which is mostly tangential to federation. My point is that, in the long run, only federated systems are sustainable, because nobody is able to fund huge servers with millions of users without infin…

Dismissing a platform that's solving real problems for real people right now because it might not exist in 5 years is a pretty weird thing to do.

"Sustainability" is arbitrary. Everything burns eventually.

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

#89

Post by tptacek » Thu, Nov 04, 2021, 10:04 PM UTC

fsflover wrote: post #85

tptacek wrote: post #84

Earlier quoted context omitted.

None of what you've said to support that argument sounded persuasive to me. I think it's a pretty transparent rhetorical sleight of hand to say "the only way things can actually be secure in the long run is for them to be federated the way I want them to be". I get it, you want to run federated systems that you can build your own clients for. The evidence for those kinds of systems being the most private runs strongl…

> "the only way things can actually be secure in the long run is for them to be federated the way I want them to be" I never mentioned any particular kind of federation that I prefer. I also never mentioned word "private", which is mostly tangential to federation. My point is that, in the long run, only federated systems are sustainable, because nobody is able to fund huge servers with millions of users without infin…

Yeah. How'd that work out for Matrix? Here's a hint: find out when the project was started, and when the network first required end-to-end encryption. Warning: the answer to that entirely vindicates Signal's position on federation; you may not like it.

That doesn't make Matrix bad. It makes Matrix different. Matrix has different goals than Signal, and those goals simply prioritize security and privacy differently than Signal does.

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

#90

Post by Arathorn » Thu, Nov 04, 2021, 10:23 PM UTC

tptacek wrote: post #89

fsflover wrote: post #85

Earlier quoted context omitted.

> "the only way things can actually be secure in the long run is for them to be federated the way I want them to be" I never mentioned any particular kind of federation that I prefer. I also never mentioned word "private", which is mostly tangential to federation. My point is that, in the long run, only federated systems are sustainable, because nobody is able to fund huge servers with millions of users without infin…

Yeah. How'd that work out for Matrix? Here's a hint: find out when the project was started, and when the network first required end-to-end encryption. Warning: the answer to that entirely vindicates Signal's position on federation; you may not like it. That doesn't make Matrix bad. It makes Matrix different . Matrix has different goals than Signal, and those goals simply prioritize security and privacy differently th…

I'll bite: we first created Matrix in 2014; we started implementing E2EE in 2016 and we turned it on by default in 2020. The reason it took so long was because we focused first on getting decentralisation (not federation) correct, and then the protocol started to get prematurely successful and we got sucked into ensuring the implementations (and spec) scaled and the governance was correct... even before E2EE was stable enough to be on by default.

You're completely right that we have different goals to Signal (openness + freedom rather than privacy-at-all-costs), but I'm not sure that blaming federation is the right answer here. We just prioritised building an open standard over having E2EE from day 1, instead choosing to design things so we could add it later.