4 ms·

Counter argument by XMPP/OMEMO developer: https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/ https://blog.jabberhead.tk/2019/12/29/re-the-ecosyst

Counter argument by XMPP/OMEMO developer: https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/ https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-mo...

tialaramex 7y ago
For Domain Fronting in particular it's embarrassing that pro-distributed people have taken it as a "victory" that AWS and Google disabled domain fronting used as an anti-censorship mechanism for Signal. That's both a terrible look "Ha! Our services are so unpopular nobody even cares to block them" and a grave misunderstanding of the situation. The big CDNs and cloud service providers are actually very enthusiastic about domain fronting, what they blocked was the technical mechanism abused to make it happen, because it causes their reliability teams pain. Domain fronting means you figure out this is a request for thing-a.example.com using SNI, your backend systems cue up the Thing A service... and then during HTTP headers the client insists it intended to talk to thing-b.example.com all along instead and you've got to either give an error or somehow backtrack and make that happen. Doing this is very easy, indeed the default, in say one Apache httpd on a Linux box. But Google or AWS isn't a data centre full of Apache httpds on Linux boxes, it's a bit more complicated than that. When I say they're enthusiastic I don't mean just empty words, the active direction of QUIC, eSNI, the revised HTTP service record for DNS and so on are all aligned with the domain fronting concept, just not in the form of abusing different protocol layers. They want to know early in the connection which service you're intending to reach, while preserving your privacy from snooping governments, etc.
StavrosK 7y ago
> 5 years are not a long time to update the entirety of the internet Given that WhatsApp manages to update its entirety of the internet in a few days, I'd say that is quite a long time. Is there a name for this fallacious "arguing for/against something without comparing it to alternatives"? > But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right? No, the argument is that decentralized services will mostly be centralized anyway due to the fact that centralization can move faster. Everyone has Gmail on the other end because Gmail is better than other services (that is the argument, not what I personally believe, as I think Fastmail is better). Given that decentralization will lead to the existence of a few large points of centralization anyway, we should make those points secure, and centralizing allows us to do that better, the argument goes. > While this is an issue, there are solutions to this problem, one being nomadic identities. The point is that nobody has zero-knowledge nomadic identities. AFAIK Signal were the first ones to come up with a practical implementation a few days ago. > For some reason Marlinspike confuses a decentralized system with a centralized, but distributed system. It even reads “Centralized Service” on his slides… Moxie is talking about a centralized service. It says centralized on the slides, he said centralized twice, the author seems confused here. > These suites act as maps that point a way through the XEP jungle. Yes, and a centralized service needs none of this. Personally, I don't see this article debunking many of the points. Decentralized is better for censorship-resistance, and I prefer it, but it's better for that because centralized platforms aren't usually designed for censorship resistance. Signal knows nothing about its messages, and thus it's much harder to censor people using it. I feel like Moxie made some good arguments, and would like to see some solutions in making decentralized servers and clients more easily upgradable. Signal's approach works for signal, but it also works for almost every other person, since everyone seems happy to use Facebook or Slack or whatnot instead of Riot for their communications. I really like what Mastodon is doing in the federated microblogging space, and hopefully that will extend to other areas.
- shakna 7y ago
  > Given that WhatsApp manages to update its entirety of the internet in a few days, I'd say that is quite a long time. Is there a name for this fallacious "arguing for/against something without comparing it to alternatives"? You're comparing the wrong thing there. The alternative to a protocol specification is not a closed source implementation of a proprietary system. How fast Windows Update can change their architecture doesn't really matter a jot when looking at changes to apt, etc. We can instead look at how long it took to update the IMAP spec to include TLS, or the move towards requiring OAUTH.
  - StavrosK 7y ago
    The original argument was comparing centralized vs decentralized services. We aren't talking about closed vs open, the point remains even if you substitute WhatsApp with Signal.
    - shakna 7y ago
      I wasn't talking about closed/open either. Outlook and Thunderbird are both clients that use known specifications. One is open, one is closed. Getting both updated to the specification takes more time (and in Outlook's case may never happen), then updating something where no specification exists.
lima 7y ago
Good points regarding HTTP, but XMPP is an excellent example on how decentralisation can be detrimental to the user experience. A large percentage of XMPP users are using a lowest-common-denominator client like Pidgin that supports only a small fraction of XEPs. The excellent Conversations client for Android is only on par with Signal if you use it to talk to other Conversations users using a modern server like Prosody. Good luck with simple tasks like sending a picture, otherwise :( The only truly successful decentralized application protocol besides HTTP is SMTP, and even that is becoming increasingly centralized, with vendors like Google extending it with extra features on their own platform. This kind of "protocol ossification" of decentralized protocols is unfortunate, and can be seen even in core internet protocols. Any attempt to improve upon TCP like Multipath TCP has faced huge issues with overly restrictive middleboxes and very slow propagation of new kernels, leading to userspace TCP reimplementations like gQUIC, now standardized as HTTP/3.0.

Counter argument by XMPP/OMEMO developer: https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/ https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-mo...

tialaramex 7y ago

For Domain Fronting in particular it's embarrassing that pro-distributed people have taken it as a "victory" that AWS and Google disabled domain fronting used as an anti-censorship mechanism for Signal. That's both a terrible look "Ha! Our services are so unpopular nobody even cares to block them" and a grave misunderstanding of the situation. The big CDNs and cloud service providers are actually very enthusiastic about domain fronting, what they blocked was the technical mechanism abused to make it happen, because it causes their reliability teams pain. Domain fronting means you figure out this is a request for thing-a.example.com using SNI, your backend systems cue up the Thing A service... and then during HTTP headers the client insists it intended to talk to thing-b.example.com all along instead and you've got to either give an error or somehow backtrack and make that happen. Doing this is very easy, indeed the default, in say one Apache httpd on a Linux box. But Google or AWS isn't a data centre full of Apache httpds on Linux boxes, it's a bit more complicated than that. When I say they're enthusiastic I don't mean just empty words, the active direction of QUIC, eSNI, the revised HTTP service record for DNS and so on are all aligned with the domain fronting concept, just not in the form of abusing different protocol layers. They want to know early in the connection which service you're intending to reach, while preserving your privacy from snooping governments, etc.

StavrosK 7y ago

> 5 years are not a long time to update the entirety of the internet Given that WhatsApp manages to update its entirety of the internet in a few days, I'd say that is quite a long time. Is there a name for this fallacious "arguing for/against something without comparing it to alternatives"? > But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right? No, the argument is that decentralized services will mostly be centralized anyway due to the fact that centralization can move faster. Everyone has Gmail on the other end because Gmail is better than other services (that is the argument, not what I personally believe, as I think Fastmail is better). Given that decentralization will lead to the existence of a few large points of centralization anyway, we should make those points secure, and centralizing allows us to do that better, the argument goes. > While this is an issue, there are solutions to this problem, one being nomadic identities. The point is that nobody has zero-knowledge nomadic identities. AFAIK Signal were the first ones to come up with a practical implementation a few days ago. > For some reason Marlinspike confuses a decentralized system with a centralized, but distributed system. It even reads “Centralized Service” on his slides… Moxie is talking about a centralized service. It says centralized on the slides, he said centralized twice, the author seems confused here. > These suites act as maps that point a way through the XEP jungle. Yes, and a centralized service needs none of this. Personally, I don't see this article debunking many of the points. Decentralized is better for censorship-resistance, and I prefer it, but it's better for that because centralized platforms aren't usually designed for censorship resistance. Signal knows nothing about its messages, and thus it's much harder to censor people using it. I feel like Moxie made some good arguments, and would like to see some solutions in making decentralized servers and clients more easily upgradable. Signal's approach works for signal, but it also works for almost every other person, since everyone seems happy to use Facebook or Slack or whatnot instead of Riot for their communications. I really like what Mastodon is doing in the federated microblogging space, and hopefully that will extend to other areas.

shakna 7y ago
> Given that WhatsApp manages to update its entirety of the internet in a few days, I'd say that is quite a long time. Is there a name for this fallacious "arguing for/against something without comparing it to alternatives"? You're comparing the wrong thing there. The alternative to a protocol specification is not a closed source implementation of a proprietary system. How fast Windows Update can change their architecture doesn't really matter a jot when looking at changes to apt, etc. We can instead look at how long it took to update the IMAP spec to include TLS, or the move towards requiring OAUTH.
- StavrosK 7y ago
  The original argument was comparing centralized vs decentralized services. We aren't talking about closed vs open, the point remains even if you substitute WhatsApp with Signal.
  - shakna 7y ago
    I wasn't talking about closed/open either. Outlook and Thunderbird are both clients that use known specifications. One is open, one is closed. Getting both updated to the specification takes more time (and in Outlook's case may never happen), then updating something where no specification exists.

lima 7y ago

Good points regarding HTTP, but XMPP is an excellent example on how decentralisation can be detrimental to the user experience. A large percentage of XMPP users are using a lowest-common-denominator client like Pidgin that supports only a small fraction of XEPs. The excellent Conversations client for Android is only on par with Signal if you use it to talk to other Conversations users using a modern server like Prosody. Good luck with simple tasks like sending a picture, otherwise :( The only truly successful decentralized application protocol besides HTTP is SMTP, and even that is becoming increasingly centralized, with vendors like Google extending it with extra features on their own platform. This kind of "protocol ossification" of decentralized protocols is unfortunate, and can be seen even in core internet protocols. Any attempt to improve upon TCP like Multipath TCP has faced huge issues with overly restrictive middleboxes and very slow propagation of new kernels, leading to userspace TCP reimplementations like gQUIC, now standardized as HTTP/3.0.