Re: Google, etc, and their proprietary protocols

["Theodore Y. Ts'o" <[e-mail]>]

On Fri, Nov 27, 2020 at 10:56:14AM -0500, Warren Kumari wrote:
> Publishing documentation on how to use an API on the
> Google (internal) site is easy; standardizing through the IETF process
> takes many months/years, often requiring travel, extensive time on
> mailing lists, etc. One exception to this is QUIC. QUIC was started in
> Google, but, because of the broad impact and interoperability to the
> core plumbing of the Internet, it was clear that bringing it to the
> IETF would result in a more widely deployed and used protocol.

One thing that's worth noting about QUIC is that it first appeared in
Google's Chrome in 2013; it entered the IETF standardization process
in 2015, with the working group established in 2016.  And as of 2020,
QUIC is finally in Last Call.

No doubt QUIC has improved significantly in the intervening four
years.  But if you are trying to ship product for the Christmas
holiday season, it's hard when the standardization process takes years
and the timeline is not under a company's control.  So sure, you can
ship versions based on some draft version (CloudFlare was deploying
something based on QUIC I-D version 14 as a beta in 2018), but there
will almost certainly be interoperability problems if different
companies are shipping based on different versions of the draft spec
--- in which case the benefits of standardization will have been
seriously diluted.

On Thu, 26 Nov 2020 12:33:57 -0800, Michael Thomas <[e-mail]> wrote:
>
> I know there are a whole lot of things that Google is doing for configuration,
> casting of urls (cf chromecast), etc which use proprietary protocols. Lots of
> other vendors are inventing the same or similar wheels. Can anybody tell me
> why these haven't been standardized? Is it politics? It sure is a PITA to not
> be able to send a URL to Apple Device or cast from Firefox onto my chromecast.
> I assume that this tangle applies for every other ecosystem like Apple and
> Amazon.

One important thing to remember is that IETF is a volunteer
organization.  So the companies involved would need to be willing to
send engineers to work on the standardization process --- for years
and years and years.

And for what benefit?  As far as Apple and Amazon is concerned,
customer lock-in to their ecosystem is a *good* thing.  Heck, for a
while, Amazon refused to sell any of Google's chromecast product on
their website.  So from a business perspective, if you can't convince
Amazon or Apple or Google why they should spend person-years if not
person-decades standardizing something, which might delay rollout of
the product, and perhaps make it easier for the competition to get
customers to transfer their ecosystem allegiance from (say) Apple to
Amazon --- why should they do it?

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?

Well, no....

So there are certainly some people who prefer open, standards driven
protocols.  But if they are not a sufficient large part of the
customer base, such that there is a business advantage, and the
standards route has velocity disadvantages and other downsides such as
making life easier for spammers, it is really quite unreasonable to
expect companies to do something just because you want something based
on interoperable standards.

Cheers,

						- Ted