I do think it's important to say that this isn't a sure-fire deal. We had stuff like NaCl (native code in the browser) that basically died off, and other options as well.
Inversely, SPDY is not what the standard is, and Google instead pulled stuff it learned into HTTP/2. This seems like a positive aspect to me.
It's important to be wary of things that Google won't bring up, but overall I feel like we're getting a lot of benefit from having an implementer "beta test" stuff in this way.
Google using the standards process to release new things is exactly what we should want and see. You make it like it is some nefarious behavior. Geeze.
Google has offered things for standards which were changed by the standards group and Google adopted the change.
Google could just keep it all closed if they want. Honestly wonder if they will not in the future with posts like yours. Why do it?
Designing a new protocol to be used at internet scale is really hard. Having the ability to test that on a significant amount of traffic before refining and standardizing is a huge advantage that few groups on the planet are able to make use of. From the IETF's perspective, I would look skeptically upon a new standard that someone dreamed up but had little to no practical real-world data to show how it behaves in practice.
But I also want them to avoid ramming standards down the IETF's throat. If, after due consideration, the IETF says "no" to a new standard, I want Google to stand down and abandon it. If the IETF thinks it's a good idea and is willing to work with Google to iron out issues and standardize in a public manner, then that's the ideal outcome.
Right now, I'm convinced we need Google's help to make it harder for governments and ISPs to censor and prioritize.
After that, we'll deal with Google.
We can talk about network neutrality whatever we want - but these companies have built technological capabilities to have "little bit bigger share".
So, probably after some time it is too late to deal with Google:)
What is your preferred course here? Google has provided free as in freedom source code for all of the above, and in some cases pushed the code upstream. Granted, it will take small players longer to see the benefits of these techs, since they can't afford to integrate it themselves and must wait for vendors to include it. But small players usually have worse user experience regardless of the mechanism. Proposed standards are just one way that happens.
I think it's far more important to deal with Google than hand them the keys to the kingdom while fighting smaller fish.
The good part is that it focus on fixing the government. That's the correct entity to fix.
Google is effectively the actual determiner of Internet standards. As the article notes, Google implemented QUIC on their servers and their browsers, and therefore, 7% of Internet traffic is already QUIC-based, despite it not being officially accepted at this point. This is essentially the same as what happened with SPDY at the time.
As Google controls both the primary source of Internet traffic (up to 35-40% of all Internet traffic, depending who you ask, and a browser share in the what 65% range), Google can implement any new protocol it wants, and everyone else needs to support it or be left out.
Arguably, the IETF is no longer the controlling organization here: Google is. Should the IETF not approve Google's proposals, Google will continue to use them, and everyone else will continue to need to support them.
As the parent notes, Google both essentially determines these standards, and has an interested in faster networks so they can shove fatter payloads down the pipe. This is in part due to the ability to implement pervasive tracking, and of course, they operate a lot of content distribution products like YouTube.
Note that every method here that makes it harder for governments to censor and ISPs to prioritize also makes it harder for people to detect, inspect, and filter out Google's pervasive surveillance.