On Sat, 28 Nov 2020 at 04:00, Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
And sometimes being open to standards makes things worse, not better.
For example, Google's Chat product used to interoperate with the
IETF-standardized XMPP protocol. Unfortunately, federation made it
easy for spammers to send unwanted messages to Google Chat users. And
the XMPP protocol was terrible from a power consumption perspective on
mobile devices. Sure, the protocol could be changed to allow for more
battery-friendly implementations, but see the "years and years and
years" problem described above. And finally, did customers switch in
droves from the closed Apple iMessage ecosystem to the "open" Google
Chat just because it was open, and based on an IETF standard?
Oh, you can't expect me to keep quiet if you're sharing that - I'm afraid it has very little correlation with fact.
Google never implemented any form of serious security for XMPP S2S - that is, the federation protocol - making it a lucrative and easy target for spammers. Instead, while the rest of the community were trying to enforce strict TLS authentication, Google didn't offer TLS at all. Instead, the vanishingly small amount of communication the community got from Google was that they wanted to be able to multiplex sessions heavily and allow indirect certificate auth, which resulted in POSH and other efforts being driven by the community to address these concerns. The community literally bent over backwards to help Google. Google barely participated in the work, and did not implement any of it. All Google needed to do was implement and mandate TLS security, and the vast majority of their spammers would have vanished. They did not.
This was not the only problem with the federation code - for example popular services outside of Google would be inundated with multiple S2S connections as, apparently, Google Talk's buffers would fill and connections would be terminated before they could handle the messages. Again, this suggests that it was not the spamming that was the problem, it was that effort was simply not put into the federation code. Perhaps it was seen as a cost not worth paying, but it was not any kind of technical problem.
Furthermore, XMPP was not, and is not, terrible on mobile. That's pure rubbish, and there is no evidence for it, and plenty of evidence that it performs very well indeed on battery-limit devices. XMPP communication patterns involve server-initiated, lazily acknowledged messages, which is ideal for battery consumption, high latency communications, and adverse network conditions. Individual stanzas (PDUs) are small, and often fit into the small buffers required for cheaper radio states on mobile devices. Having multiple apps perform uncoordinated network activity *is* detrimental to battery life, and so the ideal solution for the entire device is to have a single arbiter of network traffic for backgrounded apps - hence "push" - but holding a TCP session open has no significant battery cost. If a messaging app is going to send only high-priority (ie, immediate wake and delivery) messages over the push channel, then the battery advantages of centralized push rapidly vanish, and the security and complexity issues come to dominate.
Speaking as someone who has spent significant time on mobile device power management for instant messaging apps, it's very efficient to have the app keep the XMPP session open and re-establish it on demand. It's why we spent a lot of effort in getting XEP-0198 and similar solid; work that started in 2007 and was ready long before Google terminated Google Talk. WhatsApp is still loosely based on XMPP. Most if not all device push systems have been based on XMPP at some point, and many still are (for example, Nintendo Switch). As far as I can tell, the only people ever to have said that XMPP is a poor choice on mobile were the team who replaced Google Talk with Google Hangouts (not a relation of the video meeting solution, of course, which used XMPP for years and quite possibly still does in its rebrand as Meet).
Finally, consumers might not have switched to or from Google Talk because of its Open Standards capability, but plenty of people used their own clients to connect - a "Client Choice" concept that Google themselves promoted heavily (see, inter alia: https://support.google.com/code/answer/55690?hl=en) - which allowed Google Talk to expand onto platforms Google didn't want to commit the resources to support (like desktops), and allowed ecosystemic options such as Google Talk SIP gatewaying to be added by third parties. Apple's iChat, by the way, was also XMPP - they switched to the proprietary iMessage at about the same time as Google Talk switched to Google Hangouts - and you could connect iChat to Google Talk, so no need for users to "switch" at all.
Amongst those who developed new features to support this was Microsoft, who provided Google Talk integration into Skype For Business at one point via the Open Standard C2S interface as well as the S2S interface that was supported anyway. Shortly thereafter, Google announced they were killing Google Talk entirely. I genuinely think this was a coincidence, actually - I've always put the demise of Google Talk down to a series of internal power struggles and poor technical investment in Google's IM products, which continues to this day - which goes some way to explain why none of us can keep track of what any of them were or are called.
In summary:
* Federation on Google Talk was insecure, and they wouldn't fix it - hence it was an easy target for spammers.
* XMPP was, and is, significantly more efficient from a power consumption perspective on mobile devices than most other solutions - which is why it's still used so heavily.
* People didn't switch to Google Talk "just because it was open", true, but consumers did see benefits from the use of open standards, and I believe those advantages helped drive growth. In your specific example, people did indeed connect iChat to Google Talk.
Dave.
