|The Job's Not Done Until Edge Don't Run|
|Written by Mike James|
|Wednesday, 19 December 2018|
In a recent news item we speculated on why Microsoft gave up on its own rendering engine and decided to adopt Chromium. Now we might have another clue as to why it happened.
At first the idea that Microsoft would give up developing its own HTML rendering engine sounds shocking, but after you think about it a while it starts to seem a logical step. Browsers, as far as HTML goes, are standardized and there isn't much scope for getting an edge in the market (pun intended) - or is there?
A comment posted to Hacker News by Joshua Bakita, a recent Edge team intern, made for interesting reading. It isn't clear how true all of this is, but it sounds feasible. In response to a comment suggesting that Google might build in proprietary features which might give it the advantage, Bakita claimed that this had already happened, but not in the browser, in Google's web sites and apps.
"... I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up.
"For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.
Now while I'm not sure I'm convinced that YouTube was changed intentionally to slow Edge, many of my co-workers are quite convinced - and they're the ones who looked into it personally. To add to this all, when we asked, YouTube turned down our request to remove the hidden empty div and did not elaborate further.
And this is only one case."
Of course, this is difficult to prove and is just one of the attractions of this method of attack- was it intentional or just one of those things? If it keeps happening, and you can't get anyone to fix it, then I guess you have to assume enemy action.
What is amusing is that, if true, this couldn't be happening to a nicer entity. If you have a long enough memory, you might remember the alleged Windows dev team motto:
It ain't done until Lotus doesn't run
alluding to the need to include undocumented twists in the Windows API that would cause Lotus 1-2-3 to crash and make Excel look good.
There are other issues. Could such dirty tricks be targeted at Firefox? If so, Mozilla could do worse that adopt Microsoft's defence and adopt Chromium as its HTML rendering engine. Once you get over the shock of the idea of everyone concentrating on a single standards-compliant HTML rendering engine, you can see the advantages. The only significant disadvantage is that if Chromium gets it wrong then all of the browsers that use it get it wrong too and this includes any vulnerabilities.
Finally does using Chromium defend against dirty tricks via Chromium?
It seems to. At least, I can't think of any way quirks in an open source project could be used against another browser. Of course, this doesn't mean that Google couldn't tweak the code that it uses in Chrome to be slightly different, but if it did and other browsers using Chromium didn't work on one of its websites, then that would be a smoking gun.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Wednesday, 19 December 2018 )|