I've been revisiting moving to self hosted Matrix around every 4 months now for 2 years, and every single time I failed.
The reasons vary; initially synapse refused to work, then I got stuck trying to set up a multi-domain service.
That said, this document verifies what I feared in the background: what matrix offers as self-hosted is too simple to be true, and thus it's no surprising I never got it completely running.
XMPP has it's own issues, but when I self host it, it's there, nowhere else. No identity servers, no push servers, no jitsi servers in the background.
It seems like I'm going to be with XMPP for a much longer time.
Matrix tries to do a lot more than XMPP. In my experience, people find XMPP too limiting, so they don't use it.
It's not that simple. Many doesn't know about omemo, jingle, etc, when it comes to xmpp. Or xmpp bridges like biboumi.
Matrix is is doing the same thing, but on differrent - and way more complicated - infrastructure ideas.
Prosody is definitely much simpler to configure, even with multiple domains, especially when per domain specific setting are needed.
How about removing the ability to copy text? Or the ability to take screenshots?
The following stack will be used as reference, with users
connecting via web, desktop and smartphone clients:
Client: Riot-web v1.2.1,
Riot Desktop v1.2.1,
Riot Android v0.9.1
Server: Synapse v1.0.0
Unfortunately, it might not be a good idea to trusting that a version number consistently maps to a specific URL, or that a server will give the same file to everyone each time they ask fo a URL. We know that sending different versions to different people is common ("A/B testing"). If you're investigating the security of something or worse: you suspect you might have sentient opponents actively trying to deceive you, then version numbers are no longer sufficient: you should also include cryptographic checksums! The only way you can know that the file you received is the same is if you have e.g. SHA-2 hashes as proof. Even better, if it's important, include the RIPEMD-160, SHA-1, CRC32, and any other available hash/checksum because why not add redundancy and give people options.
$ sha256sum *
e406bcc...51c199a riot-android-0.9.1.tar.gz
8020cc6...d6126c1 riot-v1.2.1.tar.gz
443b612...51e0cef synapse-1.0.0.tar.gz
In the interest of making a reproducible investigation, it might be a good idea to include hashes for the specific packages being investigates.
> Give the git commit hash maybe?
That would probably work? This gets into the problem of reproducible builds, where builds from different environments might not be identical. This means documenting that you used "a build of version 1.2.1 git commit 7446799e4b0e3e65122f5642b5f3a8c59aae15bf" means something slightly different than saying you used "riot-v1.2.1.tar.gz with SHA256 8020cc617367a4318be090b1562a26571f1a3417b0d4a52b2d4f19e03d6126c1". That said, obviously having literally any hash to work from is much better than using version numbers alone.
Github links that include the commit hash might be useful, but it seems like you cannot link to both a tag and a hash? I wonder if github supports links that are a combination of https://github.com/vector-im/riot-web/releases/tag/v1.2.1 and https://github.com/vector-im/riot-web/commit/7446799e4b0e3e6... ?
Matrix devs, instead of battling the reviewer here, please make a proper blog post and explain what is really going on here. Tell us the truth about your data handling and the data retention.
The reviewer did his own share of work. If there are mistaken parts in his reporting, please correctly explain them in a civilized way in a possible blog post.
thanks
Yeah, the issue with all these replies is that the real replies that addresses the issues can be lost. I really recommend that you put that on your official blog so we all can benefit from reading your response.
Much to improve.
Agreed that we should do better at presenting a max-privacy config preset and explaining how identity/integ/notary servers work to users (without making the UX unusable), but to throw away the whole project over this is throwing out the baby with the bathwater, imo.
"Riot needs permission to access your address book contacts to find other Matrix users based on their email and phone numbers. Please allow access on the next pop-up to discover address book users reachable from Riot."
That said, this analysis does have a few valid points in it, specifically:
* We should probably provide a click-thru when users interact with 3rd party identity lookup servers or integration managers
* We should hash contacts when doing bulk lookups
* Riot/Web has a bug where it talks to the integration manager too frequently (https://github.com/vector-im/riot-web/issues/5846)
* Notary servers should eventually be removed entirely (as per MSC1228).
However, most of the rest of it is alarmist and disproportionate FUD, plus the author has sadly forgotten to disclose that he's working on a hostile fork of Matrix. A point by point response is at https://matrix.org/~matthew/Response_to_-_Notes_on_privacy_a... fwiw (apologies for the PDF, but Google Docs doesn't seem to expose a read-only view of commented docs.)
Please don't say please to make people perform questionable privacy violations. How about:
"If you want Riot to determine which of your contacts also use Matrix and to easily enable you to talk to them via Riot, you can allow Riot to access your contact list.
Note: This will upload all your contacts' details, as stored on your phone, including addresses, birthdays, notes, and more if available to matrix.org. Here is the privacy policy."
Or something like that, whatever it really does.
Disclaimer: I like matrix :)))
I know very well that concise wording in UIs is incredibly hard, but this wording is misleading. It makes it sound like Riot will not work unless I allow access to the address book. I'd suggest something like this:
> Riot can check your address book to find other Matrix users based on their email and phone numbers. If you agree to sharing your address book for this purpose, please allow access on the next pop-up.
The document is clear that it puts the default behaviour and explanation next to what users understand out of it and expect, just like what the privacy policy of Matrix.org is based of in section 2.1.1. We have asked several technical and non-technical people alike, from our family members to our friends to people in our communities. And the feedback is unanimous: They did not understand nor expect what we described.
In terms of actually of handling the issues, the scalar issue is one we brought up with Ben months ago in private as per your disclosure policy, and yet nothing was done. This is just an example of a long list of issues brought up over the years.
The point of the document is not to find justification for what is happening, but to inform users that it is happening. An attacker got access to your systems which contained logs from which such data can be gathered. It is important that users who self-host and do not expect such data to get out realize that it does so they can take appropriate action.
The document might feel alarmist, certainly. It does not feel alarmist because we wrote it. It feels alarmist because the behaviour described is happening and nothing is done about it. It is not discussed anywhere. Attempts to do so are shut down. But it does not change anything: leaks are happening right now on thousands of servers and for millions of users (up to 9M, as per Matrix.org figure) and every person who we showed this to before publishing had the same reaction: "I never expected such data to go out like this. I am worried".
As for Grid, we made a specific effort out of respect for the Matrix.org people not to mention it or steer towards it. Yes we have forked Matrix. No it is not hostile, despite your continuous claims to label it as such.
We think it is time to stop talking about all the good reasons why, in the 5 years it took to get Matrix out of beta, there was just no time to deal with such leaks. We think it is time to start talking about how we can make sure it stops from happening and which decisions lead to it happening for so long unnoticed.
You wrote the software. Start respecting your users privacy.
This is way better than the behavior of proprietary programs, but I'd much prefer if the program actively discouraged uploading private information. I can deny the permission myself, but there's not much I can do about other people's behavior, and with the way Riot currently works they are going to end up uploading my personal information.
A client that isn't even able to access contacts is one of my top wishes for Matrix right now. As soon as that appears I'm going to start recommending it to everyone over miniVector.
> If you don't specify an email address, you won't be able to reset your password. Are you sure?
In your response on pg. 4, you say:
> Commented [11]: Yup, this is the point of the service -to map email addresses and phone numbers to matrix IDs.
Is it possible to specify an e-mail address to be able to reset passwords without making this e-mail address public? Clearly, this should be the default setting if someone enters an e-mail address after the above prompt by Riot.
access != upload
This is the same wording how Facebook/LinkedIn/etc got our contact list.
Also:
> a hostile fork
What? Matrix is Free Software. There is no such thing as "hostile fork".
https://gist.github.com/maxidorius/5736fd09c9194b7a6dc03b6b8...
* You could fully encrypt push notifications?
We encourage anyone who already read the initial version to check out the revisions of it for new content or re-visit the document.