Re: Google, etc, and their proprietary protocols

[Dave Cridland <[e-mail]>]

On Sat, 28 Nov 2020 at 04:00, Theodore Y. Ts'o <[e-mail]> 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.