4 ms·

The whole issue with XMPP is that yes, in theory you could do e2ee accross multiple servers and devices but only if all the servers support the right extensions

The whole issue with XMPP is that yes, in theory you could do e2ee accross multiple servers and devices but only if all the servers support the right extensions and the clients support them properly.

Andrew_nenakhov 5y ago
The whole issue with XMPP is that users are brainwashed to demand e2ee even without fully understanding what it means and what unavoidable downsides in UX true e2ee brings. Most users would have the same level of security as with e2ee by simply running their own server. E2ee mostly helps against service owner you don't trust, so just be your own service owner and have nicely syncing history and server side search.
- pkulak 5y ago
  I totally agree, though I run my own Matrix server and still find value in e2ee because I don't really trust AWS (or maybe my ability to secure AWS). I suppose I could run the service on a machine in my house, but that's not going to be good for uptime, the NAT screws things up, etc. Plus, even that could be hacked if I fuck something up.
  - Andrew_nenakhov 5y ago
    If you run a legal operation, you don't have to worry about hosting company admins logging into your database. That can be done only on police inquiry.
    - pkulak 5y ago
      Eh. I'm still not storing passwords, keys, documents, photos, et all, plain text in some RDS database.
      - Andrew_nenakhov 5y ago
        On photos/documents, you are in a tiniest of minorities: ~99% of all smartphone users store photos in unencrypted cloud services like Google Photos and use Google Docs and MS Office 365. (But but chats are surely the holy cow and must be encrypted - strictly demand those same users, paradoxically) And no modern server stores passwords in plain text, and keys are not stored on servers at all.
- NoGravitas 5y ago
  For single-user XMPP servers, this is true, but on the other hand, not everyone is able to run their own server. I will say, that even though I kind of like the architecture of XMPP better, the Matrix people have put in tremendous amounts of work to overcome the UX problems with e2ee, in particular the multidevice problem (where I have a laptop and a phone logged into the same account and try to participate in the same encrypted conversation from both).
MattJ100 5y ago
This is not a problem with XMPP, but any open ecosystem. There's no way to force third-party developers to implement stuff, especially when they are open-source volunteers working in their free time. XMPP does have this feature parity issue, though there is a good selection of modern active XMPP clients across platforms with important features like end-to-end encryption and calls. But you're right - there's no way to stop people trying to use clients like Pidgin, which have been essentially frozen in time for a decade. Matrix is newer, so has less diversity, and lots of resources to put into the Element clients. However there certainly is exactly the same problem growing in the Matrix ecosystem too - there are many features supported by Element that are not (yet?) implemented in popular alternative clients such as FluffyChat. The best you can do is ensure that when two clients communicate without the same set of features, that you degrade gracefully and securely (e.g. the worst case I can imagine would be E2EE that silently becomes unencrypted if not supported by your contact - thankfully that's not how it's done) to the best common feature set between the two.
- jayd16 5y ago
  I think a major problem is there isn't (last I looked) a clear set of feature tiers or a collection of XEPs that are given names and tests. Instead of "oh MS teams supports up to xmpp2017" it's just a crapshoot.
  - MattJ100 5y ago
    Here's what you're looking for: https://xmpp.org/about/compliance-suites/ https://xmpp.org/about/compliance-suites/ Compliance suites are reviewed, updated and published annually with the recommended set of features across a range of different categories.
    - jayd16 5y ago
      Well there go. I guess now that I think of it, last I looked was MUC support in 2012 or so. Looks like it's on the list but as "* Support can be enabled via an external component or an internal server module/plugin." So...a crap shoot, haha.
zaik 5y ago
> in theory you could do e2ee accross multiple servers and devices I use XMPP to send e2ee messages to friends on other servers and clients every day, so it's very much not just 'in theory'.
upofadown 5y ago
> ...but only if all the servers support the right extensions... That is only for OMEMO (OpenPGP and OTR require nothing of the server) and you can easily check a potential server for the things that OMEMO depends on by doing a normal server compliance check here: * https://compliance.conversations.im/ https://compliance.conversations.im/ In the same way, if you pick a client that does not support something then that thing will not work. But why pick such a client in the first place?

The whole issue with XMPP is that yes, in theory you could do e2ee accross multiple servers and devices but only if all the servers support the right extensions and the clients support them properly.

Andrew_nenakhov 5y ago

The whole issue with XMPP is that users are brainwashed to demand e2ee even without fully understanding what it means and what unavoidable downsides in UX true e2ee brings. Most users would have the same level of security as with e2ee by simply running their own server. E2ee mostly helps against service owner you don't trust, so just be your own service owner and have nicely syncing history and server side search.

pkulak 5y ago
I totally agree, though I run my own Matrix server and still find value in e2ee because I don't really trust AWS (or maybe my ability to secure AWS). I suppose I could run the service on a machine in my house, but that's not going to be good for uptime, the NAT screws things up, etc. Plus, even that could be hacked if I fuck something up.
- Andrew_nenakhov 5y ago
  If you run a legal operation, you don't have to worry about hosting company admins logging into your database. That can be done only on police inquiry.
  - pkulak 5y ago
    Eh. I'm still not storing passwords, keys, documents, photos, et all, plain text in some RDS database.
    - Andrew_nenakhov 5y ago
      On photos/documents, you are in a tiniest of minorities: ~99% of all smartphone users store photos in unencrypted cloud services like Google Photos and use Google Docs and MS Office 365. (But but chats are surely the holy cow and must be encrypted - strictly demand those same users, paradoxically) And no modern server stores passwords in plain text, and keys are not stored on servers at all.
NoGravitas 5y ago
For single-user XMPP servers, this is true, but on the other hand, not everyone is able to run their own server. I will say, that even though I kind of like the architecture of XMPP better, the Matrix people have put in tremendous amounts of work to overcome the UX problems with e2ee, in particular the multidevice problem (where I have a laptop and a phone logged into the same account and try to participate in the same encrypted conversation from both).

MattJ100 5y ago

This is not a problem with XMPP, but any open ecosystem. There's no way to force third-party developers to implement stuff, especially when they are open-source volunteers working in their free time. XMPP does have this feature parity issue, though there is a good selection of modern active XMPP clients across platforms with important features like end-to-end encryption and calls. But you're right - there's no way to stop people trying to use clients like Pidgin, which have been essentially frozen in time for a decade. Matrix is newer, so has less diversity, and lots of resources to put into the Element clients. However there certainly is exactly the same problem growing in the Matrix ecosystem too - there are many features supported by Element that are not (yet?) implemented in popular alternative clients such as FluffyChat. The best you can do is ensure that when two clients communicate without the same set of features, that you degrade gracefully and securely (e.g. the worst case I can imagine would be E2EE that silently becomes unencrypted if not supported by your contact - thankfully that's not how it's done) to the best common feature set between the two.

jayd16 5y ago
I think a major problem is there isn't (last I looked) a clear set of feature tiers or a collection of XEPs that are given names and tests. Instead of "oh MS teams supports up to xmpp2017" it's just a crapshoot.
- MattJ100 5y ago
  Here's what you're looking for: https://xmpp.org/about/compliance-suites/ https://xmpp.org/about/compliance-suites/ Compliance suites are reviewed, updated and published annually with the recommended set of features across a range of different categories.
  - jayd16 5y ago
    Well there go. I guess now that I think of it, last I looked was MUC support in 2012 or so. Looks like it's on the list but as "* Support can be enabled via an external component or an internal server module/plugin." So...a crap shoot, haha.

zaik 5y ago

> in theory you could do e2ee accross multiple servers and devices I use XMPP to send e2ee messages to friends on other servers and clients every day, so it's very much not just 'in theory'.

upofadown 5y ago

> ...but only if all the servers support the right extensions... That is only for OMEMO (OpenPGP and OTR require nothing of the server) and you can easily check a potential server for the things that OMEMO depends on by doing a normal server compliance check here: * https://compliance.conversations.im/ https://compliance.conversations.im/ In the same way, if you pick a client that does not support something then that thing will not work. But why pick such a client in the first place?