Google Shows Off “Native Client Technology” with Games on Google Chrome

Google’s aggressive strategy with Chrome has taken Chrome to a stage where it can claim a dominant browser-market share. Now, where does a company obsessed with speed and performance go from here? Google recently showed off how well Chrome can use the Native Client Technology. With this, Google Chrome will take browser wars to a new level.

The Native Client Technology in Google Chrome has been in news from the beginning of this year. While Mozilla had declared that they will not implement Native Client in their Firefox browser, Opera software had criticized Google for not following the web-standard (WebGL) and allowing game developers a free ride on their browser.

Google Native Client  (NaCl  in an allusion to  sodium chloride  or common salt) is a  sandboxing  technology for running a subset of Intel  or ARM native code using software-based fault isolation.  Currently in development, it is proposed for safely running native code from a  web browser, allowing web-based applications to run at near-native speeds.

Adobe Air provides a Native Code API, and the recently launched  Silverlight 5  also brings Native Code into the browser. Moreover, we all know about the  notoriety  of ActiveX in Internet Explorer. Although Native code has always been an area of interest across platform because of the promised robustness, it poses a risk at the same time.

The “Native Client Technology” project was started to create robust applications by allowing them to leverage native (system) processing speeds. It has been present in Google Chrome 14 dev version as a disabled feature. However, after this stunt by Google, “Native Client Technology” might be reduced to a game-enabling project, which kicks WebGL in the gut.

Visit the Native Client developer page here.

Microsoft Gets Slammed for Its Hypocritical Stance on WebGL

Last week, I reported that Microsoft won’t be supporting WebGL in Internet Explorer due to security concerns. WebGL is a cross-platform 3D graphics API for the web that enables web applications running in the browser to do all sorts of cool stuff. Currently all the major browser vendors apart from Microsoft (i.e. Mozilla, Google, Opera, and Apple) actively support the WebGL initiative. Microsoft gave a pretty detailed technical explanation of their issues with WebGL, which led me to remark that Microsoft might be doing the right thing for a change. However, I might have been too hasty in giving the software giant, which has built a reputation of not willing to play nice, the clean chit.

One of the things I have long criticized tech-giants like Microsoft and Apple for is hypocrisy. As it turns out, the latest WebGL vs. Microsoft incident is another glowing example of the same. The biggest problem with Microsoft’s criticism of WebGL was first highlighted by Opera Software’s HÃ¥vard K. Moen and later elaborated upon by Google’s Gregg Tavares.

Microsoft: Criticizes something WebGL is doing. Does the exact same thing with Silverlight. Sigh.less than a minute ago via web Favorite Retweet Reply

It appears that Microsoft’s security consciousness magically vanishes as soon as it moves away from WebGL, with which it has clear conflicts of interests. WebGL is based on OpenGL, which is the main competitor of Microsoft’s DirectX. Adobe’s Flash and Microsoft’s own Silverlight suffers from many of the same drawbacks highlighted by Microsoft. However, Microsoft has no qualms about allowing these plug-ins to work on Internet Explorer. Tavares, who has been working on Chrome’s GPU acceleration and WebGL features, is understandably furious.

The latest FUD is Microsoft’s claim that they won’t support WebGL because it’s insecure. They might have a little more credibility if they weren’t promoting a technology, Silverlight 5, that provides the EXACT SAME FEATURES with all the same issues. They can’t have it both ways. Either it’s possible to make this tech safe or else it’s not. If it is possible to make it safe in Silverlight 5 then it’s also just as possible in WebGL. If it’s not possible to make it safe Microsoft would have to come out and say (1) They are removing GPU access from Silverlight 5. (2) They are banning Unity3D from running in IE since it also provides access to the EXACT SAME FEATURES. (3) They are banning Flash 11 from running in IE since it also provides access to the EXACT SAME FEATURES.

He also alleges that the research done by ContextIS into the security vulnerabilities present in WebGL was sponsored by Microsoft. If that is true, then this won’t be the first time that Microsoft has done something like this. However, at the very least, the results presented by ContextIS aren’t manipulated like the ones by NSS labs.

Tavares also tackled the main objections raised by Microsoft. One of the objections was related to denial of service, wherein a malicious process can prevent other processes from accessing the services of the GPU by asking the GPU to process something that takes too long.

The simplest solution is to time how long the GPU is taking to execute each task. If it’s taking too long reset the GPU and kill the page that issued the command. Microsoft Windows is one of the only OSes that currently provides this solution. They should be proud of this. They can basically claim the best place to run WebGL is on Windows. The Khronos group is working to bring similar functionality to other OSes as fast as possible and it may already be available in some drivers.
Of course it’s completely unacceptable if your machine gets DOSed. My only point is (1) there are fixes, Windows already support them and they are coming soon to other OSes. (2) it’s not has (sic) bad as your machine getting owned. In fact most likely very soon now, if a page takes too long on the GPU it will be marked bad by the browser. If you try to visit it again you’ll be warned. Similarly using techniques like Safe Browsingwe can warn you in advance while we work on providing the real fixes in all OSes.

The other point raised by Microsoft was that WebGL provides low-level hardware access in a way that is overly permissive. Bugs present in the graphics driver can create serious security issues. Tavares suggests that sandboxing coupled with a multi-process architecture can go a long way towards solving these issues. Google currently parallelizes all WebGL calls. Before anything is passed to the GPU, Chrome performs strict validation and even tries to work around several known GPU driver bugs.

Undoubtedly, the current status of WebGL is far from ideal. However, it’s still a work in progress, and the Khronos group is still busy tying up all the loose ends. One thing that is for certain is that WebGL is essential for cross-platform, cutting-edge, next-gen web applications that will blur the line between native and web applications.

Microsoft Disses WebGL, Calls It Harmful

WebGLWebGL is a cross-platform 3D graphics API for the web that is being adopted by the likes of Chrome, Firefox, Safari, and Opera in order to usher in next-gen graphics intensive web applications. However, one major browser vendor has decided to distance itself from the pack, and has announced that it won’t be supporting WebGL. No points for guessing who that browser vendor is. It is none other than Microsoft.

Microsoft has a terrible track record when it comes to adopting new standards. They have been trying to turn a new leaf, but there have been several missteps along the way. They also happen to be the folks behind DirectX, the main competitor of OpenGL, which forms the basis for WebGL. So, its not all that surprising that Microsoft has decided to diss WebGL. However, before the knives come out, Microsoft might actually be right for a change.

Microsoft’s objection is based on the fact that WebGL, in spite of claims to the contrary by the Khronos Group, isn’t really secure. Microsoft explained the technicalities behind its objections in a fair amount of detail in its TechNet blog post. The three main points raised by Microsoft are:

  1. WebGL provides low-level hardware access in a way that is overly permissive.
  2. Even security procedures put in place can be circumvented due to the presence of vulnerabilities in the graphics driver. The onus for ensuring security will fall on the driver manufacturers and not on the browser or operating system vendor. Users rarely update their hardware drivers; and even the manufactures themselves aren’t accustomed to releasing frequent and quick security updates.
  3. Modern operating systems and graphics infrastructure were never designed to fully defend against attacker-supplied shaders and geometry. It might become possible for hackers to crash and reboot systems at will by supplying malformed data.

Microsoft believes that WebGL will likely become an ongoing source of hard-to-fix vulnerabilities, and this is a concern that has been raised before by third parties. WebGL is an exciting piece of technology. It is also something that is required to push the boundaries of what can be done within a web app. Microsoft might be playing spoil sport; however, with the current design flaws in WebGL, Microsoft’s stance also makes a lot of sense. Let’s hope that the Khronos Group will manage to find a way to assuage the concerns surrounding WebGL.