Fix #57 : Overhaul real-time communications page + add Session messenger

[lrq3000]

Description

Resolves: element-hq/element-web#57, element-hq/element-web#138, element-hq/element-web#50

• Add audits systematically whenever available.
• Separate descriptions of networks types in a separate tutorial section
• Tag by network types instead of sections only for instant messengers)
• Add illustrations of networks types.
• Rework a bit the definitions and pros/cons.
• Add Anonymous Routing as a network type.
• Add Session (ex Loki Messenger)
• Upgrade Status messenger (ex status.im messenger) into a recommendation (needs more testing to confirm).

Following discussions below:

• Remove non audited or non E2EE apps: Jami, Mumble.
• Add lots of warning as notes for almost all software messengers.
• Migrate template from legacy to evergreen
• Add labels to evergreen template (more flexible alternative to info and warning items, necessary to implement the tags based classification of messengers by networks types)

Todo before merge:

• Check if Status is worthy of being a recommendation (usability, security concerns since after the 2019 audit, etc).
• Consider Jami as a videoconferencing recommendation (need to confirm how it E2EE encrypts group calls).

This is a proposition, to overhaul the real-time communications page.

Currently, instant messengers are separated in different categories. This forces to dichotomize messengers into one category or the other, which doesn't fit well for some messengers that implement multiple networks (eg, Briar which is both P2P and Anonymous Routing). Furthermore, only instant messengers are identified by their network type, but this should also apply to video and voice messengers as well as teamchat.

I propose here following the discussion in element-hq/element-web#57 to redesign the page by removing the network type sections, and instead just present a list of instant messengers, but with tags in each description instead of sections. This allows for a more streamlined overview, similar to other listings in other pages, while not losing any information. In fact, there are more infos now since we can assign multiple networks types.

The layman descriptions of the differences between each network type is not lost either, but moved at the bottom of the page. It could be moved at the top too depending on what you want to present first (the selection of apps or a tutorial to help the user choose). Illustrations have been added, as well as an Anonymous Routing network type.

Note: the PR may be buggy (I will check with Netlify, build toolchain fails on my computer for some reason...). I will update this post when fully ready.

/EDIT: somewhat ready now to discuss further. Probably needs some more polishing if this proposition is accepted.

/EDIT2: Note that Jami has not yet been audited.

/EDIT3: for future reference, all icons that can be used for tags are listed here: https://www.angularjswiki.com/fontawesome/

[netlify]

✔️ Deploy Preview for privacyguides ready!

🔨 Explore the source changes: edd7dee

🔍 Inspect the deploy log: https://app.netlify.com/sites/privacyguides/deploys/61c6d54a00427500075c3699

😎 Browse the preview: https://deploy-preview-192--privacyguides.netlify.app

[lrq3000]

Somewhat ready now to discuss further. Probably needs some more polishing if this proposition is accepted.

[lrq3000]

Deployment failed because blog.privacytools.io appears to have just been deleted... But the last snapshot should be good enough to have a good idea of what the PR would do.

/EDIT: ah it seems this doesn't prevent deployment. I guess this error is not new then?

[dngray]

I hadn't noticed this comprehensive PR, will give it a check over shortly.

[TommyTran732]

Adding session and the audit tag looks great, but I would like to suggest that we remove jami due to it being unaudited. Status is audited but that was back in 2019 and had a lot of unfixed issues back then, so I'd remove that as well.

Also, is there a rationalization behind removing the advantages and disadvantages section? I think its important to mention how signal requires a phone number but does metadata reduction, sessions not having forward secrecy and so on.

[lrq3000]

@TommyTran732 I agree that Jami not being audited is a malus. On the plus side, it's one of the only E2EE and P2P messengers. But in practice in my experience it doesn't work well anyway. (Addendum: here's an interesting discussion about Jami's security)

About status.im, I never used this software, but from the doc it seems to fit all criteria. If the audit being 2 years old is an issue, the same criterion should be applied to other messengers, and I'm not sure a lot would pass a bar this high...

I would also suggest to remove Mumble. Although it is a very beloved software, it does not implement E2EE, which is a necessary criterion per the introduction of this page. Or at least it should be a "Worth Mentioning", but not a recommendation.

About the advantages/disadvantages, they are still there, but at the bottom of the page in the tutorial section on the various network types. Most messengers nowadays implement multiple network types for various features (eg, voice and video calls being P2P while messenging can be centralized/federated/anonymously routed), so the pros/cons are necessarily contextual (ie, no pros/cons per software but rather per network type, so that for hybrid messengers implementing multiple network types, the pros/cons for each of these network types apply depending on what features of the messenger are being used). I will add a short explanation to clarify in the tutorial section.

[dngray]

Adding session and the audit tag looks great, but I would like to suggest that we remove jami due to it being unaudited.

Agreed

Status is audited but that was back in 2019 and had a lot of unfixed issues back then, so I'd remove that as well.

Agreed, we can always review the situation later.

In line with https://github.com/privacyguides/privacyguides.org/discussions/24 we want to establish a criteria for this page too.

I think it's worth mentioning that all submissions must be audited competently. Unofficially we'd already had that as a criteria, besides being open source. E2EE being another one that came in when we added Matrix and that was imminently enabling that.

I would also suggest to remove Mumble. Although it is a very beloved software, it does not implement E2EE, which is a necessary criterion per the introduction of this page. Or at least it should be a "Worth Mentioning", but not a recommendation.

Agreed.

About the advantages/disadvantages, they are still there, but at the bottom of the page in the tutorial section on the various network types. Most messengers nowadays implement multiple network types for various features (eg, voice and video calls being P2P while messenging can be centralized/federated/anonymously routed), so the pros/cons are necessarily contextual (ie, no pros/cons per software but rather per network type, so that for hybrid messengers implementing multiple network types, the pros/cons for each of these network types apply depending on what features of the messenger are being used). I will add a short explanation to clarify in the tutorial section.

This section may need re-working to what is currently there, as there is a bit of crossover now.

If you could find the time, a quick one to add to this https://github.com/privacyguides/privacyguides.org/discussions/138

[lrq3000]

This section may need re-working to what is currently there, as there is a bit of crossover now.

Yes the text needs polishing, but I'm not sure I understand what you have in mind. Could you please provide me with an example of what you would like to change?

[dngray]

This section may need re-working to what is currently there, as there is a bit of crossover now.

Yes the text needs polishing, but I'm not sure I understand what you have in mind. Could you please provide me with an example of what you would like to change?

I had another look today and I'm not sure what I was talking about. 😄

We could get rid of the team section now, as Rocket Chat's E2EE hasn't been audited. With Matrix you can run a non-federating server, so that is suitable for companies too. Saves on duplication. You could mention that under the badge text for Federating with Element.

I think we can get rid of that WebRTC warning, that is no longer true. It isn't in Firefox nor Chromium.

[lrq3000]

About Rocket.chat's audit, I found the following infos:

• Their "management system" is independently audited (but not their technical system): https://docs.rocket.chat/guides/security/compliance-resources
• The only independent audit was done with automatic tools: https://www.isgroup.it/node.security/audit-Rocket.Chat.html
• 7 months ago, an independent researcher and member of a digital rights movement asked for the public release of infos about an independent audit, and the Rocket.chat team only pointed to contacting them in private: https://giters.com/RocketChat/Rocket.Chat/issues/21859

This looks quite shady. So I will proceed to remove Rocket.chat .

About removing the entire Team Chat section, I think it's a bit sad because it's a very different use case but it's useless to keep an entire section if there is only one software inside. This will become a label for now.

What about the file structure? Currently the files are in "legacy" folders, but since this would be an almost complete rewrite, maybe we should move the files to reflect that this is no longer legacy? If so, what should be the files structure?

[lrq3000]

There's a problem with requiring independent audits, all softwares in Voice and Video Messengers are not independently audited. Maybe because the encrypted multiparty VoIP feature is still quite new and experimental (implemented in 2019 as LIME in Linphone, implemented in the latter half of 2020 for Jitsi Meet).

Should we make an exception for these, or remove them, or retract the "independently audited" criterion? (the latter implying Jami and Rocket.chat could be reintegrated?)

[lrq3000]

I would also suggest to make status.im a recommendation. I never used the software so a practical test would be necessary first, but the more I dig into the technicals, the more it appears to fit all our criteria, including independent audits. So I'm not sure why it's only "Worth Mentioning" currently, maybe because it uses a blockchain network?

[lrq3000]

An excellent tutorial on anonymous routing, maybe we could add it in a "Further reading" subsection in anonymous routing? https://medium.com/unitychain/privacy-blockchain-and-onion-routing-d5609c611841

[dngray]

@lrq3000

Sorry I haven't replied earlier, as we've been busy updating other parts of the site/doign research 😄

About Rocket.chat's audit, I found the following infos:

• Their "management system" is independently audited (but not their technical system): https://docs.rocket.chat/guides/security/compliance-resources

• The only independent audit was done with automatic tools: https://www.isgroup.it/node.security/audit-Rocket.Chat.html

• 7 months ago, an independent researcher and member of a digital rights movement asked for the public release of infos about an independent audit, and the Rocket.chat team only pointed to contacting them in private: https://giters.com/RocketChat/Rocket.Chat/issues/21859

This looks quite shady. So I will proceed to remove Rocket.chat .

Indeed, these things should be public, and audits aren't using automatic tools.

About removing the entire Team Chat section, I think it's a bit sad because it's a very different use case but it's useless to keep an entire section if there is only one software inside. This will become a label for now.

I don't think its worthwhile keeping for one piece of software.

What I think we could do is add a footnote for Element that Matrix servers when configured for business can have federation disabled if they are intended for internal company use only.

About that specifically, with the new format described below, longer descriptions are possible without sending the site layout into disarray (see hardened firefox for example).

What about the file structure? Currently the files are in "legacy" folders, but since this would be an almost complete rewrite, maybe we should move the files to reflect that this is no longer legacy? If so, what should be the files structure?

About the file structure, basically the "legacy" is the PTIO style pages. The newer format will be individual YAML files for each card. You can see an example of where we're starting to do this on the browser section https://github.com/privacyguides/privacyguides.org/pull/309/files

What this means is then each "item" on the site actually has its data extracted from the main layout pages.

There's a problem with requiring independent audits, all softwares in Voice and Video Messengers are not independently audited. Maybe because the encrypted multiparty VoIP feature is still quite new and experimental (implemented in 2019 as LIME in Linphone, implemented in the latter half of 2020 for Jitsi Meet).

Should we make an exception for these, or remove them, or retract the "independently audited" criterion? (the latter implying Jami and Rocket.chat could be reintegrated?)

Personally I'm in favour of stripping them rather than making exceptions. The reason is it makes the site less complex, and encourages things to actually get an audit to be listed.

Otherwise we really open the floodgates to "everything"

I would also suggest to make status.im a recommendation. I never used the software so a practical test would be necessary first, but the more I dig into the technicals, the more it appears to fit all our criteria, including independent audits. So I'm not sure why it's only "Worth Mentioning" currently, maybe because it uses a blockchain network?

A couple of reasons, I thik the first was a bug regarding notifications @jonaharagon tested this sime time ago.

The second was we were waiting for it to be listed in F-Droid which it now is: https://f-droid.org/en/packages/im.status.ethereum/

We're not against adding products with cryptocurrency features, we're just not open to adding everything that exists.

[lrq3000]

@dngray Thank you for your clarifications and suggestions. No worries, I know you guys are very busy since the fork, and anyway your replies were always timely imho (but I wouldn't mind if not, I'll try to follow through your schedule).

About being selective, I agree, and I try to consider softwares for PG only based on whether they fit all the criteria. Since the criteria are stringent, there are only a handful of softwares that can fit, so I think this takes objectively care of the selectivity problem.

I hence understand your suggestion to remove the voice/video calling softwares altogether, however this means that PG won't provide any alternative suggestion to Zoom and Microsoft Teams. IMHO using Jitsi Meet or Linphone is much better albeit not audited. Maybe we can make them a "Worth Mentioning" suggestion?

Indeed, we could consider the "Worth Mentioning" sections as a place to include softwares that do not (yet) meet all criteria, if that's ok for you. In this case, we will end up with a single section "Instant messengers", remove the Voice/Video Communication section, and add Jitsi Meet and Linphone as Worth Mentioning with a description that explains their purpose.

About status.im, then I will test it to see if the issues were resolved and if yes I will add it since it seems to fit all criteria.

[dngray]

@dngray Thank you for your clarifications and suggestions. No worries, I know you guys are very busy since the fork, and anyway your replies were always timely imho (but I wouldn't mind if not, I'll try to follow through your schedule).

That's okay, I do very much appreciate the help with PRs, especially regarding this page.

About being selective, I agree, and I try to consider softwares for PG only based on whether they fit all the criteria. Since the criteria are stringent, there are only a handful of softwares that can fit, so I think this takes objectively care of the selectivity problem.

It does, and I think honestly more is not better as it clutters the page and the user then asks "which one do I pick?"

I hence understand your suggestion to remove the voice/video calling softwares altogether, however this means that PG won't provide any alternative suggestion to Zoom and Microsoft Teams. IMHO using Jitsi Meet or Linphone is much better albeit not audited. Maybe we can make them a "Worth Mentioning" suggestion?

I was only suggesting removing the team category as it only had Element in it.

Indeed, we could consider the "Worth Mentioning" sections as a place to include softwares that do not (yet) meet all criteria, if that's ok for you.

We're moving away from "Worth Mentioning" sections, we can always revist those softwares in a discussion thread.

In this case, we will end up with a single section "Instant messengers", remove the Voice/Video Communication section, and add Jitsi Meet and Linphone as Worth Mentioning with a description that explains their purpose.

Maybe a "Video Conferencing" section would work?

About status.im, then I will test it to see if the issues were resolved and if yes I will add it since it seems to fit all criteria.

Would it be too much to ask if you take a look at the new format before we merge this.

An example can be seen in #309 and #333

We might as well look at it now, before merging in legacy.

[lrq3000]

@dngray I had a look at the new evergreen template thanks to the PR pointers you gave me. Wow, that's a great departure from the previous template! But it's great to see PG heading towards a more tutorial oriented approach, rather than listing. I understand the idea.

I updated this PR to migrate to the evergreen template, please let me know what you think about it. I had to also migrate the labels subtemplate to allow the implementation of tags.

I upgraded Status to a recommendation temporarily because I just moved everything to the evergreen template (and there is no Worth Mentions in it), I still need to test it out for myself.

About removing the Videoconferencing section, I was referring to the fact that if independent audits are required for all recommended softwares, none of those in the videoconferencing section would pass, hence the section would be empty and hence would need to be removed. So what do we do about that?

[TommyTran732]

Heyo :)

I am working on a lot of the migration too, so here are a few things I'd suggest :)

I think this part can be merged with the introduction at the top. I don't think the explanation for the 3 types of communications are necessary, we already touch on it below anyways. The top should just explain what end to end encryption is and how it removes the trust from the server - and by extension, the service provider, as they cannot read your messages anyways.

I had a talk with dngray and we are moving away from using those alert banners, they do look pretty bad and it's not good that it is currently used just to tell people that they should move away from those chat apps without being a real alert. Besides, we already talks about the needs to remove trust from the service provider in the intro anyways, so it's redundant to have these.

I think the btags are a bit inconsistent here.

I think we should move away from the red alert tag as well. In my other PRs, I just explicitly put in the notes something in the lines of: Hey, using Signal requires a phone number. Your chat messages are private, the metadata the server has is minimal, but you are not anonymous. Consider getting a disposable number depending on your threat model (linking the threat modeling page).

You can see an example of this on the https://privacyguides.org/video-streaming/ page (the LBRY section)

[lrq3000]

@TommyTran732 Thank you so much for your very helpful feedback! Your other PR on browser is very helpful too and I used it as a guide for my own migration!

I currently have an issue since the merge, the layout is completely broken for some reason, so I'm trying to fix that first.

I will implement all your suggestions.

About the tags being inconsistent, what are you pointing at more specifically? The icons (this was done on purpose) or the missing background for "Audit" and "Whitepaper"? If the latter, this happens when there are both a link and a tooltip, then for some reason the current template removes the background. I would also prefer this to be fixed but I'm not Jekyll wizard enough to do that myself... Any help is welcome!

[TommyTran732]

@lrq3000 Oh, I meant the missing background

And dw about the tests being stuck btw, dngray updated one of the dependencies and it broke github actions... he is trying to fix it xD

[lrq3000]

@TommyTran732 thank you for the heads-up, but it was my mistake about the missing template ;-) It's now fixed fortunately :D

I have now implemented all your suggestions, except fixing the linked+tooltip labels missing background. Is the page now more in line with the planned new UI?

[lrq3000]

I decided to rename the Whitepaper headings into Technical documentation, so that specifications published on github for example but not specifically termed "whitepapers" can be added. This applies for example to Briar. Because honestly there is no difference with a whitepaper apart from the name, both are self-published anyway.

[lrq3000]

Ok guys I have implemented everything that was mentioned so far.

I still have to test the two apps (Status and Jami).

@TommyTran732 I didn't add everything in the description of Signal because I feel they are not pertinent to most users, in my understanding the Notes subsections should contain any info worth mentioning to improve security or gotchas/pitfalls to know before using the app, but per se they aren't descriptive of the app's purpose. I however added that it's widespread and praised, and removed the criticisms about MobileCoin, which were just basic general criticism about cryptocurrencies by a well known critic (whose arguments are not holding much for now) and hence irrelevant about Signal's communication security despite what newspapers headlines tried to make out of it (and I fell for it...).

[TommyTran732]

@lrq3000

1. I think you should remove the centralized tag from element. It is federated, not centralized.
2. Team Chat as a badge should be removed entirely - you can have group chat with Signal and Briar as well. It doesn't make any sense.
3. "Discover secure and private ways to communicate with others online without letting any third parties read your messages. " I think this is redundant and don't need to be mentioned.
4. "We only recommend communication softwares that support end-to-end encryption (E2EE), which ensures all communications are encrypted for anyone, including the server, except for you and the recipient. "
   I think this could be phrased better, something along the lines of "The threat when using instant messenger is that the provider can look at your messages. Thus, we recommend only E2EE chats to mitigate this threat blah blah"
5. The deleted media section on element is too long. The described situation (federated servers can ignore the deletion request) applies to both the attached media and messages. You don't need to split messages to a different area.
6. Reactions, nicknames, avatar can be combined to 1 single section. Just mention that the only thing encrypted are the message body, nothing else. Metadata is fully available for anyone to see.
7. @dngray I think some links at the bottom could be cleaned up. Do you agree?

[dngray]

Yes, sounds good, btw i'm going to rebase this PR soon on main.

[ph00lt0]

the links under "Complete Comparison" do not always have the right info and also they recommend apps that we certainly wouldn't, I would suggest not to include them on the privacyguides website.

[dngray]

@lrq3000

1. I think you should remove the centralized tag from element. It is federated, not centralized.

Yes.

2. Team Chat as a badge should be removed entirely - you can have group chat with Signal and Briar as well. It doesn't make any sense.

Yes

3. "Discover secure and private ways to communicate with others online without letting any third parties read your messages. " I think this is redundant and don't need to be mentioned.

Correct, we don't recommend anything that doesn't have strong E2EE.

4. "We only recommend communication softwares that support end-to-end encryption (E2EE), which ensures all communications are encrypted for anyone, including the server, except for you and the recipient. "

I think this could be phrased better, something along the lines of "The threat when using instant messenger is that the provider can look at your messages. Thus, we recommend only E2EE chats to mitigate this threat blah blah"

Yep, more explanatory and less technical. Says the same thing, maybe don't start the sentence with Thus, though. Just get straight into it.

I'd probably go more down the line of:

We only recommend messengers that support strong E2EE otherwise the chat platform administrators may be able to look at your messages. E2EE means your messages are encrypted before they are transmitted.

5. The deleted media section on element is too long. The described situation (federated servers can ignore the deletion request) applies to both the attached media and messages. You don't need to split messages to a different area.

Yup

6. Reactions, nicknames, avatar can be combined to 1 single section. Just mention that the only thing encrypted are the message body, nothing else. Metadata is fully available for anyone to see.

Yup

7. @dngray I think some links at the bottom could be cleaned up. Do you agree?

Agreed, I think we talked about it in the lounge, and it was determined many of them are quite out of date, might be worth moving it to the wiki rather than entirely deleting it. Might be useful for a blog article or something like that.

[dngray]

the links under "Complete Comparison" do not always have the right info and also they recommend apps that we certainly wouldn't, I would suggest not to include them on the privacyguides website.

Yes this, and i'd ditch the audits section. Each software recommendation should have that included in it's card.

[dngray]

Rebased and squashed this to make it easier to work with.

[dngray]

@TommyTran732 and I decided not to mention Linphone/Jitsi as cards because they aren't audited. We do still mention Jitsi is used in the Element card.

[privacyguides-bot]

This pull request has been mentioned on Privacy Guides. There might be relevant details there:

https://discuss.privacyguides.net/t/why-is-jami-not-listed-in-pg/12500/3

[privacyguides-bot]

This pull request has been mentioned on Privacy Guides Community. There might be relevant details there:

https://discuss.privacyguides.net/t/status-app/20643/3