Google says they will eventually submit this to IETF and produce a reference implementation, but it is interesting how a company was able to quietly move a large user base from open protocols to a proprietary protocol.
50% of all communication between Chrome and Google sites is now through a path that is not standardized, nor on track to standardization, and is just special to the combination of Google's browser plus Google's sites. That sets off warning lights for some people, and for good reason.
I totally get that to experiment with a new protocol, you need real-world data. Definitely. So if say 1% or 5% of that communication were non-standard, I really wouldn't have much of an issue. But when the "experimentation" is 50%, it's on the verge of being the normal path; it doesn't seem like experimentation. Perhaps they could continue the experiment and go from 50% to 60% or 80% - there isn't much a difference at that point. In fact, if the new protocol is better, it would be almost irrational not to - if 50% is considered ok ethically, and moving to 60% saves costs, then why wouldn't you?
I'm not saying that there is something wrong here. It's not even seriously worrying, given Google's positive track record on SPDY. Still, it's very close to the edge of being worrying. That worry of course is that they expand beyond 50%, and are slow to standardize or never do so - in which case things would clearly be wrong. Again, Google has a good reputation here, given SPDY. Still, I'm surprised Google feels ok to move half of all communication to a non-standard protocol, apparently unconcerned about that worrying anyone.
Right now, 50% of Chrome users (the #1 browser), on Google websites (some of the #1 websites), are in that state.
This is only Google sites visited by Chrome. It's not like you can't visit these Google sites with normal HTTP with other browsers, nor does Chrome use QUIC on the rest of the web. If they walled themselves in then I could see a cause for concern but right now, even 50% of the traffic between Google sites and Chrome is still nowhere near the majority of internet traffic in any sense.
Because the web is open and massive is precisely the reason why changes like these will not happen overnight but potentially take decades. The amount of old legacy stuff on the web including protocols, implementations, security holes, ipv4, etc that seem like they'll never get upgraded is far more worrying to me.
The logic behind it is benevolent and reasonable, but the short-term effect is that Chrome users get an incentive to use GWS/Gmail/Drive rather than Yahoo/Dropbox, and GWS/GMail/Yahoo users get an incentive to use Chrome rather than Firefox/Safari/IE.
If Chrome intentionally started rendering Yahoo slower, that would be blatantly anti-competitive. This is, in effect, just about the same thing, only with practical reasons behind it (much like their were practical reasons behind integrating IE into Windows).
This seems to be a poor analogy.
One of the main draws of capitalism is to encourage companies to compete by offering quality products. One of the main drawbacks is that companies are also able to compete by sabotaging the ability of other companies to offer quality products.
The second is the reason for anti-competitive laws. Sabotaging Yahoo falls into this category. Offering a better product that what's already on the market - especially without impeding the quality of the old product - falls squarely into the first.
> it is interesting how a company was able to quietly move a large user base from open protocols to a proprietary protocol.
Some of us may believe Google is doing so for good reasons, some of us might not be sure - but that is all beside the point.
The point is that this is a massive show of power. And it has been applied quietly - no one (outside of Google) knew about this massive change in activity until this blogpost.
In any hands, that amount of power should be worrying.
I don't think this is a cause for concern but rather a victory for progress and efficiency that a company can finally do such large scale testing and experimentation to move us all to a better standard.
No one else has a web browser with market share anywhere near.
And no other browser vendor has any major websites. Microsoft has Bing and MSN etc. sites, but those are fairly small compared to google.com, google docs, google maps, etc. etc.
Facebook would be a company with a website that has massive reach. But Facebook doesn't control a browser. If it did have a major browser, it would be as concerning as Google is.
It's the combination of major browser + major websites that allowed Google to divert a massive part of internet usage from a standard protocol to a non-standard one. No one else can do that today.
Only if you weren't paying attention. They've been discussing testing it on Google's servers like they did SPDY for a long time now. The first announcement I can find that they were switching some Google traffic over to it was almost two years ago[1], and if you're on blink-dev or chromium-dev (or proto-quic, if you're serious about it) you'd have gotten periodic updates on the topic. Youtube videos about it[2] (with discussion on HN[3]), etc etc.
[1] https://groups.google.com/a/chromium.org/forum/#!topic/chrom...
The distinction between open-source-but-proprietary and open-standard is important for many reasons. One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility with a giant pile of C++.
I think there is a distinction to be made between closed spec protocols and protocols developed prior to being submitting for standardization; while its hard to tell them apart prior to the latter actually being submitted for standardization outside of potentially misleading forward-looking statements of intent, the latter is a reasonable way of cleaning up something and getting some solid real-world feedback and proving utility before submitting something as the basis for standards work while the former carries the problem you describe.
By your definition Mozilla's (your employer's) asm.js and Rust are also proprietary.
Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards.
There have been plenty of research and work even in standard bodies like IETF that try to implement a better tcp/ip-like protocol.
They all went nowhere because at this point in time, you can't just have some guys in a room to design a new transmission protocol and have it taken seriously by anyone that matters (Google/Apple/Microsoft/Mozilla).
Google is following the only realistic route: implement something, test it in a scale large enough to conclusively show an improvement and then standardize it.
This is exactly how HTTP/2 happened.
We should be cheering them on instead of spreading FUD because it doesn't live up to your impossible standard of non-proprieterness.
I think dragonwriter's sibling comment to yours is pretty apt here. It's hard to tell the difference between something that will be submitted to standards bodies any day now and something that really will be submitted to standards bodies any day now. At a certain point (with e.g. Pepper) the statute of limitations runs out and you have to assume it's just going to be an open-source but proprietary API.
Of course, whether or not overloading "proprietary" is useful is a different discussion. Mostly it seems these conversations eventually just devolve into arguments over definitions of the word for no real insight.
asm.js isn't a new protocol, and so isn't proprietary according to that definition. It's a subset of JavaScript (to be specific, ES6, including such extensions such as Math.imul). You can implement asm.js by simply implementing the open, multi-vendor ES6 standard. In fact, that's exactly what some projects, like JavaScriptCore, are doing.
Rust isn't relevant, as it's not intended to be added to the Web. Adding <script type="text/rust"> to the browser would be a terrible idea for numerous reasons. Nobody has proposed it.
"Proprietary" as used here isn't limited to the Web.
I do think there is a big difference between "a subset of JavaScript" and "a bunch of JavaScript APIs" from a standardization point of view. All engines have been implementing special optimizations for JavaScript subsets ever since the JS performance wars started. Nobody thinks we need to standardize polymorphic inline caches, for example, even though the set of JS code that is PIC-friendly is different from the set of JS code that is heavily polymorphic (and this distinction would be easy to describe formally if anyone cared to). asm.js is just an optimization writ large: the reason why it's not a protocol is that any conforming JavaScript implementation is also an asm.js implementation.
I think people are reading a lot more into my posts than was intended. I'm not calling out QUIC specifically, since I'm not involved with the details of its standardization anyway. The point is simply that open source doesn't automatically mean non-proprietary.
Things like the "Championed" proposals model for TC39 and (as DannyBee notes) IETF's approach to standardization are direct acknowledgements of this. In a way the Extensible Web approach is also a direct acknowledgment, insofar as it says that innovation happens at the edges, so browsers should provide minimum flexible building blocks and get out of the way. asm.js is a great example of using those building blocks (though it should be noted that as asm.js catches on, other browsers are forced to spend time on it, explicit directive prologue handling or no). Network protocols, on the other hand, are something that can't be built and tested from the tools browsers provide.
I think the better question for you would be, what's the better way to develop network protocols like this, then? Assuming that purpose, I can't think of anything to criticize here except maybe they should have limited testing to beta and dev users of Chrome. However, that limits your test data and normally that sort of thing is done to make sure web compatibility isn't broken in the future by changing standards, and given that browsers already negotiate protocols, I don't see an imminent danger there.
As I mentioned in my reply to tptacek, I'm not intending to call out QUIC specifically here; the point is simply that open source and open standards are not equivalent. Shipping implementations is fine as long as there are effective safeguards to prevent lock-in.
What we have to make sure we avoid is something like the -webkit CSS prefix situation, where the fact that WebKit was open source did nothing to prevent the mobile Web from very nearly coming to depend on all the quirks of a big pile of C++. (That situation is also an example of standardization leading to better outcomes—remember how bad the WebKit-specific "-webkit-gradient(linear, color-stop(foo), ...)" syntax was?)
I love Mozilla, but this seems like an apt description of "JavaScript." (sure, they're not so much bugs as misfeatures, but..)
By the definitions of proprietary floated here, every open protocol standardized as IETF proposal started out as proprietary.
The only thing that wouldn't seems to be "stuff designed in the open by committee". A process that has worked so well, it brought us things like C++ and POSIX.
I fully agree, but it has to be counterbalanced with not shipping random single-vendor features to the entire Web. The proven model here, which is a policy shared by both Blink and Gecko, is developer and beta channels and feature flags.
> The only thing that wouldn't seems to be "stuff designed in the open by committee". A process that has worked so well, it brought us things like C++ and POSIX.
It also brought us things like CSS 2.1 (which everyone loves to hate, but it's much better than the nightmare of pre-CSS layout) and ES6 (which is extremely well-designed). Even the standard versions of C++ aren't really badly designed, especially if you limit yourself to C++{11,14}: there were a few notable standardization blunders, like the STL allocator API, but by and large it's hard to find things in C++11 and C++14 that were clearly mistakes at the time.
CORBA and XHTML 2.0 would be better examples, but the failure modes there were being unimplementable and impracticality of dropping backwards compatibility respectively, both of which the developer channel/feature flag approach address.
Is it unrelated, or is your argument that if they do it this way, it's somehow now "open" and not "proprietary"? Because if so, i struggle to see why that would be the case :)
"Even the standard versions of C++ aren't really badly designed, especially if you limit yourself to C++{11,14}: there were a few notable standardization blunders, like the STL allocator API, but by and large it's hard to find things in C++11 and C++14 that were clearly mistakes at the time."
I'm just going to go with "C++ committee members i have easy access to" (IE sit 10 feet from me) disagree :)
Now, that's not to say it's a complete and utter disaster, but ...
Absolutely. If the goal is to create a open, multi-vendor implementation of some feature, then the right way to go about it is to (a) implement it behind a feature flag; (b) present it for standardization; (c) take feedback into account during the process, making changes as necessary; (d) ship it to stable and remove the flag once consensus emerges. Even better if multiple vendors do (a) at the same time, but it's not strictly necessary.
The reason why the flag in step (a) is so important is that it makes step (c) possible. Otherwise, there's a very real risk that content will come to depend on the quirks of your first implementation, making it impossible to take other parties' feedback into account. If you just ship to stable right away, you're running the risk of making the platform depend on a proprietary feature.
The reason why doing (a) before (b) is important is that it prevents unimplementable features and mistakes that only become apparent once implementation happens from being standardized. It also allows users of the feature, not just the folks who implement the platform, to take part in the process.
This process is really the only one I know of for popular multi-vendor platforms that both prevents proprietary features from being locked in and avoids the problems of design-by-committee. That's why both Blink and Gecko have adopted it (and Blink is definitely to be commended for following it).
To some extent this might be a matter of appearance. Does Google have a firm rule against shipping a proprietary protocol to over 50% - is that why you stopped there? If so, that would be reassuring to hear.
1. proprietary vs. Free / Open Source (code released under an F/OSS license), and
2. proprietary vs. Open Standards (an implementation of a standard governed by an independent standards body and freely implementable.)
QUIC is not proprietary by F/OSS on the first axis, and currently proprietary rather than based on an open standards on the second axis, with a stated intent of becoming the basis for open standards works in the future.
There is, I think, a pretty good case that this is a good way to get to new open standards that are actually useful for solving real world problems.
Very few applications are only an implementation of an open standard, but things like the QUIC implementation or other communications protocol implementations aren't applications, but lower level components.
Anyone who wants to discuss it on the mailing list and submit code.
In fact, the project has a ton of non-google non-drive-by committers (250+ IIRC, it's been a while since i looked ).
I do admit that things aren't as cut-and-dry for protocols and specifications than for actual implementations where rights and ownership are pretty clearly defined, but surely you can see that there is a distinction that can be drawn here? QUIC is expected to become an open standard (or die), but it's not there yet. Though it may be further along on the "open" than "standard" aspect.
(Some software implements a proprietary protocol.)
So this definition of proprietary does not seem particularly useful ....
Consider:
H.264 has a spec that's written down by a standards-setting organization and not a trade secret (though behind a paywall) and has multiple independent interoperable implementations. Yet, it's "proprietary" in the sense that it's patent-encumbered. I.e. the patent holder are the proprietors.
VP8, OTOH, is Royalty Free with a Free Software canonical implementation and has other implementations, too, though their independence is debatable. Yet, VP8 is called "proprietary" by some, because the design of VP8 was under a single vendor's (Google's) control and not blessed by a standards-setting organization.
I think using the word "proprietary" as the opposite of "free as in Free Software" is fine when talking about a particular implementation, but it's better to avoid the word when talking about protocols and formats.
For protocols and formats, it's more productive to talk about:
* Royalty-free vs. encumbered
* Multiple independent interoperable implementations vs. single implementation.
* A Free Software implementation exists vs. doesn't.
* Fully specified vs. defined by a reference implementation.
* (If fully specified) Non-secret spec vs. secret spec.
* (If non-secret spec) Spec available at a freely GETtable URL vs. spec behind paywall or similar.
(A number of Googly things that are royalty-free and have a Free Software implementation go to worse end of these axes on the points of having a single implementation and being defined by the quirks of that implementation.)
If the feature is actually an improvement, it should be on for everyone that's able to run the code as soon as possible. Ship fast and break nothing.
To address a different aspect of your comment, I do think it's very interesting how little attention we pay to the packets of data sent between software running on our personal devices and remote servers. Slap some TLS on it, and nobody even notices.
I think there's a fundamental OS level feature, and a highly visible UI component which is outright missing, allowing users to understand no just what programs are connecting to where, but what are they actually sending out and receiving. If it didn't have such horrendous implications and failure modes, I would love to have highly functional deep packet MitM proxy keeping tabs on exactly what my computer is doing over the network. You know, or the NSA could publish a JSON API to access their copy?