Add XMPP servers #141

New Issue

see and manipulate your contact lists, groups and group membership and vCard
log your password in cleartext even if SCRAM is enabled
monitor all of your activities (typing, reading messages, changing profile info)
inject fake messages from arbitrary senders
read all of your non-encrypted chats (1-to-1 and group messaging)
…

The clear recommendation here is to always run your own XMPP server and never use one on the internet run by people you don't know. Even if you trust the admin, there is the risk that your personal data and tons of metadata will be exposed due to a data breach. This is basically a security and privacy nightmare.

We recently [wrote an article](https://infosec-handbook.eu/blog/xmpp-aitm/) about the power of XMPP admins. For instance, they are able to: - see and manipulate your contact lists, groups and group membership and vCard - log your password in cleartext even if SCRAM is enabled - monitor all of your activities (typing, reading messages, changing profile info) - inject fake messages from arbitrary senders - read all of your non-encrypted chats (1-to-1 and group messaging) - … The clear recommendation here is to **always run your own XMPP server** and never use one on the internet run by people you don't know. Even if you trust the admin, there is the risk that your personal data and tons of metadata will be exposed due to a data breach. This is basically a security and privacy nightmare.

👍 1

ghost commented

2018-08-18 14:06:44 +00:00

(Migrated from github.com)

What's wrong with that? XMPP is just the protocol we choose for OTR. Metadata might be something of concern, but just informing users is better than abandoning the idea of third party XMPP servers altogether.

ghost commented

2018-08-19 05:20:11 +00:00

(Migrated from github.com)

@Shifterovich
Sorry, I don't get your point this time. I said, besides metadata XMPP server admins can read and manipulate your personal data including contacts, groups, vCards and passwords. For instance, they are able to:

add arbitrary contacts to your roster
send you messages from arbitrary senders (like "snowden@nsa.gov" or one of your friends)
log in to your account since they can log your password in cleartext (see image below)

Admins are still able to do so if you enable OMEMO/OTR/OpenGPG and connect via Tor. Another point is that users can't see whether an admin monitors their activities. This is neither secure nor privacy-friendly.

Therefore, I would only recommend running your own XMPP server and abandon the idea to recommend third party servers which look to be thrustworthy while there is no proof. (Only my two cents!)

@Shifterovich Sorry, I don't get your point this time. I said, _besides metadata_ XMPP server admins can read _and manipulate_ your personal data including contacts, groups, vCards and passwords. For instance, they are able to: - add arbitrary contacts to your roster - send you messages from arbitrary senders (like "snowden@nsa.gov" or one of your friends) - log in to your account since they can log your password in cleartext (see image below) ![Passwords in cleartext](https://infosec-handbook.eu/art-img/xmpp-aitm-passwords.png) Admins are still able to do so if you enable OMEMO/OTR/OpenGPG and connect via Tor. Another point is that users can't see whether an admin monitors their activities. This is neither secure nor privacy-friendly. Therefore, I would only recommend running your own XMPP server and abandon the idea to recommend third party servers which look to be thrustworthy while there is no proof. (Only my two cents!)

❤️ 1

ghost commented

2018-08-19 16:04:48 +00:00

(Migrated from github.com)

If you always use OTR, how is receiving an unencrypted message from one of your friends a major concern? What you listed isn't anything specific to XMPP, it's like that with all sorts of third party servers. I see your point but we should be warning users about this instead of deciding what's good for them. There are secure ways to communicate over insecure channels. One of them is only trusting OTR messages.

Mikaela commented

2019-01-10 20:32:02 +00:00

(Migrated from github.com)

Jabber servers comparison list: https://gultsch.de/compliance_ranked.html

This has moved to https://compliance.conversations.im/ where you recognise at least Disroot.org. Many Diaspora* pods are also running XMPP servers.

DuckDuckGo's XMPP server (dukgo.com)

This doesn't exist anymore.

> Jabber servers comparison list: https://gultsch.de/compliance_ranked.html This has moved to https://compliance.conversations.im/ where you recognise at least Disroot.org. Many Diaspora* pods are also running XMPP servers. > DuckDuckGo's XMPP server (dukgo.com) This doesn't exist anymore.

👍 1

Mikaela commented

2019-04-15 10:59:38 +00:00

(Migrated from github.com)

Could https://xmpp.org/getting-started/ be linked to instead or should Privacytools.io host XMPP in addition to Matrix?

ghost commented

2019-04-15 11:11:28 +00:00

(Migrated from github.com)

We could host our own XMPP server, but we should advise our users not to have all their accounts centralized on our servers (using PTIO Matrix, XMPP, Mastodon, etc).

👍 3 😆 1

Mikaela commented

2019-06-05 11:03:01 +00:00

(Migrated from github.com)

@privacytoolsIO/editorial Do you have new thoughts on this?

@JonahAragon commented at https://github.com/privacytoolsIO/privacytools.io/pull/915#pullrequestreview-242417487:

What concerns me about this PR is I'm not sure if recommending specific instances is in the best interest of our users. The point of these federated protocols especially is to promote decentralization. We host social.privacytools.io and chat.privacytools.io as a convenient way for people to join our discussions on privacy and leave centralized services like Twitter and Facebook. We do not host them as a service that everybody should be using, and indeed I would recommend people self-host the software every time I'm asked, even though I personally maintain chat and social.privacytools.io.

I fear if we recommend a specific instance to people for these services, they won't do the research on their own to make a more informed decision.

and so did @blacklight447-ptio at https://github.com/privacytoolsIO/privacytools.io/pull/915#issuecomment-496449555

I feel the same as jonah, listing these services can feel like an endorsement to some people. if their choice happens to turn out in a bad way, it could backfire to us.

Could this be read as an support to not list specific instances (until hypothetical privacytools.io XMPP server starts?) and instead link to the previously mentioned lists?

Edit: in the sibling issue we also have a question on how should XMPP be added, as a separate page? https://github.com/privacytoolsIO/privacytools.io/issues/60#issuecomment-377622021

@privacytoolsIO/editorial Do you have new thoughts on this? @JonahAragon commented at https://github.com/privacytoolsIO/privacytools.io/pull/915#pullrequestreview-242417487: > What concerns me about this PR is I'm not sure if recommending specific instances is in the best interest of our users. The point of these federated protocols especially is to promote decentralization. We host social.privacytools.io and chat.privacytools.io as a convenient way for people to join our discussions on privacy and leave centralized services like Twitter and Facebook. We do not host them as a service that everybody should be using, and indeed I would recommend people self-host the software every time I'm asked, even though I personally maintain chat and social.privacytools.io. > > I fear if we recommend a specific instance to people for these services, they won't do the research on their own to make a more informed decision. and so did @blacklight447-ptio at https://github.com/privacytoolsIO/privacytools.io/pull/915#issuecomment-496449555 > I feel the same as jonah, listing these services can feel like an endorsement to some people. if their choice happens to turn out in a bad way, it could backfire to us. Could this be read as an support to not list specific instances (until hypothetical privacytools.io XMPP server starts?) and instead link to the previously mentioned lists? * https://xmpp-servers.404.city * https://list.jabber.at * https://compliance.conversations.im * * * * * Edit: in the sibling issue we also have a question on how should XMPP be added, as a separate page? https://github.com/privacytoolsIO/privacytools.io/issues/60#issuecomment-377622021

Mikaela commented

2019-07-29 08:04:36 +00:00

(Migrated from github.com)

https://www.privacytools.io/software/im/ currently has XMPP clients in a sublist in worth mentioning and I hope that if people are interested in it, they click the link to XMPP.org and thus find https://xmpp.org/getting-started/ which two of the lists mentioned above.

If this is not a satisfying solution, please request reopening with new comments or preferably suggestions.

https://www.privacytools.io/software/im/ currently has XMPP clients in a sublist in worth mentioning and I hope that if people are interested in it, they click the link to XMPP.org and thus find https://xmpp.org/getting-started/ which two of the lists mentioned above. If this is not a satisfying solution, please request reopening with new comments or preferably suggestions.

👍 1

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#141