4 ms·

> This is much less critical when the protocol is federated False. Federated protocols typically have a lot more, as there is routing data between servers. The

by dngray 2y ago

> This is much less critical when the protocol is federated False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix. The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.

AshamedCaptain 2y ago
Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.
- dngray 2y ago
  > Routing data between servers and networks you literally control This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting. TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population. > Leaking metadata to a centralized service is simply inevitable by pure physics Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Signal has a lot less metadata than XMPP.
  - AshamedCaptain 2y ago
    XMPP largest deployments are in enterprises. I do not disagree with this. To go from there to "it is not designed to be a private protocol" is a stretch. And does that invalidate any of my points? > Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Yeah, no. Timing alone is enough to clearly distinguish a sender, and any attempts like these is pure astronaut engineering to obfuscate something that is trivial to recover by a million side channels. There is just No. Way. to eliminate the problem of metadata leaks to a centralized server, other than making it practically distributed/P2P. The more time it takes for people to realize this, the worse society becomes.
    - dngray 2y ago
      > And does that invalidate any of my point Yes it does, because the threat model there is not the server itself. You trust that as it's your employer's server and you're using it for work related purposes. > Timing alone is enough to clearly distinguish a sender It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
      - AshamedCaptain 2y ago
        > You trust that as it's your employer's server and you're using it for work related purposes. Yes, that is the point. Or it is my home server sitting at my router serving my family. I have been arguing that if I can trust the server then the discussion about E2EE becomes less relevant. > It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol. And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
        dngray 2y ago
        > Or it is my home server sitting at my router serving my family. That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet. For a lot of people it wouldn't even be possible if they wanted to and that's not getting into the technical investment they would have to make in knowing how to do such a thing in the first place. > And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it. It's a lot easier than simply not having that data server side in the first place like Signal for example.
        AshamedCaptain 2y ago
        > That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet. Frankly, that works for the majority of XMPP users -- let's not forget about that. But yes, this is a problem today for many consumers. However, I see this as a much better direction for the Internet as a whole to take -- see efforts such as ownCloud and the like -- , rather than just conceding defeat and accepting a centralized Internet, or worse: the extremely dangerous idea that centralization increases security. Which should only be seen as the non-sense it is. > It's a lot easier than simply not having that data server side in the first place like Signal for example. You still do not get the point here at all. This is not about storage. This is not about the server implementation. As long as there is a communication at all between me and the server and then my contacts and the server, it is irrelevant if you are storing the roster or not. ANYONE (*anyone with access to that server) can easily pick it up. In fact, it is HARD not to leak it up, even by accident. Barring a P2P Freenet-like thing, this is _unavoidable_. (and even with P2P/Freenet/Onion/whatever it's not trivial) And due to the nature of IMs, metadata is practically as big an issue than protecting the payload itself.
  - ementally 2y ago
    https://simplex.chat/ https://simplex.chat/ has lesser metadata than Signal[1][2], Matrix and XMPP. SimpleX Chat is going to move to Groups V2[3] very soon to make the experience much better. [1]: https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-... [2]: https://arxiv.org/abs/2305.09799 https://arxiv.org/abs/2305.09799 [3]: https://github.com/simplex-chat/simplex-chat/issues/4620#issuecomment-2275153645 https://github.com/simplex-chat/simplex-chat/issues/4620#iss...
    - Tmpod 2y ago
      SimpleX looks really interesting. Will have to read on it. Seems somewhat like "magic", is there any gotcha?
      - ementally 2y ago
        See "We plan to add:" https://github.com/simplex-chat/simplex-chat?tab=readme-ov-file#privacy-and-security-technical-details-and-limitations https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f... but the first 2 points were already implemented as shown in their Roadmap[1], so they are going to probably remove them [1]: https://github.com/simplex-chat/simplex-chat?tab=readme-ov-file#roadmap https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f...

by dngray 2y ago

AshamedCaptain 2y ago

Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.

dngray 2y ago
> Routing data between servers and networks you literally control This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting. TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population. > Leaking metadata to a centralized service is simply inevitable by pure physics Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Signal has a lot less metadata than XMPP.
- AshamedCaptain 2y ago
  XMPP largest deployments are in enterprises. I do not disagree with this. To go from there to "it is not designed to be a private protocol" is a stretch. And does that invalidate any of my points? > Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Yeah, no. Timing alone is enough to clearly distinguish a sender, and any attempts like these is pure astronaut engineering to obfuscate something that is trivial to recover by a million side channels. There is just No. Way. to eliminate the problem of metadata leaks to a centralized server, other than making it practically distributed/P2P. The more time it takes for people to realize this, the worse society becomes.
  - dngray 2y ago
    > And does that invalidate any of my point Yes it does, because the threat model there is not the server itself. You trust that as it's your employer's server and you're using it for work related purposes. > Timing alone is enough to clearly distinguish a sender It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
    - AshamedCaptain 2y ago
      > You trust that as it's your employer's server and you're using it for work related purposes. Yes, that is the point. Or it is my home server sitting at my router serving my family. I have been arguing that if I can trust the server then the discussion about E2EE becomes less relevant. > It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol. And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
      - dngray 2y ago
        > Or it is my home server sitting at my router serving my family. That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet. For a lot of people it wouldn't even be possible if they wanted to and that's not getting into the technical investment they would have to make in knowing how to do such a thing in the first place. > And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it. It's a lot easier than simply not having that data server side in the first place like Signal for example.
        AshamedCaptain 2y ago
        > That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet. Frankly, that works for the majority of XMPP users -- let's not forget about that. But yes, this is a problem today for many consumers. However, I see this as a much better direction for the Internet as a whole to take -- see efforts such as ownCloud and the like -- , rather than just conceding defeat and accepting a centralized Internet, or worse: the extremely dangerous idea that centralization increases security. Which should only be seen as the non-sense it is. > It's a lot easier than simply not having that data server side in the first place like Signal for example. You still do not get the point here at all. This is not about storage. This is not about the server implementation. As long as there is a communication at all between me and the server and then my contacts and the server, it is irrelevant if you are storing the roster or not. ANYONE (*anyone with access to that server) can easily pick it up. In fact, it is HARD not to leak it up, even by accident. Barring a P2P Freenet-like thing, this is _unavoidable_. (and even with P2P/Freenet/Onion/whatever it's not trivial) And due to the nature of IMs, metadata is practically as big an issue than protecting the payload itself.
- ementally 2y ago
  https://simplex.chat/ https://simplex.chat/ has lesser metadata than Signal[1][2], Matrix and XMPP. SimpleX Chat is going to move to Groups V2[3] very soon to make the experience much better. [1]: https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-... [2]: https://arxiv.org/abs/2305.09799 https://arxiv.org/abs/2305.09799 [3]: https://github.com/simplex-chat/simplex-chat/issues/4620#issuecomment-2275153645 https://github.com/simplex-chat/simplex-chat/issues/4620#iss...
  - Tmpod 2y ago
    SimpleX looks really interesting. Will have to read on it. Seems somewhat like "magic", is there any gotcha?
    - ementally 2y ago
      See "We plan to add:" https://github.com/simplex-chat/simplex-chat?tab=readme-ov-file#privacy-and-security-technical-details-and-limitations https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f... but the first 2 points were already implemented as shown in their Roadmap[1], so they are going to probably remove them [1]: https://github.com/simplex-chat/simplex-chat?tab=readme-ov-file#roadmap https://github.com/simplex-chat/simplex-chat?tab=readme-ov-f...