Google Native Client challenges Microsoft and Adobe RIAs
If only they can get the security to work
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Google is entering the rich-client game with a project allowing online applications to tap your desktop through the browser.
The search giant has revealed its Native Client project, intended to run native code from web-based applications on x86 Windows, Mac, and Linux. Native Client will use JavaScript in the browser.
Google has so far devised a version of Native Client for Ubuntu - the flavor of Linux that Google runs. Versions of Native Client for Windows XP and Mac OS X have been developed and tested. Native Client works with Firefox, Safari, Opera, and Google Chrome, with plans to support ARM and PowerPC.
Google has released the open-source Native Client code to take feedback from the security community, in addition to those in the broader open-source community.
The company has proposed a system of two sandboxes - called the inner and outer sandboxes - to prevent untrusted modules from the web running amok on your machine. Google has proposed a model where application calls are made using ptrace in Linux and Mac OS X. Access control lists have been proposed for Native Client on Windows.
You can read more about the proposed Native Client architecture here (warning: PDF).
Why all the security? Native Client wants code from web-based applications such as photo sharing and editing to run natively on your x86 machine. Currently, you use a combination of JavaScript in the browser with the resources of the service-providers' servers.
However, Google wants consumers do be able to do things such as modify photos hosted on photo-sharing websites using their machine's processor and memory, rather than flogging the service provider's servers and or going out over the network - both of which produce delays.
Brad Chen, with Google's Native Client Team, blogged: "With the ability to seamlessly run native code on the user's machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency."
Also, Google wants such applications to be "browser neutral". In other words, to allow application and content creators to build their applications without needing to tweak for different browsers' idiosyncrasies or different levels of support for web standards.
Many will see Google's Native Client in terms of a head-to-head with Microsoft and a challenge to the Windows desktop - and there's certainly an element of truth to that view. Native Client could potentially provide more options for Windows-application developers interested in putting their software online and freeing themselves of dependency on the desktop or being tied into Microsoft's Silverlight browser-based plug-in for video and audio.
The challenge will be in how far Microsoft is willing to work with Google on making its Windows APIs open and available to talk to the sandbox architecture. That'll be one reason why Google is reaching out to the security community: to garner feedback and assistance.
Adobe Systems' Flash and AIR, though, are the real competitors here. Adobe is working on the same goals with AIR: to let applications on the internet or intranets access the data and processing resources on your PC and present server-side information in visually slick and pleasing ways.
Also, Flash and AIR are used to present online video and photo content, while there's a potential rivalry between' Adobe's presentation technology and JavaScript. And, finally, Google doesn't like the fact that Adobe's Flash Player remains a closed-source product.®
COMMENTS
Here we go again...
Ok, so we will have the ability to run x86 apps in a browser. But then we will need APIs to make it useful. And if we want to have "browser neutral" applications, which GUI will we choose (so that users are not confronted with something entirely different for each app)?
It seems that Sun has already struggled with all these questions in the past, and succeeded somewhat. It has addressed the issues of security, cross platform GUI and provides a host of APIs all in what would appear to be a more elegant solution (processor independent, not just platform independent).
If I were Google I would help Sun with the big area that it has failed: deployment. Java can work well on the client side, but Sun have made a big mess when it comes to browser integration and compatibility. It is not that difficult, Adobe get it right with Flash (how many flash runtimes do you have on your PC?). Sun have even made some good efforts of late (Java kernel) but the response is all too confused. Sun is a company which develops good technology but can't package it properly for the intended audience. Google is a company which gets the packaging aspect just right.
We seem to see this all the time in IT circles: a technology matures to a point where it is just about usable and then someone throws their hands in the air and starts again in an opposite direction only to end up at the same point 5 years later.
Think how XML-RPC was first portrayed as being a much simpler solution compared to the "overly complex" CORBA. After it became SOAP and then web services and we added all the required WS extensions (security, asynchronous transactions, messaging, etc.) I would argue that it is no less complex than CORBA was. And we lost over 5 years in the process.
Sometimes we would be better of fixing existing technologies which are "almost there" rather than blindly starting again...
Dominic.
Security Nightmare
Now when the inevitable security flaw rears its ugly head it will be able to directly run native code. Sigh. Will we never learn? Okay Google, repeat after me, separation of privileges is a GOOD thing!
Ah well, I suppose us firefox folks can whip up a NoCode or CodeBlock Plus.
Besides, how silly it is to wrap a native client inside a browser instead of just distributing the client directly?
Mine's the one right next to the one with the pocket full of holes!
Javascript is the future ? I hope not ...
Javascript sucks. Maybe Google can force it to be better? I've been working on a Java back-end and Flex front-end project for a while. It's much much better because you don't really need to worry about the interference between the HTML and JavaScript. Not to mention that you have to deal with the "name space" issue with that if it's in a portlet type of environment...
Adobe Flex / ActionScript is a much better environment to work with. Also, it will only be getting better with more integration with the Flash. In addition, Adobe is doing the right thing to work with SpringSource to utilize the open source power further more and I can see a bright future because I like everything has been done by the SpringFramework team so much. It makes my J2EE life much easier. (That and the Eclipse & Maven and all the Java Open Source communities.)
Here is that exciting news,
http://www.internetnews.com/webcontent/article.php/3789821/Adobe+SpringSource+Team+For+Enterprise+RIAs.htm
To me, it's a much better news from Enterprise developer's point of view.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
