Subject: Google, etc, and their proprietary protocols

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Nov 2020 12:33:57 -0800

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.

Mike, cheers and happy T-day for those who celebrate it :)

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 27 Nov 2020 11:45:04 +0100 (CET)

> Il 26/11/2020 21:33 Michael Thomas <[email-masked]> ha scritto:
>  

Well, whether an open standard exists is often not the driving factor in choosing between using a standard or a custom protocol - or, the open standard is taken and used in non-interoperable ways, through incompatible extensions or simply by refusing connections from third party clients.  Instant messaging is a trove of examples of this.  Social single sign-on is another example.  It does not make a lot of sense to put effort into standardizing something, if the market leaders do not want to interoperate.

> Does anybody know the history and/or why we suffer this mess? 

I suspect that the reason is that we now have a generation of Internet CEOs that noticed that you can make a lot more money if you conquer the entire market and then lock your users into a walled garden and refuse to interoperate, so that others cannot take the market away from you just by being better.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Nov 2020 10:56:14 -0500

> 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

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 27 Nov 2020 11:30:28 -0500

Michael Thomas wrote:
> 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.
>
Because Google, contrary to stated position, can be intentionally evil.  
It started when they broke calendaring.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Nov 2020 14:14:38 -0800

> limit how quickly features can be added.

There is clearly an over the wire(less) protocol going on between my 
chrome browser and my chromecast which sends a URL (I assume) and some 
mechanism for authentication as needed so the chromecast pull up the 
content (chromecast does not dogleg through your device, unlike 
AppleTV). Or some such voodoo. It's probably the same/similar for 
sending a URL to another google browser. They also seem to have a 
VNC-like protocol which is used for screen sharing. For all I know it is 
just repackaged VNC.

One bad thing about it being a closed protocol is that I have no idea 
whether whatever voodoo their using to allow my chromecast to have 
access to various streaming services is secure and safe. The larger 
issue is that there are probably a dozen or more companies all doing 
similar things with varying degrees of security competence.

One of the best things that IETF has brought in the last 20 years is 
eyeballs with security clue to protocols whose authors have much less 
clue, and especially in the beginning none at all. So now we're giving 
all of these household items access to intimate details of our lives 
where we don't even know whether they are properly secured. The one 
lasting lesson of the LinkedIn unsalted password debacle is that even 
really big companies can do really stupid things, and with network 
protocols it's even worse.

But the bottom line of all of this is that it's a mess, and all of their 
squabbling and posturing are making the user experience terrible.

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Nov 2020 12:52:28 +1100

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 <[email-masked]> wrote:
> 

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

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 27 Nov 2020 23:00:04 -0500

> 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 <[email-masked]> 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

---

From: Christian Huitema <[email-masked]>
Date: Fri, 27 Nov 2020 20:20:03 -0800

> QUIC is finally in Last Call.
Sometimes, the process is to blame. Sometimes, writing the spec just 
requires a long time. In the case of QUIC, there was quite a bit of the 
latter. The working group engaged into what amounts to a discovery 
process, iterating the design as issues surfaced in early deployments 
and interoperability tests. Doing something like QUIC was not exactly 
simple.
> --- in which case the benefits of standardization will have been

In fact, Google kept shipping successive versions of "Google QUIC" in 
their products during all these years, progressively integrating parts 
of the IETF design in their code, until arriving at interoperability 
with the IETF specification a few months ago, following draft-29. Other 
companies followed the same pattern, deploying successive drafts in 
controlled environments such as on an internal "back end" network, or 
between a proprietary app an their servers. They learned a lot in the 
process, and contributed to the standardization.

One way the working group dealt with that was by conducting regular 
interoperability tests based on specific draft numbers, which ensured 
that some draft versions will be well supported by many implementations. 
Another way was the support of version negotiation in the protocol. But 
mostly, the rule was to only deploy interim QUIC versions on systems 
that supported frequent software upgrades.

I don't know whether this will apply to other IETF endeavors, but it is 
probably worth documenting.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Nov 2020 00:27:19 -0500

On 11/27/20 8:52 PM, Mark Nottingham wrote:

> 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?

It's a _very_ interesting question.  On one hand, that seems squarely 
within IETF's scope and purpose.  On another hand, I wonder whether IETF 
consensus would be willing to support the constraints that some 
countries would want to impose, or perhaps, whether different countries 
would want to impose mutually incompatible constraints and be unwilling 
to let IETF sort out the differences.

Figuring out where to draw the line between IETF's purview and the 
various countries' purviews might be a necessary precondition for that 
kind of work.

Keith

---

From: Dave Cridland <[email-masked]>
Date: Sat, 28 Nov 2020 12:20:09 +0000

> 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.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 28 Nov 2020 14:17:55 -0800

> on interoperable standards.
Sure I understand that they all want walled gardens but from a consumer 
standpoint it is completely impractical. Some people will use Apple, 
some people will use Google, some people will use Amazon and two or more 
of them exist in a huge swath of the households. This leads to a 
complete mess of incompatibilities, missing features, and other bizarre 
things like "can i shut my laptop while this thing is playing?" All of 
this is bewildering to people who aren't tech savvy and ain't much 
better for those of us who are.

And yes, it takes time and money to standardize things, but it takes 
time and money to roll your own, maintain, and keep up with Joneses. 
TANSTAAFL.

And then there is security. I had better Google Fu this time around and 
found some developer documentation for chromecast the protocol. After 
some hunting, I found that the sending app (ie, phone) delivers a URL to 
the media to be played, and the users credentials apparently in plain 
text to the chromecast. Is that OK? It sounds a lot like it has the 
problem that OAUTH tries to avoid which is doglegging credentials 
through something else, perhaps hostile. Apparently their API now allows 
for apps to be written both on the sender side, and on the chromecast 
side so it sounds like it's no longer the case "oh, i can trust google 
not steal my credentials". what is the threat model here? I could even 
be wrong about half of this and still illustrates my point that closed 
box protocol designs like this in IoT land are scary.

All of the above in your message could be said of Apple and Microsoft 
years ago when a lot of the media stuff was getting hashed out, for 
example. Both would have been delighted to have a walled garden if they 
could get away with it. But somehow they managed to bite the bullet and 
cooperate in many important cases. Think about the combinatorics of 
misery had they not and then grafting on all of new stuff. Yuck.

Mike, yes i know i'm pushing on string, but maybe it's a string worth 
pushing for a bit

---

From: Michael Thomas <[email-masked]>
Date: Sat, 28 Nov 2020 14:20:55 -0800

On 11/27/20 8:20 PM, Christian Huitema wrote:
> with the IETF specification a few months ago, following draft-29. 
> Other companies followed the same pattern, deploying successive drafts 
> in controlled environments such as on an internal "back end" network, 
> or between a proprietary app an their servers. They learned a lot in 
> the process, and contributed to the standardization.
>
> that some draft versions will be well supported by many 
> implementations. Another way was the support of version negotiation in 
> the protocol. But mostly, the rule was to only deploy interim QUIC 
> versions on systems that supported frequent software upgrades.
>
> I don't know whether this will apply to other IETF endeavors, but it 
> is probably worth documenting.
>
>
DIdn't the same sort of process happen with websockets? Is that back and 
forth really that unusual?

Mike

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 28 Nov 2020 17:30:09 -0800

We followed the similar process in RIFT (Routing in Fat Trees) development.

Regards,
Jeff

> On Nov 28, 2020, at 14:21, Michael Thomas <[email-masked]> wrote:
> 
> 
>> In fact, Google kept shipping successive versions of "Google QUIC" in their products during all these years, progressively integrating parts of the IETF design in their code, until arriving at interoperability with the IETF specification a few months ago, following draft-29. Other companies followed the same pattern, deploying successive drafts in controlled environments such as on an internal "back end" network, or between a proprietary app an their servers. They learned a lot in the process, and contributed to the standardization.
>> 
>> One way the working group dealt with that was by conducting regular interoperability tests based on specific draft numbers, which ensured that some draft versions will be well supported by many implementations. Another way was the support of version negotiation in the protocol. But mostly, the rule was to only deploy interim QUIC versions on systems that supported frequent software upgrades.
>> 
>> I don't know whether this will apply to other IETF endeavors, but it is probably worth documenting.
>> 
>> 
> DIdn't the same sort of process happen with websockets? Is that back and forth really that unusual?
> 
> Mike
>

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 30 Nov 2020 17:36:28 +0100 (CET)

> Il 28/11/2020 02:52 Mark Nottingham <[email-masked]> ha scritto:
>  
> 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.*

I am quite involved in the European one, so I am happy to see this mentioned here. Also, it is rare to have opportunities to discuss this topic with non-Europeans and with people from the global platforms, and it is a pity.

> 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. 

This is the likely model in Europe, where the Commission already has procedures to "recognize" standards developed by SDOs and bless them. There would still be a regulatory authority (a single European one or a constellation of national ones) that would define the policy objectives, but then the SDOs would be scouted to find suitable existing standards, or to see if any of them wants to develop one.

> 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? 

I'd also like to know. However, I'd say that if Europe ever wanted to do something like this, perhaps the first door that would be knocked upon would be ETSI, not the IETF. This is due not just to the basic fact that the "E" in ETSI stands for European, but also to the fact that, in the general perception, the IETF does not seem to like cooperating with governments, or even to recognize them a role.

Also, there is indeed some concern that open, consensus-based SDOs where the global platforms are strongly represented could fail in producing any suitable standard, as such a standard would negatively affect the interests of a significant part of the participants, which would thus prevent consensus from ever being reached.  This explains, for example, why the bylaws of the GAIA-X Foundation(*) exclude non-European companies (including European subsidiaries of non-European groups) from applying for leadership positions.

> 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. 

I would not mention DNT to governments as an example of how this cooperation can work, given its total failure...

> Can we do the necessary coordination to actually make it work? Would
> we be able to deliver?

And would the IETF have an answer to the concern above?

(*) GAIA-X is the effort launched by the German and French governments to promote a standard framework for cloud infrastructure, so that customers could freely move across vendors without being locked in.
-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Dec 2020 11:43:02 +1100

> On 1 Dec 2020, at 3:36 am, Vittorio Bertola <[email-masked]> wrote:
> 
> 
> 

It seems like there's been a lot more interest in places like Australia and even the US with recent reports. :)

> I'd also like to know. However, I'd say that if Europe ever wanted to do something like this, perhaps the first door that would be knocked upon would be ETSI, not the IETF. This is due not just to…

That's interesting. I'd characterise it slightly differently -- the IETF does not like cooperating with governments on projects that are perceived as harming the Internet. From what I've seen there's pretty strong concern held by many here about consolidation of power on the Internet, and a fair amount of experience in areas that could be helpful (e.g., JSON formats, Atom publishing, HTTP APIs), so it might be a good fit.

ETSI is an attractive venue (that unfortunately I haven't participated in yet), but I'd be concerned that the membership rules and weighted voting procedures could affect the result; many of the potential work items here (e.g., APIs for social networking) would benefit from broad participation and a focus on end user needs, rather than being unduly influenced by large corporate concerns. I can imagine that some big vendors would still be attracted to unwieldy solutions like SOAP here...

Of course, if the work items were just lightweight profiles of existing specifications (e.g., Atom, ActivityStreams, etc.), that might be workable. I see that ETSI has the ability to enter into a Partnership Project; for some items, perhaps it might be worth considering use of that mechanism to involve orgs like the IETF.

> Also, there is indeed some concern that open, consensus-based SDOs where the global platforms are strongly represented could fail in producing any suitable standard, as such a standard would negati…

Absolutely; that's a risk that's going to be very front-of-mind for venues like the W3C. However, if Europe tries to keep too tight of a hold on the reins, it's going to make it look like a regional solution, and increase the chances of fragmentation.

It's also interesting to me when the IETF is portrayed as being vendor-driven/owned. While it's certainly dominated by tech people, and they have a number of limitations, I think most vendors would say that they do not feel in control of the discussions here; there are too many individuals who prioritise the Internet overall over their employer at the moment (acknowledging that some of them prioritise their view of the technology, rather than the users of the Internet in doing so).

In any of these fora, the practicalities of decision-making under these conditions needs some consideration. For example, if a competition authority tells BigPlatformCorp that it must expose an API to be standardised by the FooWG, how does the FooWG consider input from BigPlatformCorp participants? What if those participants say that BigPlatformCorp can't implement a proposal -- how do you evaluate and weigh that objection (e.g., how much should their costs be considered)? Will appeals from them be handled in a special way? If the normal process isn't adequate to achieve the outcome you want, would adopting special rules to accommodate a mandate from a competition authority cause anti-trust issues in other jurisdictions? And so on.

> I would not mention DNT to governments as an example of how this cooperation can work, given its total failure...

:)  Yes, that wasn't done well; it always seemed like an instance of hope-based standardisation. I think we'd all benefit if there was some more thought (and research?) about why it did, and how we could do better.

Cheers,