🆕 Software Suggestion | Matrix (Riot/Synapse) #1389

Closed
opened 2019-10-10 02:45:30 +00:00 by jonah · 35 comments
Owner

Basic Information

Name: Matrix (Riot)
Category: RTC > Team Chat Platforms
URL: https://about.riot.im/

Name: Matrix (Synapse)
Category: RTC > ?
URL: https://matrix.org/docs/guides/installing-synapse
I think we need to mention Synapse specifically and encourage self-hosting over using the matrix.org homeserver, or really any public homeserver whenever possible. I don't know if this should be mentioned in the Riot listing, or if we should have a separate category for RTC servers.

Description

Since Riot was last reviewed, they have added a number of privacy-centric improvements. This is not a complete list, but these are issues we previously defined as major blockers:

There are a few unfixed issues, but I don't know if they are blockers to recommendation or not, so that's what I want to discuss here.

Finally, there are a few more "major" concerns we've voiced that have not yet been fixed, but that I do not think are blockers at all.

  • Matrix.org uses Cloudflare
    • Services using Cloudflare has historically not been a blocker for recommendation. I personally don't see it as a "major" issue at all.
    • End-to-End Encrypted chats are not really affected by this, and should be used whenever sensitive messages are being communicated.
    • Finally, during this re-listing we definitely want to discourage the use of matrix.org anyways to promote decentralization.
  • https://github.com/vector-im/riot-web/issues/10167: Present an aggregated terms of service dialogue at registration if possible
    • Operators of custom Riot servers can specify ToS, Privacy Notices, etc. in config.json, no?
    • The functionality I wanted does exist, whoops!
  • Riot X identity server is not configurable. https://github.com/vector-im/riotX-android/issues/20
    • For privacy reasons a hardcoded IS seems unacceptable, but is Riot X currently recommended for public use? I don't think we can judge the project based on an incomplete client.
    • In addition to being in beta, identity server functionality is not implemented at all.

All the other issues within https://github.com/privacytoolsIO/privacytools.io/issues/1049 are still important to monitor but I don't think the issues not mentioned above are blockers and are mostly small issues.

Anyhow, it seems clear to me that the Matrix team is at least committed to fixing their issues. For instant messengers I would still probably prefer Signal or Wire, but for a more public, large group chat use-case there does not appear to be any better alternatives to Matrix, especially from a privacy standpoint. This is why we still use it ourselves. It seems especially disingenuous to recommend XMPP over Matrix.

Also, I think that by advertising our group chat on Matrix without recommending Matrix itself we are both sending a mixed message and promoting centralization on our own server, by not demonstrating the alternatives (hosting it yourself).

## Basic Information **Name:** Matrix (Riot) **Category:** RTC > Team Chat Platforms **URL:** https://about.riot.im/ **Name:** Matrix (Synapse) **Category**: RTC > ? **URL:** https://matrix.org/docs/guides/installing-synapse I think we need to mention Synapse specifically and encourage self-hosting over using the matrix.org homeserver, or really any public homeserver whenever possible. I don't know if this should be mentioned in the Riot listing, or if we should have a separate category for RTC *servers*. ## Description Since Riot was last reviewed, they have added a number of privacy-centric improvements. This is not a complete list, but these are issues we previously defined as *major* blockers: - [x] Redacted messages are now removed from the database. https://github.com/matrix-org/synapse/issues/1287 - [x] Integration managers can now be easily controlled by the user. https://github.com/vector-im/riot-web/issues/10161 - [x] The identity server now appears to be stored in account data, and more importantly can now be modified or removed in user settings. https://github.com/vector-im/riot-web/issues/10094 There are a few unfixed issues, but **I don't know if they are blockers to recommendation or not, so that's what I want to discuss here.** - [ ] Matrix seems to store a *lot* of unnecessary metadata https://github.com/matrix-org/synapse/issues/4565 - **Edit:** The majority of this issue appears to be addressed: https://github.com/matrix-org/synapse/issues/4565#issuecomment-540320761 - [x] Homeserver data does not expire https://github.com/matrix-org/matrix-doc/issues/447 - **Edit:** A fix for this issue has been designed and will soon be implemented: https://github.com/matrix-org/matrix-doc/issues/447#issuecomment-540321546 - Seeing as redactions *are* evidently erased I don't think this is a huge issue. This is a problem for HS admins who may not want to maintain data infinitely but it doesn't seem like a privacy problem to me. Even if this was implemented it would be up to the HS admins, and one HS could choose to store data infinitely anyways (i.e. users should not assume their data will ever be erased even after implementation), - [ ] Media is never redacted https://github.com/matrix-org/synapse/issues/1263 - [x] Private contact discovery is not implemented https://github.com/vector-im/riot-web/issues/7649 - We have this listed as a blocker in #1049 but I don't see this as a *major* issue. This would be more of a useful feature. The *privacy* concern here is with using an IS, but that can now be easily disabled, correct? - **Edit:** The functionality as described in this issue doesn't sound like it will be implemented, but it appears that a more privacy-friendly contact discovery method than the old method has been implemented: https://github.com/vector-im/riot-web/issues/7649#issuecomment-540322593 Finally, there are a few more "major" concerns we've voiced that have not yet been fixed, but that I do not think are blockers at all. - Matrix.org uses Cloudflare - Services using Cloudflare has historically not been a blocker for recommendation. I personally don't see it as a "major" issue at all. - End-to-End Encrypted chats are not really affected by this, and should be used whenever sensitive messages are being communicated. - Finally, during this re-listing we definitely want to discourage the use of matrix.org anyways to promote decentralization. - ~~https://github.com/vector-im/riot-web/issues/10167: Present an aggregated terms of service dialogue at registration if possible~~ - ~~Operators of custom Riot servers can specify ToS, Privacy Notices, etc. in `config.json`, no?~~ - The functionality I wanted [*does* exist](https://github.com/matrix-org/synapse/blob/master/docs/consent_tracking.md), whoops! - ~~Riot X identity server is not configurable. https://github.com/vector-im/riotX-android/issues/20~~ - ~~For privacy reasons a hardcoded IS seems unacceptable, but is Riot X currently recommended for public use? I don't think we can judge the project based on an incomplete client.~~ - In addition to being in beta, identity server functionality is not implemented at all. All the other issues within https://github.com/privacytoolsIO/privacytools.io/issues/1049 are still important to monitor but I don't think the issues not mentioned above are blockers and are mostly small issues. Anyhow, it seems clear to me that the Matrix team is at least committed to fixing their issues. For instant messengers I would still probably prefer Signal or Wire, but for a more public, large group chat use-case there does not appear to be any better alternatives to Matrix, especially from a privacy standpoint. This is why we still use it ourselves. It seems especially disingenuous to recommend XMPP over Matrix. Also, I think that by advertising our group chat on Matrix without recommending Matrix itself we are both sending a mixed message *and* promoting centralization on our own server, by not demonstrating the alternatives (hosting it yourself).
dngray commented 2019-10-10 03:03:16 +00:00 (Migrated from github.com)
Author
Owner

I support this. It would make https://github.com/privacytoolsIO/privacytools.io/issues/1377 a lot simpler too.

All the other issues within #1049 are still important to monitor but I don't think the issues not mentioned above are blockers and are mostly small issues.

Anyhow, it seems clear to me that the Matrix team is at least committed to fixing their issues. For instant messengers I would still probably prefer Signal or Wire, but for a more public, large group chat use-case there does not appear to be any better alternatives to Matrix, especially from a privacy standpoint. This is why we still use it ourselves. It seems especially disingenuous to recommend XMPP over Matrix.

Also, I think that by advertising our group chat on Matrix without recommending Matrix itself we are both sending a mixed message and promoting centralization on our own server, by not demonstrating the alternatives (hosting it yourself).

Could not have put it better myself.

I support this. It would make https://github.com/privacytoolsIO/privacytools.io/issues/1377 a lot simpler too. > All the other issues within #1049 are still important to monitor but I don't think the issues not mentioned above are blockers and are mostly small issues. > > Anyhow, it seems clear to me that the Matrix team is at least committed to fixing their issues. For instant messengers I would still probably prefer Signal or Wire, but for a more public, large group chat use-case there does not appear to be any better alternatives to Matrix, especially from a privacy standpoint. This is why we still use it ourselves. It seems especially disingenuous to recommend XMPP over Matrix. > > Also, I think that by advertising our group chat on Matrix without recommending Matrix itself we are both sending a mixed message _and_ promoting centralization on our own server, by not demonstrating the alternatives (hosting it yourself). Could not have put it better myself.
ara4n commented 2019-10-10 03:30:50 +00:00 (Migrated from github.com)
Author
Owner

Several of the issues listed here as unfixed are actually fixed - i've gone through updating the bugs in question to try to make it clear, but specifically:

Several of the issues listed here as unfixed are actually fixed - i've gone through updating the bugs in question to try to make it clear, but specifically: * almost all of https://github.com/matrix-org/synapse/issues/4565 is addressed * https://github.com/matrix-org/matrix-doc/issues/447 is designed & implemented (but being tested on the French matrix deployment before being merged into mainline) * https://github.com/vector-im/riot-web/issues/7649 was implemented (i've closed the bug) * https://github.com/vector-im/riot-web/issues/10167 is just UX eye-candy; having the option to present the policies at registration rather than incrementally as the user stumbles across the services in question. I'm not convinced we should do it at all, given it makes the user less likely to read the policies and understand what they relate to. * https://github.com/vector-im/riotX-android/issues/20 is a non-issue; the only reason that RiotX doesn't expose a configurable identity server URL is because it hasn't implemented any identity service functionality yet(!).
Author
Owner

Thank you @ara4n, I've updated the issue.

Re 10167 I was confused, I actually wasn't aware consent tracking existed. Don't know how that slipped by me, but since that's the case I do agree the current implementation is probably better. Sorry about that!

Thank you @ara4n, I've updated the issue. Re 10167 I was confused, I actually wasn't aware [consent tracking](https://github.com/matrix-org/synapse/blob/master/docs/consent_tracking.md) existed. Don't know how that slipped by me, but since that's the case I do agree the current implementation is probably better. Sorry about that!
blacklight447 commented 2019-10-10 06:03:40 +00:00 (Migrated from github.com)
Author
Owner

I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats.

I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats.
dngray commented 2019-10-10 06:58:46 +00:00 (Migrated from github.com)
Author
Owner

I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats.

If that's the case we should not recommend any XMPP clients as they do not have it on by default either; and likely never will do.

Perhaps a warning badge and a link to step-by-step guide in enabling it in Riot would do? We know that E2EE is going to be on by default for 1:1 chats with Riot https://github.com/vector-im/riot-web/issues/6779 at some time in the future.

> I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats. If that's the case we should not recommend any XMPP clients as they do not have it on by default either; and likely never will do. Perhaps a warning badge and a link to step-by-step guide in enabling it in Riot would do? We know that E2EE is going to be on by default for 1:1 chats with Riot https://github.com/vector-im/riot-web/issues/6779 at some time in the future.
dawidpotocki commented 2019-10-10 07:06:37 +00:00 (Migrated from github.com)
Author
Owner

I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats.

If that's the case we should not recommend any XMPP clients as they do not have it on by default either; and likely never will do.

Conversations uses OMEMO by default for sure.

> > I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats. > > If that's the case we should not recommend any XMPP clients as they do not have it on by default either; and likely never will do. Conversations uses OMEMO by default for sure.
dngray commented 2019-10-10 07:09:38 +00:00 (Migrated from github.com)
Author
Owner

Conversations uses OMEMO by default for sure.

But does everyone use conversations on Android?

> Conversations uses OMEMO by default for sure. But does everyone use conversations on Android?
dawidpotocki commented 2019-10-10 07:12:50 +00:00 (Migrated from github.com)
Author
Owner

Conversations uses OMEMO by default for sure.

But does everyone use conversations on Android?

Do you know anyone who doesn't? I'm pretty sure it's most popular XMPP
client for Android and there are also few forks like Quicksy, which also
use OMEMO by default.

> > Conversations uses OMEMO by default for sure. > > But does everyone use conversations on Android? Do you know anyone who doesn't? I'm pretty sure it's most popular XMPP client for Android and there are also few forks like Quicksy, which also use OMEMO by default.
dngray commented 2019-10-10 07:13:55 +00:00 (Migrated from github.com)
Author
Owner

Quicksy

afaik that's fork of Conversations that uses phone numbers as an identifier.

What about if you're not on Android.

> Quicksy afaik that's fork of Conversations that uses phone numbers as an identifier. What about if you're not on Android.
dawidpotocki commented 2019-10-10 07:29:48 +00:00 (Migrated from github.com)
Author
Owner

What about if you're not on Android.

ChatSecure (iOS) is using OMEMO too.

> What about if you're not on Android. ChatSecure (iOS) is using OMEMO too.
dngray commented 2019-10-10 07:54:40 +00:00 (Migrated from github.com)
Author
Owner

What about if you're not on Android.
ChatSecure (iOS) is using OMEMO too.

Does it support E2EE by default? I can't definitively find anywhere where it says it does, i would have thought that would have been worth mentioning on their blog https://chatsecure.org/blog/

> What about if you're not on Android. > ChatSecure (iOS) is using OMEMO too. Does it support E2EE by default? I can't definitively find anywhere where it says it does, i would have thought that would have been worth mentioning on their blog https://chatsecure.org/blog/
dawidpotocki commented 2019-10-10 07:56:04 +00:00 (Migrated from github.com)
Author
Owner

ChatSecure (iOS) is using OMEMO too.

Does it support E2EE by default?

Yes, I just checked it.

> > ChatSecure (iOS) is using OMEMO too. > > Does it support E2EE by default? Yes, I just checked it.
dngray commented 2019-10-10 08:33:08 +00:00 (Migrated from github.com)
Author
Owner

ChatSecure (iOS) is using OMEMO too. Does it support E2EE by default?
Yes, I just checked it.

And what if you want to access in a web browser (public/friends computer), a desktop or some other platform like maybe a Librem, the point is you're going to have to know where to click on all platforms (some you may not even know) when instructing friends to do things. When their client crashes, or has some issue, "works for me on my platform" isn't going to be an answer they will accept.

Nothing is perfect, (no software is), but taking the pragmatic approach and suggesting something that is just going to annoy people is not really going to help privacytools.io the likely result is that people will just stay with their offering from Facebook, Inc. or maybe consider Signal, though that requires a phone number (something plenty of people I know who are tech noobs are not happy to hand out).

What we really need to decide is, is it too difficult to show a user how to enable E2EE on a 1:1 conversation in Riot? - we can do that with pretty pictures. ie:

  1. Clicking a contact's name
  2. Clicking "Security & Privacy"
  3. Toggling "Encryption" to the on position.

Should also be noted that once a user does that it cannot be disabled, (something that might happen if you use an XMPP client that doesn't have OMEMO on by default, "Never send encrypted messages to unverified devices in this room from this device" seems pretty explanatory too.

I would also argue that emoji fingerprint verification is far less daunting than a huge alphanumeric fingerprint. (QR only really works if you are in the same room as the person you're trying to verify).

> > ChatSecure (iOS) is using OMEMO too. Does it support E2EE by default? > Yes, I just checked it. And what if you want to access in a web browser (public/friends computer), a desktop or some other platform like maybe a [Librem](https://puri.sm/products/librem-5/), the point is you're going to have to know where to click on all platforms (some you may not even know) when instructing friends to do things. When their client crashes, or has some issue, "works for me on my platform" isn't going to be an answer they will accept. Nothing is perfect, (no software is), but taking the pragmatic approach and suggesting something that is just going to annoy people is not really going to help privacytools.io the likely result is that people will just stay with their offering from Facebook, Inc. or maybe consider Signal, though that requires a phone number (something plenty of people I know who are tech noobs are not happy to hand out). What we really need to decide is, is it too difficult to show a user how to enable E2EE on a 1:1 conversation in Riot? - we can do that with pretty pictures. ie: 1. Clicking a contact's name 2. Clicking "Security & Privacy" 3. Toggling "Encryption" to the on position. Should also be noted that once a user does that it cannot be disabled, (something that might happen if you use an XMPP client that doesn't have OMEMO on by default, "Never send encrypted messages to unverified devices in this room from this device" seems pretty explanatory too. I would also argue that emoji fingerprint verification is far less daunting than a huge alphanumeric fingerprint. (QR only really works if you are in the same room as the person you're trying to verify).
blacklight447 commented 2019-10-10 10:03:38 +00:00 (Migrated from github.com)
Author
Owner

Thing is, end to end is the default on all other platforms we basically recommend. I wouldn't see why riot deserve an exception here. Plus, they announced to make it default very soon, so it cannot hurt to wait for it a little longer.

Thing is, end to end is the default on all other platforms we basically recommend. I wouldn't see why riot deserve an exception here. Plus, they announced to make it default very soon, so it cannot hurt to wait for it a little longer.
dngray commented 2019-10-10 10:16:44 +00:00 (Migrated from github.com)
Author
Owner

Thing is, end to end is the default on all other platforms we basically recommend.

Well except for the current XMPP clients, we recommend. Do we know if Monal supports E2EE by default? I don't think it uses E2EE for it's jingle transport https://github.com/anurodhp/Monal/issues/10 https://github.com/anurodhp/Monal/issues/267

I am pretty sure Gajim doesn't.

Perhaps we should consider a warning badge?

The rocky road to OMEMO by default probably a bit outdated, but it does talk about this issue.

I wouldn't see why riot deserve an exception here. Plus, they announced to make it default very soon, so it cannot hurt to wait for it a little longer.

I guess we can always wait.

> Thing is, end to end is the default on all other platforms we basically recommend. Well except for the current XMPP clients, we recommend. Do we know if [Monal](https://monal.im/) supports E2EE by default? I don't think it uses E2EE for it's jingle transport https://github.com/anurodhp/Monal/issues/10 https://github.com/anurodhp/Monal/issues/267 I am pretty sure [Gajim](https://gajim.org) doesn't. Perhaps we should consider a warning badge? [The rocky road to OMEMO by default](https://gultsch.de/omemo_by_default.html) probably a bit outdated, but it does talk about this issue. > I wouldn't see why riot deserve an exception here. Plus, they announced to make it default very soon, so it cannot hurt to wait for it a little longer. I guess we can always wait.
dawidpotocki commented 2019-10-10 10:24:23 +00:00 (Migrated from github.com)
Author
Owner

Thing is, end to end is the default on all other platforms we
basically recommend. I wouldn't see why riot deserve an exception
here. Plus, they announced to make it default very soon, so it cannot
hurt to wait for it a little longer.

There is Rocket.chat also in Team Chat category which seems to have E2EE
with real Alpha quality (no support on Mobile app, no forward secrecy)

> Thing is, end to end is the default on all other platforms we > basically recommend. I wouldn't see why riot deserve an exception > here. Plus, they announced to make it default very soon, so it cannot > hurt to wait for it a little longer. There is Rocket.chat also in Team Chat category which seems to have E2EE with real Alpha quality (no support on Mobile app, no forward secrecy)
dawidpotocki commented 2019-10-10 10:26:20 +00:00 (Migrated from github.com)
Author
Owner

Thing is, end to end is the default on all other platforms we basically recommend.

Well except for the current XMPP clients, we recommend. Do we know if
Monal supports E2EE by default? I am pretty sure
Gajim doesn't. Perhaps we should consider a
warning badge?

I tried Monal today, seems to send unencrypted messages and I have no
idea how to make OMEMO work there. I would replace it with ChatSecure.

> > Thing is, end to end is the default on all other platforms we basically recommend. > > Well except for the current XMPP clients, we recommend. Do we know if > [Monal](https://monal.im/) supports E2EE by default? I am pretty sure > [Gajim](https://gajim.org) doesn't. Perhaps we should consider a > warning badge? I tried Monal today, seems to send unencrypted messages and I have no idea how to make OMEMO work there. I would replace it with ChatSecure.
dngray commented 2019-10-10 10:35:24 +00:00 (Migrated from github.com)
Author
Owner

I would replace it with ChatSecure.

What would you suggest for users of MacOS? iirc ChatSecure was iOS only.

> I would replace it with ChatSecure. What would you suggest for users of MacOS? iirc ChatSecure was iOS only.
blacklight447 commented 2019-10-10 10:57:33 +00:00 (Migrated from github.com)
Author
Owner

Maybe @ara4n will be able to give us an estimated time until e2ee will be turned on by default for private chats?

Maybe @ara4n will be able to give us an estimated time until e2ee will be turned on by default for private chats?
dawidpotocki commented 2019-10-10 11:01:12 +00:00 (Migrated from github.com)
Author
Owner

I would replace it with ChatSecure.

What would you suggest for users of MacOS? iirc ChatSecure was iOS only.

Beagle IM (https://beagle.im/), looks nice and fully supports OMEMO.
Never used it myself, because I don't use macOS.

> > I would replace it with ChatSecure. > > What would you suggest for users of MacOS? iirc ChatSecure was iOS only. Beagle IM (https://beagle.im/), looks nice and fully supports OMEMO. Never used it myself, because I don't use macOS.
dngray commented 2019-10-10 11:27:54 +00:00 (Migrated from github.com)
Author
Owner

I would replace it with ChatSecure. What would you suggest for users of MacOS? iirc ChatSecure was iOS only.
Beagle IM (https://beagle.im/), looks nice and fully supports OMEMO. Never used it myself, because I don't use macOS.

looks nice and fully supports OMEMO

I don't think I would recommend anything which includes half-baked E2EE unencrypted channels: (voice, video, file transfer), https://github.com/tigase/beagle-im/issues/1 https://github.com/tigase/beagle-im/issues/3). I would say this is far more dangerous than Riot which once E2EE is enabled, everything is encrypted. It's not the first time a vendor has claimed to be fully E2EE.

I would say at this point Riot's E2EE implementation is better than most, even though it is not enabled by default.

In one of our issues previously auditing has been mentioned. The reality is this isn't going to happen for the majority of XMPP clients.

> > I would replace it with ChatSecure. What would you suggest for users of MacOS? iirc ChatSecure was iOS only. > Beagle IM (https://beagle.im/), looks nice and fully supports OMEMO. Never used it myself, because I don't use macOS. > > looks nice and fully supports OMEMO I don't think I would recommend anything which includes half-baked E2EE unencrypted channels: (voice, video, file transfer), https://github.com/tigase/beagle-im/issues/1 https://github.com/tigase/beagle-im/issues/3). I would say this is **far** more dangerous than Riot which once E2EE is enabled, everything is encrypted. It's [not the first time](https://medium.com/@pepelephew/how-to-intercept-all-wire-voice-and-video-calls-13da1246675c) a vendor has claimed to be fully E2EE. I would say at this point Riot's E2EE implementation is better than most, even though it is not enabled by default. In one of our issues previously auditing has been mentioned. The reality is this isn't going to happen for the majority of XMPP clients.
Mikaela commented 2019-10-10 13:30:06 +00:00 (Migrated from github.com)
Author
Owner

I think we need to mention Synapse specifically and encourage self-hosting over using the matrix.org homeserver, or really any public homeserver whenever possible. I don't know if this should be mentioned in the Riot listing, or if we should have a separate category for RTC servers.

I wish we could recommend a non-Synapse and non-Riot option also as currently there is only New Vector.

There are a few unfixed issues,

I have some more:

  • Communities are centralized on a single server and often broken flashing the screen too fast for clicking join or not loading at all. There is also no way to grant other users permissions in a community, so they also get centralized on a single user. They are also Riot-only as far as I am aware. I am told that communities are being rewritten, so maybe it should be a blocker before calling Riot a team chat application.
  • The direct chats system is weird and from what I understand getting more sense in https://github.com/matrix-org/matrix-doc/pull/2199 so I would also be waiting for it.
  • There is no indepedent security audit (other than the OLM one and E2EE is again not enabled by default).

Media is never redacted matrix-org/synapse#1263

Not something I would like to see in our recommendation.

End-to-End Encrypted chats are not really affected by this, and should be used whenever sensitive messages are being communicated.

Is E2EEd media also media? What about when technology is powerful enough to break todays encryption?

Finally, during this re-listing we definitely want to discourage the use of matrix.org anyways to promote decentralization.

Blocker: https://github.com/matrix-org/matrix.org/issues/586

Also, I think that by advertising our group chat on Matrix without recommending Matrix itself we are both sending a mixed message and promoting centralization on our own server, by not demonstrating the alternatives (hosting it yourself).

https://github.com/privacytoolsIO/privacytools.io/issues/987

Perhaps a warning badge

Will we have a warning about it not having been indepedently audited?

afaik that's fork of Conversations that uses phone numbers as an identifier.

No, it's a build variant of Conversations.

What we really need to decide is, is it too difficult to show a user how to enable E2EE on a 1:1 conversation in Riot? - we can do that with pretty pictures. ie:

How about we just wait for New Vector to enable it default as they have said that they are going to do it? https://github.com/vector-im/riot-web/issues/6779

> I think we need to mention Synapse specifically and encourage self-hosting over using the matrix.org homeserver, or really any public homeserver whenever possible. I don't know if this should be mentioned in the Riot listing, or if we should have a separate category for RTC servers. I wish we could recommend a non-Synapse and non-Riot option also as currently there is only New Vector. > There are a few unfixed issues, I have some more: * Communities are centralized on a single server and often broken flashing the screen too fast for clicking join or not loading at all. There is also no way to grant other users permissions in a community, so they also get centralized on a single user. They are also Riot-only as far as I am aware. I am told that communities are being rewritten, so maybe it should be a blocker before calling Riot a *team chat application*. * The direct chats system is weird and from what I understand getting more sense in https://github.com/matrix-org/matrix-doc/pull/2199 so I would also be waiting for it. * There is no indepedent security audit (other than the OLM one and E2EE is again not enabled by default). > Media is never redacted matrix-org/synapse#1263 Not something I would like to see in our recommendation. > End-to-End Encrypted chats are not really affected by this, and should be used whenever sensitive messages are being communicated. Is E2EEd media also media? What about when technology is powerful enough to break todays encryption? > Finally, during this re-listing we definitely want to discourage the use of matrix.org anyways to promote decentralization. Blocker: https://github.com/matrix-org/matrix.org/issues/586 > Also, I think that by advertising our group chat on Matrix without recommending Matrix itself we are both sending a mixed message and promoting centralization on our own server, by not demonstrating the alternatives (hosting it yourself). https://github.com/privacytoolsIO/privacytools.io/issues/987 > Perhaps a warning badge Will we have a warning about it not having been indepedently audited? > afaik that's fork of Conversations that uses phone numbers as an identifier. No, it's a build variant of Conversations. > What we really need to decide is, is it too difficult to show a user how to enable E2EE on a 1:1 conversation in Riot? - we can do that with pretty pictures. ie: How about we just wait for New Vector to enable it default as they have said that they are going to do it? https://github.com/vector-im/riot-web/issues/6779
Mikaela commented 2019-10-10 13:34:10 +00:00 (Migrated from github.com)
Author
Owner

While assigning labels I noticed the Tor one and would like to ask @ara4n what is the status with https://github.com/vector-im/riot-meta/issues/287 and related issues and mark it as a blocker.

We are currently recommending Tor for anonymity instead of a VPN and you generally don't send all your traffic through Tor and instead Torify only specific applications, possibly even with SOCKS isolation and currently all Riots make that non-trivial.

While assigning labels I noticed the Tor one and would like to ask @ara4n what is the status with https://github.com/vector-im/riot-meta/issues/287 and related issues and mark it as a blocker. We are currently recommending Tor for anonymity instead of a VPN and you generally don't send all your traffic through Tor and instead Torify only specific applications, possibly even with SOCKS isolation and currently all Riots make that non-trivial.
Author
Owner

I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats.

Just for clarification my proposed solution at #1392 would only "recommend" Riot as a team chat platform, mainly for this reason.

> I REALLY don't want to recommend matrix until e2ee is turned on by default for private chats. Just for clarification my proposed solution at #1392 would only "recommend" Riot as a team chat platform, mainly for this reason.
Mikaela commented 2019-10-10 16:01:47 +00:00 (Migrated from github.com)
Author
Owner

And I wouldn't list Riot even as a team chat application until the communities are rewritten (and when https://github.com/matrix-org/matrix-doc/pull/2199 is fixed I think it may be listed also as a direct chat client). See also my other concerns above.

Edit: I think this is https://github.com/matrix-org/matrix-doc/issues/1513 (meta/tracker) + worked upon at https://github.com/matrix-org/matrix-doc/pull/1772.

And I wouldn't list Riot even as a team chat application until the communities are rewritten (and when https://github.com/matrix-org/matrix-doc/pull/2199 is fixed I think it may be listed also as a direct chat client). See also my other concerns above. Edit: I think this is https://github.com/matrix-org/matrix-doc/issues/1513 (meta/tracker) + worked upon at https://github.com/matrix-org/matrix-doc/pull/1772.
Author
Owner

I probably disagree that the "communities" feature are an integral part to either the "team chat" or the "Matrix" experience in general. They seem to be mostly useful as flairs designating certain memberships, somewhat akin to IRC vanity vhosts...

I probably disagree that the "communities" feature are an integral part to either the "team chat" or the "Matrix" experience in general. They seem to be mostly useful as flairs designating certain memberships, somewhat akin to IRC vanity vhosts...
ara4n commented 2019-10-10 22:22:07 +00:00 (Migrated from github.com)
Author
Owner

This thread makes my head hurt. It seems to be devolving into a weird list of personal gripes against Matrix, saying “we can’t possibly relist Riot until... ‘all phase 3 (ie nice-to-have) privacy bugs are closed’ or ‘it has native Tor support’ or ‘communities get rewritten’ or ‘because both it and Synapse are mainly written by the same team’ or ‘it doesn’t have latex support’ (or whatever the next complaint will be)”. This feels bizarre in the extreme, and honestly makes privacytools look bad. It feels like we are being judged by a totally different and arbitrary standard to the other tools, despite demonstrably prioritising privacy and freedom.

We hope to turn on E2E by default in the coming months - ideally by end of year. Possibly sooner, given pantalaimon and seshat are almost ready; it’s only the E2EE cross signing that remains because... we prioritised it behind addressing the privacy concerns which had been highlighted. It is genuinely hard to get it right, and we don’t want to force it on until it’s perfect otherwise it will just screw over all the users who are used to the existing behaviour. Meanwhile, just as XMPP doesn’t mandate E2EE, nor does Matrix.

At this point, we are going to keep plugging away improving Matrix, and hope that you consider it worth promoting at some point.

This thread makes my head hurt. It seems to be devolving into a weird list of personal gripes against Matrix, saying “we can’t possibly relist Riot until... ‘all phase 3 (ie nice-to-have) privacy bugs are closed’ or ‘it has native Tor support’ or ‘communities get rewritten’ or ‘because both it and Synapse are mainly written by the same team’ or ‘it doesn’t have latex support’ (or whatever the next complaint will be)”. This feels bizarre in the extreme, and honestly makes privacytools look bad. It feels like we are being judged by a totally different and arbitrary standard to the other tools, despite demonstrably prioritising privacy and freedom. We hope to turn on E2E by default in the coming months - ideally by end of year. Possibly sooner, given pantalaimon and seshat are almost ready; it’s only the E2EE cross signing that remains because... we prioritised it behind addressing the privacy concerns which had been highlighted. It is genuinely hard to get it right, and we don’t want to force it on until it’s perfect otherwise it will just screw over all the users who are used to the existing behaviour. Meanwhile, just as XMPP doesn’t mandate E2EE, nor does Matrix. At this point, we are going to keep plugging away improving Matrix, and hope that you consider it worth promoting at some point.
Mikaela commented 2019-10-10 22:27:31 +00:00 (Migrated from github.com)
Author
Owner

My understanding is that Matrix communities are best compared to Discord servers/guilds or IRC servers, and the flair is a side-effect.

Example

I am an operator on PirateIRC which is IRC network intended only for international Pirate Parties. IRC clients generally list all servers under specific servers and there are currently 115 channels that would appear under it, while anything joined on another server would appear under that server.

This is what I understand Discord to be replicating as if I joined a Discord server, I would see server/guild bubbles on the left and next to them the list of channels on that server (I would be autojoined to everything that I have permission to unlike at IRC).

I understand that Matrix is attempting to directly imitate Discord, so everything would not appear as belonging to a single IRC server, but belong to the releated community/communities such as Pirate Parties or Pirate Party Finland.

Thinking while finishing this comment, IPFS could have been a better example, but I haven't followed them recently due to having been on a IRC break and trying to avoid IRC-bridged Matrix rooms.

My understanding is that Matrix communities are best compared to Discord servers/guilds or IRC servers, and the flair is a side-effect. ## Example I am an operator on PirateIRC which is IRC network intended only for international Pirate Parties. IRC clients generally list all servers under specific servers and there are currently 115 channels that would appear under it, while anything joined on another server would appear under that server. This is what I understand Discord to be replicating as if I joined a Discord server, I would see server/guild bubbles on the left and next to them the list of channels on that server (I would be autojoined to everything that I have permission to unlike at IRC). I understand that Matrix is attempting to directly imitate Discord, so everything would not appear as belonging to a single IRC server, but belong to the releated community/communities such as Pirate Parties or Pirate Party Finland. Thinking while finishing this comment, IPFS could have been a better example, but I haven't followed them recently due to having been on a IRC break and trying to avoid IRC-bridged Matrix rooms.
Mikaela commented 2019-10-10 22:32:23 +00:00 (Migrated from github.com)
Author
Owner

It feels like we are being judged by a totally different and arbitrary standard to the other tools, despite demonstrably prioritising privacy and freedom.

I think you have a worse track record than many of the other tools, but I hope everything in real time communication is judged similarly.

Meanwhile, just as XMPP doesn’t mandate E2EE, nor does Matrix.

It will probably warm you to hear that @JonahAragon has proposed delisting XMPP on our team chat and I expect him to be opening an issue soon.

My personal view on this is that you have history of storing messages forever even when they have been removed by the user and you are currently storing media messages forever, while XMPP has (as far as I know of) always had expiry time for messages. I am also confused on how file uploads sent in a direct chat can be posted elsewhere as easily as by copying the URL, which to me hints that they aren't actually private.

> It feels like we are being judged by a totally different and arbitrary standard to the other tools, despite demonstrably prioritising privacy and freedom. I think you have a worse track record than many of the other tools, but I hope everything in real time communication is judged similarly. > Meanwhile, just as XMPP doesn’t mandate E2EE, nor does Matrix. It will probably warm you to hear that @JonahAragon has proposed delisting XMPP on our team chat and I expect him to be opening an issue soon. My personal view on this is that you have history of storing messages forever even when they have been removed by the user and you are currently storing media messages forever, while XMPP has (as far as I know of) always had expiry time for messages. I am also confused on how file uploads sent in a direct chat can be posted elsewhere as easily as by copying the URL, which to me hints that they aren't actually private.
Author
Owner

This feels bizarre in the extreme, and honestly makes privacytools look bad. It feels like we are being judged by a totally different and arbitrary standard to the other tools, despite demonstrably prioritising privacy and freedom.

@ara4n Uh, yeah, I agree 🤔 None of the issues anyone else has brought up outside the original post appear to have actual privacy implications to users.

> This feels bizarre in the extreme, and honestly makes privacytools look bad. It feels like we are being judged by a totally different and arbitrary standard to the other tools, despite demonstrably prioritising privacy and freedom. @ara4n Uh, yeah, I agree 🤔 None of the issues anyone else has brought up outside the original post appear to have actual _privacy_ implications to users.
Author
Owner

Plus, they announced to make it default very soon, so it cannot hurt to wait for it a little longer.

@blacklight447-ptio Will it be the default for large group chats? E2EE is highly irrelevant for large groups which is primarily what Riot is being recommended here for, to be clear. It is not a recommended instant messenger for this reason but seeing as E2EE exists we can mention it.

> Plus, they announced to make it default very soon, so it cannot hurt to wait for it a little longer. @blacklight447-ptio Will it be the default for large group chats? E2EE is highly irrelevant for large groups which is primarily what Riot is being recommended here for, to be clear. It is not a recommended instant messenger for this reason but seeing as E2EE *exists* we can *mention* it.
Mikaela commented 2019-10-10 22:58:23 +00:00 (Migrated from github.com)
Author
Owner

Will it be the default for large group chats?

I don't think so, https://github.com/vector-im/riot-web/issues/6779.

> Will it be the default for large group chats? I don't think so, https://github.com/vector-im/riot-web/issues/6779.
ara4n commented 2019-10-10 23:06:20 +00:00 (Migrated from github.com)
Author
Owner

I think you have a worse track record than many of the other tools

Speaking as objectively as possible: I think this is untrue. For instance, thinking about the tools which actually claim a security focus, Wire claimed their VoIP calls were E2EE when they simply weren't; Signal has had a series of basic security screwups (free-for-all XSS and acting as an audio bug etc.)

Whereas the worst complaint levelled against us seems to be that we set a default value for the phone book & integration manager for convenience (which we then went and fixed), and that configurable history retention and e2e-by-default hasn't been merged yet (despite clearly warning in the message composer that messages are unencrypted in non-E2E rooms). It feels like folks have been dazzled by the sheer number of words put out by the libremonde 'research'.

It will probably warm you to hear that @JonahAragon has proposed delisting XMPP

I have absolutely nothing against XMPP. We're working this week on turning Bifrost back on for XMPP<->Matrix bridging, and I really appreciated the XSF team reaching out to say congrats on our funding announcement today. The enemy here is FB/Google/Discord/Slack etc - not XMPP!!!

My personal view on this is that you have history of storing messages forever even when they have been removed by the user

...which was always on the todo-list to fix - since 2015, and has now been solved. It's not like we were doing this maliciously.

and you are currently storing media messages forever

Yes, this needs to be fixed, but is it really a privacy disaster? Especially if the file is E2EE?

I am also confused on how file uploads sent in a direct chat can be posted elsewhere as easily as by copying the URL, which to me hints that they aren't actually private.

The filenames are random. All you're doing is swapping a random access_token for a random file name. It would take longer than the heat death of the universe to guess one of the filenames. So the fact that you can copy the URLs between rooms is not a massive vulnerability. That said, we're going to fix it anyway (just to stop having this conversation, if nothing else) - just as we're providing deletion APIs for attachments.

Will it (E2EE) be the default for large group chats?

E2EE will be turned on by default for rooms created as private chats - either DMs or private group chats.

> I think you have a worse track record than many of the other tools Speaking as objectively as possible: I think this is untrue. For instance, thinking about the tools which actually claim a security focus, Wire claimed their VoIP calls were [E2EE when they simply weren't](https://medium.com/@pepelephew/how-to-intercept-all-wire-voice-and-video-calls-13da1246675c); Signal has had a series of basic security screwups ([free-for-all XSS](https://nakedsecurity.sophos.com/2018/05/16/serious-xss-vulnerability-discovered-in-signal/) and [acting as an audio bug](https://bugs.chromium.org/p/project-zero/issues/detail?id=1943) etc.) Whereas the worst complaint levelled against us seems to be that we set a default value for the phone book & integration manager for convenience (which we then went and fixed), and that configurable history retention and e2e-by-default hasn't been merged yet (despite clearly warning in the message composer that messages are unencrypted in non-E2E rooms). It feels like folks have been dazzled by the sheer number of words put out by the libremonde 'research'. > It will probably warm you to hear that @JonahAragon has proposed delisting XMPP I have absolutely nothing against XMPP. We're working this week on turning Bifrost back on for XMPP<->Matrix bridging, and I really appreciated the XSF team [reaching](https://twitter.com/ralphm/status/1182217208652603392) [out](https://twitter.com/guusdk/status/1182247654186717184) to say congrats on our funding announcement today. The enemy here is FB/Google/Discord/Slack etc - not XMPP!!! > My personal view on this is that you have history of storing messages forever even when they have been removed by the user ...which was [always on the todo-list to fix](https://github.com/matrix-org/synapse/issues/1287) - since 2015, and **has now been solved**. It's not like we were doing this maliciously. > and you are currently storing media messages forever Yes, this needs to be fixed, but is it *really* a privacy disaster? Especially if the file is E2EE? > I am also confused on how file uploads sent in a direct chat can be posted elsewhere as easily as by copying the URL, which to me hints that they aren't actually private. The filenames are random. All you're doing is swapping a random access_token for a random file name. It would take longer than the heat death of the universe to guess one of the filenames. So the fact that you can copy the URLs between rooms is not a massive vulnerability. That said, we're going to fix it anyway (just to stop having this conversation, if nothing else) - just as we're providing deletion APIs for attachments. > Will it (E2EE) be the default for large group chats? E2EE will be turned on by default for rooms created as private chats - either DMs or private group chats.
Mikaela commented 2019-10-10 23:21:25 +00:00 (Migrated from github.com)
Author
Owner

For instance, thinking about the tools which actually claim a security focus, Wire claimed their VoIP calls were E2EE when they simply weren't; Signal has had a series of basic security screwups (free-for-all XSS and acting as an audio bug etc.)

I was only thinking of security audits of those two.

I have absolutely nothing against XMPP. We're working this week on turning Bifrost back on for XMPP<->Matrix bridging.

I am happy to hear that.

The enemy here is FB/Google/Discord/Slack etc - not XMPP!!!

You are correct and I am not taking my own words from https://github.com/privacytoolsIO/privacytools.io/issues/1377#issuecomment-540152967. While I have lost a lot of trust towards Matrix, it's not Discord (which is the instant messenger enemy that I cannot get to peace with (some may know of my Telegram cases)) and thus I am willing to come towards you and apologise for my behaviour.

...which was always on the todo-list to fix - since 2015, and has now been solved. It's not like we were doing this maliciously.

And now it's 2019, but you don't need to reply to this.

Yes, this needs to be fixed, but is it really a privacy disaster? Especially if the file is E2EE?

In the light of the enemy being Discord with their ToS and privacy policy, I guess it doesn't qualify as a disaster. I am not assured that your E2EE will be unbroken forever and thus I wish to have even the encrypted copies removed after a time.

That said, we're going to fix it anyway (just to stop having this conversation, if nothing else) - just as we're providing deletion APIs for attachments.

👍

> For instance, thinking about the tools which actually claim a security focus, Wire claimed their VoIP calls were [E2EE when they simply weren't](https://medium.com/@pepelephew/how-to-intercept-all-wire-voice-and-video-calls-13da1246675c); Signal has had a series of basic security screwups ([free-for-all XSS](https://nakedsecurity.sophos.com/2018/05/16/serious-xss-vulnerability-discovered-in-signal/) and [acting as an audio bug](https://bugs.chromium.org/p/project-zero/issues/detail?id=1943) etc.) I was only thinking of security audits of those two. > I have absolutely nothing against XMPP. We're working this week on turning Bifrost back on for XMPP<->Matrix bridging. I am happy to hear that. > The enemy here is FB/Google/Discord/Slack etc - not XMPP!!! You are correct and I am not taking my own words from https://github.com/privacytoolsIO/privacytools.io/issues/1377#issuecomment-540152967. While I have lost a lot of trust towards Matrix, it's not Discord (which is the instant messenger enemy that I cannot get to peace with (some may know of my Telegram cases)) and thus I am willing to come towards you and apologise for my behaviour. > ...which was [always on the todo-list to fix](https://github.com/matrix-org/synapse/issues/1287) - since 2015, and **has now been solved**. It's not like we were doing this maliciously. And now it's 2019, but you don't need to reply to this. > Yes, this needs to be fixed, but is it *really* a privacy disaster? Especially if the file is E2EE? In the light of the enemy being Discord with their ToS and privacy policy, I guess it doesn't qualify as a disaster. I am not assured that your E2EE will be unbroken forever and thus I wish to have even the encrypted copies removed after a time. > That said, we're going to fix it anyway (just to stop having this conversation, if nothing else) - just as we're providing deletion APIs for attachments. :+1:
ara4n commented 2019-10-11 08:10:53 +00:00 (Migrated from github.com)
Author
Owner

While I have lost a lot of trust towards Matrix, it's not Discord (which is the instant messenger enemy that I cannot get to peace with (some may know of my Telegram cases)) and thus I am willing to come towards you and apologise for my behaviour.

thank you - the apology is appreciated & accepted. i'm hoping it will become even clearer that Matrix is worthy of trust, even if the core development is still largely funded by one company (under the governance of the Foundation).

> While I have lost a lot of trust towards Matrix, it's not Discord (which is the instant messenger enemy that I cannot get to peace with (some may know of my Telegram cases)) and thus I am willing to come towards you and apologise for my behaviour. thank you - the apology is appreciated & accepted. i'm hoping it will become even clearer that Matrix is worthy of trust, even if the core development is still largely funded by one company (under the governance of the Foundation).
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1389
No description provided.