Interoperability and competition [was: Google, etc, and their proprietary protocols]

[Mark Nottingham <[e-mail]>]

So, what's interesting to me here is that we have a very good possibility of at least one, and perhaps many, jurisdictions imposing interoperability requirements on various digital platforms as a remedy for competition issues.*

One path to interoperability is to require the target to open their existing interfaces up. But that was tried in United States v Microsoft Corp., and it wasn't really effective as a remedy. What's designed for internal or single-party use is often not appropriate for broad interoperability between disparate implementers. 

Another would be for the competition authority to constitute a body that's in charge of drafting technical standards that the target is required to comply with. This is being discussed actively in a number of places, and one way to look at the work on the Consumer Data Right in Australia, the UPI in India, and Open Banking in the UK as just this. However, it's not clear how that would work for mass consumer applications like social networking, etc. Also, it's very likely that this would either become country-specific, or the first large country who defined one in an area would 'win', which might be problematic.

A third option that hasn't been discussed as much is leveraging existing SDOs to do the technical work that enables interoperability -- ideally using already-existing protocols and formats where necessary. There are lots of open questions about how this would work, but first I wonder how the IETF would react -- if a competition authority came to us and said "if you create a standard that promotes interoperability for scope _foo_ in timeframe _bar_ using your normal process, we will leverage that in our remedy", would we rise to the occasion? 

Past history like DNT in the W3C suggests that there's a will in at least some standards fora to provide affordances for the law. Can we do the necessary coordination to actually make it work? Would we be able to deliver?

Cheers,


* With lots of handwaving about the exact nature of those issues, WRT abuse of power vs market domination vs self-dealing vs... - the point is that there seems to be an emerging consensus amongst the relevant authorities that there are competition issues, and now the big question is the nature of the remedies. Interoperability is one of the frontrunners; it's not the only potential remedy, and it's not appropriate in many cases, but it could be an important tool.



> On 28 Nov 2020, at 2:56 am, Warren Kumari <[e-mail]> wrote:
> 
> On Thu, Nov 26, 2020 at 3:34 PM 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.
>> 
>> Does anybody know the history and/or why we suffer this mess? I mean,
>> the base level mechanisms seem pretty well understood.
>> 
> 
> Hi there,
> 
> So, there are a number of things at play here.
> 
> Firstly is that there many of the things which you are probably
> viewing as "protocols" are more APIs/formats. In many cases these APIs
> are very narrowly focused, quite specific (and so there isn't really
> interoperability), and change frequently as new features are added,
> etc. Keeping an IETF standard updated every time the API changes would
> limit how quickly features can be added.
> 
> 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.
> 
> Basically all drafts written by Googlers are because that individual
> used some of their discretionary time to participate; often this
> doesn't happen because none of the people working on $whatever felt
> like there was utility in standardizing it, or because it seemed like
> the benefit of having $whatever become an RFC was not worth the
> time/effort/work.
> 
> I personally believe in the IETF and would like more Googlers to
> participate and standardize things **if they are actually useful to
> standardize**.
> 
> 
>> Mike, cheers and happy T-day for those who celebrate it :)
> 
> Enjoy the leftover turkey / less email weekend :-)
> W
> 
>> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 

--
Mark Nottingham   https://www.mnot.net/