Mobile Safari uses a closed-source fork of WebKit which implements certain features that Apple certainly considers "proprietary" (as in, they are unwilling to even submit them to the W3C for standardization, much less disclose how they implement them). See the transcript from a CSS working group meeting at http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html and search for comments from "smfr", who's the Apple representative.
Look, all specs can always be ignored by an implementation. The only things preventing that are actual legislation to the contrary, public embarrasment, and desire for interoperability.
The third of these is not an issue here. Making DNT default undermines the second (because it becomes easier for advertisers to justify ignoring it in the court of public opinion). So unless there's motion on the first option (legislation), making DNT default just reduces its usefulness.
Citation please? It wasn't last I checked, precisely because of issues like the ones I describe.
> if such transparent proxies are the issue the > appropriate response isn't to cover up the > problem.
What is the appropriate response? To ship software that doesn't actually work right when the user tries to use it?
> as a transparent proxy should simply only forward > the request to the server or serve from the cache.
That's the theory. In practice, many such proxies are buggy. The rest if your comment is all about how a proxy is supposed to work. I know all that. My point was that many do NOT work like that. They do all sorts of internal request coalescing and reordering logic that works OK when the client is not using pipelining but makes the proxy behave in totally bogus ways when pipelining is present.
Here's a simple example: some proxies use a threadpool and every time they get a request they hand it off to some thread to service; that thread does a request on to the destination server and when the response comes back hands the data back down the socket the original request came in on.
With no pipelining, this setup is fine. With pipelining, the proxy gets a bunch of requests in a row on a single socket, and hands them out to different threads. These threads then run in parallel and start handing back data in parallel, all on the same socket. It's not what a proxy is _supposed_ to do with a pipelined connection, but it's what some proxies _do_. Theory and reality just don't always agree...
That's the theory. The practice is that the web is full of transparent proxies that fall down when you try to pipeline through them (e.g. returning responses partially on the on the wrong socket in the setup you describe above, the last time I dealt with debugging a bug that was only reproducible with pipelining enabled in the browser).
Which is why pipelining remains off in Chrome and Firefox today: turning it on breaks too many sites for too many users....
The blanket prohibition went away, but was replaced with a restriction that the interpreter not interpret anything it gets over the network.
Which means that a browser's JS engine is still not ok under the new policy, unless it limits itself to only running JS that came bundled with the browser.
If it were just "works best", that would be one thing, but the new trend is a real throwback to the days of "we just won't let you in if you're not using the one browser we approve of"
> Because the most-used browser is only just over > half of the users
True on desktop. Not so much on mobile. And oddly enough sites that do UA sniffing and serve different content to "mobile" browsers have all sorts of WebKit-only stuff going on.
But even on desktop, people seem pretty happy to have it look broken in whatever browser they don't happen to be using.
And we're not talking just small sites. Google has had several instances recently where updates to things like Gmail got rolled out that were apparently not tested in any non-Chrome browsers or something, since they only worked in Chrome. At least Google considers that sort of thing a bug and fixes it quickly....
1) The Android browser is not Chrome (different UA string, different JS engine, different WebKit version, etc).
2) Total smartphone internet usage is much much smaller than desktop usage, so numbers that measure usage as opposed to installs are still pretty desktop-dominated.
> but there is a big giant excluded middle between > "preventing" and "encouraging"
Sure. I've encountered Google evangelists "encouraging" as well. No links, sadly: this was in-person conversation.
> Please provide evidence that other UA's require > capability sniffing for branded demos
I've seen demos that were using UA sniffing taken down by other UA vendors before. It's hard to provide evidence that something has been removed, obviously...
> if there were strong demand for them, Open > Source developers would have already > implemented it.
Oh, it's implemented. It just can't be legally shipped.
> I would thank if you provided links.
I said "heard". As in, people talking, with their mouths. So no links, sadly, sorry.
> and it seems that PNaCl is well within the reach of > Google and LLVM
Maybe. Maybe not. Depends on how you define "within reach". And in particular, there is a good chance that by the time it's portable enough it'll be no faster than JavaScript in most cases.
> This will showcase the superiority of Chrome
Assuming you accept the proposition that Chrome is superior, of course.
> Microsoft wants to lock WIndows 8 to MSIE, which > could be a disaster.
Sure. Just like Apple locking iPhone to Mobile Safari could be a disaster. But the latter hasn't happened yet, and the former is not necessarily going to happen.
Furthermore, having Windows 8 limited to "MSIE or Chrome" is just as much of a disaster as having it be just "MSIE", in my opinion.
And for what it's worth, for a lot my browsing on Windows (which is somewhat limited; I don't usually use Windows) IE9 is a much better browser than Chrome. So while I agree that old IE versions need to die, that has no bearing on Windows 8, which won't be running those old IE versions.
Google could pretty easily prevent this for its "chrome experiments" via a simple policy of requiring capability sniffing, not UA sniffing for them, the way other UAs do for branded demos. But they sure aren't doing that.
> AFAIK, chromium has an excellent user experience.
As long as you don't want the PDF viewer, or Flash, or the H.264 video, or the MP3 audio, or a few other goodies.
> But NaCl is under a BSD-like license.
I have heard people from Opera and Microsoft explicitly express concerns about the licensing of NaCl; whether it was copyright or patent issues I can't tell you.
> And Google is busy developing Portable NaCl
If they ever manage that (which is somewhat doubtful), we can revisit the situation. In the meantime, PNaCl is vaporware, and Google is pushing hard to get people to use NaCl.
> but I ask you to agree that it is not as evil as > Microsoft
See, that's the funny thing. It's not as evil as Microsoft in 2000. It's just about as evil (in the browser space) as Microsoft today. More evil in some ways, less in others. Apple is more evil than both of them, of course.;)
So no, I don't agree that MSIE needs to die in general. IE8 and earlier sure do, though.
> Unchecking two checkboxes is not jumping through > hoops.
Last I installed Skype, you had to select the "Custom Install" option to even get to the part of the install process that had the checkboxes. If you did the default install, Chrome just got installed silently without ever asking you.
> Anyway, I still hope Chrome to eclipse MSIE; it is > open-source
Except it's not. Large parts of it are open-source, but some pieces relevant to actually providing a good user experience are not.
And even the open-source parts are not under a license that allows, say, Microsoft or Opera to use the code.
And of course "open source" doesn't even mean the code is reusable: for example the Pepper implementation is open source, but very tightly coupled to Chrome's internals in ways that make it pretty much impossible for someone else to reuse.
Furthermore, Chrome is busy trying to push features like NaCl which would tie the web to particular hardware architectures if they actually gained traction. So Chrome dominance would be terrible for the evolution of the web, just like MSIE's dominance was terrible.
The best outcome here would be a 3-way or 4-way or 5-way (or more!) split in the market with approximately equal market share so that web developers actually code to standards instead of to particular browsers...
None of what you said is inconsistent with Apple making decisions that are in Apple's best interest.
It's just that they have a slightly longer-term view of these things than most of their competitors, and thus are more willing to trade off money for customer loyalty as needed.
That doesn't mean that the developer community is always fine with Apple (and in fact there are many cases of Apple developers being completely screwed by Apple when Apple decided that was in its interests, if you care to look). It also doesn't mean that its customers are as well off as they could be. They're just better off than they are with someone like Dell. And I say this as an Apple laptop user for a number of years now. Is it better than the other laptop options for me? Sure; that's why I'm using it. Do I want to be an iOS user? Not particularly, having tried it.
I'm sorry that the people who were closely involved in this can't discuss the issue in public. I guess you'll just have to go with your preconceptions...
Works fine in Firefox, say, if I spoof the UA as Chrome. Refuses to work otherwise, and not because Firefox doesn't implement WebGL or something. Just because it's sniffing specifically for Chrome. And again, Google encourages that.
And one more note. Even if one were to get special treatment, Apple can take that away any time it feels like it (and has done so in the past, for apps that did get special treatment in some way for a while). So it's not exactly something one can depend on.
Slashdot Mirror
Mobile Safari uses a closed-source fork of WebKit which implements certain features that Apple certainly considers "proprietary" (as in, they are unwilling to even submit them to the W3C for standardization, much less disclose how they implement them). See the transcript from a CSS working group meeting at http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html and search for comments from "smfr", who's the Apple representative.
But yes, nothing "proprietary" about iOS.
Look, all specs can always be ignored by an implementation. The only things preventing that are actual legislation to the contrary, public embarrasment, and desire for interoperability.
The third of these is not an issue here. Making DNT default undermines the second (because it becomes easier for advertisers to justify ignoring it in the court of public opinion). So unless there's motion on the first option (legislation), making DNT default just reduces its usefulness.
> It's enabled by default in IE.
Citation please? It wasn't last I checked, precisely because of issues like the ones I describe.
> if such transparent proxies are the issue the
> appropriate response isn't to cover up the
> problem.
What is the appropriate response? To ship software that doesn't actually work right when the user tries to use it?
> as a transparent proxy should simply only forward
> the request to the server or serve from the cache.
That's the theory. In practice, many such proxies are buggy. The rest if your comment is all about how a proxy is supposed to work. I know all that. My point was that many do NOT work like that. They do all sorts of internal request coalescing and reordering logic that works OK when the client is not using pipelining but makes the proxy behave in totally bogus ways when pipelining is present.
Here's a simple example: some proxies use a threadpool and every time they get a request they hand it off to some thread to service; that thread does a request on to the destination server and when the response comes back hands the data back down the socket the original request came in on.
With no pipelining, this setup is fine. With pipelining, the proxy gets a bunch of requests in a row on a single socket, and hands them out to different threads. These threads then run in parallel and start handing back data in parallel, all on the same socket. It's not what a proxy is _supposed_ to do with a pipelined connection, but it's what some proxies _do_. Theory and reality just don't always agree...
That's the theory. The practice is that the web is full of transparent proxies that fall down when you try to pipeline through them (e.g. returning responses partially on the on the wrong socket in the setup you describe above, the last time I dealt with debugging a bug that was only reproducible with pipelining enabled in the browser).
Which is why pipelining remains off in Chrome and Firefox today: turning it on breaks too many sites for too many users....
Actually, Mozilla stopped using NanoJIT with Firefox 9 when they dropped their tracing JIT.
The blanket prohibition went away, but was replaced with a restriction that the interpreter not interpret anything it gets over the network.
Which means that a browser's JS engine is still not ok under the new policy, unless it limits itself to only running JS that came bundled with the browser.
Sure. You can install the Chrome beta. But the point is that it's not installed by default, install numbers are low, and ICS deployment is _also_ low.
All of which is to say that Chrome on Android is not a significant part of Chrome market share.
> Long time since I've seen that
Take a look at http://getcrackin.angrybirds.com/
If it were just "works best", that would be one thing, but the new trend is a real throwback to the days of "we just won't let you in if you're not using the one browser we approve of"
> Because the most-used browser is only just over
> half of the users
True on desktop. Not so much on mobile. And oddly enough sites that do UA sniffing and serve different content to "mobile" browsers have all sorts of WebKit-only stuff going on.
But even on desktop, people seem pretty happy to have it look broken in whatever browser they don't happen to be using.
And we're not talking just small sites. Google has had several instances recently where updates to things like Gmail got rolled out that were apparently not tested in any non-Chrome browsers or something, since they only worked in Chrome. At least Google considers that sort of thing a bug and fixes it quickly....
I'm not asking you to believe anything. I'm providing you with information. You can choose what you want to do with it.
You can also choose to think that Google can do no evil, if you want. Nothing wrong with hope and all that.
The problem is that we're rapidly moving back to the "works best" bullshit, but now with "Chrome" or "WebKit" in place of "IE"...
1) The Android browser is not Chrome (different UA string, different JS engine, different WebKit version, etc).
2) Total smartphone internet usage is much much smaller than desktop usage, so numbers that measure usage as opposed to installs are still pretty desktop-dominated.
> but there is a big giant excluded middle between
> "preventing" and "encouraging"
Sure. I've encountered Google evangelists "encouraging" as well. No links, sadly: this was in-person conversation.
> Please provide evidence that other UA's require
> capability sniffing for branded demos
I've seen demos that were using UA sniffing taken down by other UA vendors before. It's hard to provide evidence that something has been removed, obviously...
> if there were strong demand for them, Open
> Source developers would have already
> implemented it.
Oh, it's implemented. It just can't be legally shipped.
> I would thank if you provided links.
I said "heard". As in, people talking, with their mouths. So no links, sadly, sorry.
> and it seems that PNaCl is well within the reach of
> Google and LLVM
Maybe. Maybe not. Depends on how you define "within reach". And in particular, there is a good chance that by the time it's portable enough it'll be no faster than JavaScript in most cases.
> This will showcase the superiority of Chrome
Assuming you accept the proposition that Chrome is superior, of course.
> Microsoft wants to lock WIndows 8 to MSIE, which
> could be a disaster.
Sure. Just like Apple locking iPhone to Mobile Safari could be a disaster. But the latter hasn't happened yet, and the former is not necessarily going to happen.
Furthermore, having Windows 8 limited to "MSIE or Chrome" is just as much of a disaster as having it be just "MSIE", in my opinion.
And for what it's worth, for a lot my browsing on Windows (which is somewhat limited; I don't usually use Windows) IE9 is a much better browser than Chrome. So while I agree that old IE versions need to die, that has no bearing on Windows 8, which won't be running those old IE versions.
http://grouek.com/ctrlpaper/ is a good example.
Google could pretty easily prevent this for its "chrome experiments" via a simple policy of requiring capability sniffing, not UA sniffing for them, the way other UAs do for branded demos. But they sure aren't doing that.
> AFAIK, chromium has an excellent user experience.
As long as you don't want the PDF viewer, or Flash, or the H.264 video, or the MP3 audio, or a few other goodies.
> But NaCl is under a BSD-like license.
I have heard people from Opera and Microsoft explicitly express concerns about the licensing of NaCl; whether it was copyright or patent issues I can't tell you.
> And Google is busy developing Portable NaCl
If they ever manage that (which is somewhat doubtful), we can revisit the situation. In the meantime, PNaCl is vaporware, and Google is pushing hard to get people to use NaCl.
> but I ask you to agree that it is not as evil as
> Microsoft
See, that's the funny thing. It's not as evil as Microsoft in 2000. It's just about as evil (in the browser space) as Microsoft today. More evil in some ways, less in others. Apple is more evil than both of them, of course. ;)
So no, I don't agree that MSIE needs to die in general. IE8 and earlier sure do, though.
If you really care I can find you examples of Google encouraging truly Chrome-only pages (as in, sniff for "Chrome" in the UA).
But in any case, how is encouraging WebKit-only things any better than encouraging Chrome-only ones?
> Unchecking two checkboxes is not jumping through
> hoops.
Last I installed Skype, you had to select the "Custom Install" option to even get to the part of the install process that had the checkboxes. If you did the default install, Chrome just got installed silently without ever asking you.
> Anyway, I still hope Chrome to eclipse MSIE; it is
> open-source
Except it's not. Large parts of it are open-source, but some pieces relevant to actually providing a good user experience are not.
And even the open-source parts are not under a license that allows, say, Microsoft or Opera to use the code.
And of course "open source" doesn't even mean the code is reusable: for example the Pepper implementation is open source, but very tightly coupled to Chrome's internals in ways that make it pretty much impossible for someone else to reuse.
Furthermore, Chrome is busy trying to push features like NaCl which would tie the web to particular hardware architectures if they actually gained traction. So Chrome dominance would be terrible for the evolution of the web, just like MSIE's dominance was terrible.
The best outcome here would be a 3-way or 4-way or 5-way (or more!) split in the market with approximately equal market share so that web developers actually code to standards instead of to particular browsers...
> But did Google *pay* for Angry Birds to do that?
I have no idea what their contract, if any, with Angry Birds looked like.
But they have certainly been encouraging web developers to do just that, yes.
> And what is your source for that Skype behaviour?
Personal experience, for one thing. You can see a screenshot from the advanced install at http://people.mozilla.org/~khuey/skype-install-2011-10-3.png if you want.
As far as a Google search not finding anything.... https://www.google.com/search?q=skype+chrome+bundling shows http://www.webmasterworld.com/goog/4135280.htm and http://www.winrumors.com/skype-for-windows-updated-to-remove-google-product-bundling/ and http://mynetx.net/6494/skype-removes-google-integration
It also finds, not coincidentally, http://www.osnews.com/comments/25184 (do read the first response too!) and http://www.salsitasoft.com/2011/09/23/wonder-how-chrome-is-growing-market-share-ask-adobe/
A similar search on Bing also finds http://www.quora.com/Just-got-a-Skype-update-and-they-wanted-me-to-install-Chrome-Why
None of what you said is inconsistent with Apple making decisions that are in Apple's best interest.
It's just that they have a slightly longer-term view of these things than most of their competitors, and thus are more willing to trade off money for customer loyalty as needed.
That doesn't mean that the developer community is always fine with Apple (and in fact there are many cases of Apple developers being completely screwed by Apple when Apple decided that was in its interests, if you care to look). It also doesn't mean that its customers are as well off as they could be. They're just better off than they are with someone like Dell. And I say this as an Apple laptop user for a number of years now. Is it better than the other laptop options for me? Sure; that's why I'm using it. Do I want to be an iOS user? Not particularly, having tried it.
I'm sorry that the people who were closely involved in this can't discuss the issue in public. I guess you'll just have to go with your preconceptions...
What does it make it, for you? WebKit-only?
Note that it sniffs for WebKit and if it doesn't find it tells the user to go download Chrome.
You can depend on Apple to be careful about protecting the interests of their platform and on average making choices that benefit Apple.
Whether those choices are "very good" depends on whether you're Apple.
Another example: http://grouek.com/ctrlpaper/
Works fine in Firefox, say, if I spoof the UA as Chrome. Refuses to work otherwise, and not because Firefox doesn't implement WebGL or something. Just because it's sniffing specifically for Chrome. And again, Google encourages that.
And one more note. Even if one were to get special treatment, Apple can take that away any time it feels like it (and has done so in the past, for apps that did get special treatment in some way for a while). So it's not exactly something one can depend on.
> Why would it need special exemptions?
No idea; I just know they needed to be able to roll out security updates quickly and Apple wouldn't let them.
> Of course they have given all sorts of apps special
> treatment.
I was specifically talking about security update rollout.