Google defends native code Chrome play Google has defended its decision to run native code inside its Chrome browser, while calling its Native Client plug-in a "very important part" of the company's Chrome OS strategy. In unveiling its Cr-48 beta Chrome OS machine on Tuesday in San Francisco, Google did not mention Native Client. But when we asked what role the …
I think what is being missed here... the missing piece... that perhaps Google is keeping closely to its chest for now... is Google Chrome Frame.
Chrome Frame currently allows IE to run NaCl code by embedding Chrome within IE. You still have the IE interface, but the rendering engine becomes Chrome when it's needed.
This code, though only an add-on for IE currently, looks to have been tested with Firefox. So, as soon as it's ready for primetime, if Firefox doesn't cave in, Google will likely just release Chrome Frame for Firefox and any other browser that supports such add-ons.
Sure, there will always be browsers like that on the iPad, but people have already come to expect a lesser experience on the iPad since you can't add features to the browser and can't view Flash, etc...
Active X was simply a way of loading a DLL into a browser over the net and run at the full privileges of the browser instance. The only "security" was digital signatures which would whitelist the DLL originators. In reality, miscreants could use legitimate, but insecure DLLs in their malicious webpages to subvert secrurity.
Now, what's Native Client:
Native Client is a sandbox with exactly the same security properties as they exist in the Java Virtual Machine. There is zero opportunity for a malicious piece of code to simply issue a system call. All it can do is to request the Google Chrome runtime to perform some system call on behalf of the malicious code. Similar to the Java Security Managers, the Chrome code will verify the correctness of the request (for example, is it in the file system sandbox intended for the downloaded code or not) and either approve or deny it. There is no way for the external code to manipulate the Chrome checking code, even though it runs in the same process.
So folks, before you spill your barrel of shite, please check the FACTS.
@Schlamperei Ist Teuer
I tend to find people who emphasise words in caps are either raging about religion or alternative medicine. For example:
"You must accept the LORD into your life or you will BURN, you horrid EVILUTIONIST"
or
"MMR research is all funded by BIG PHARMA who control the government and who are EVIL"
Therefore I choose to ignore all that you say.
Sandboxing / VM is a good idea and a good way to put a barrier between malicious code and the OS. But that doesn't mean there are zero exploits. Even Java has suffered various JVM / plugin flaws, e.g. this zero-day JNLP one http://seclists.org/fulldisclosure/2010/Apr/119. Firefox also invoked a remote kill command on a .NET / CLR plugin because of another exploit.
Sandboxes are still much better than nothing though, and certainly better than ActiveX which had a rotten security model based on trust and nothing more. Security should be a series of graded measures starting with a user's common sense, warnings, app signing, site blacklists, sandboxes, virtual machines, browsers running in restricted modes, kill switches and ultimately firewalls & virus checkers. The hope is that if one thing doesn't catch an exploit then perhaps the next one will.
So it DOES sound a lot like Java when it was first pitched. Quite agreed, it's not really like ActiveX.
Don't forget, recent times we've seen Oracle suing Google over Java implementation, it seems like a logical way out of that little argument, whereby Google gets to turn round and tell Oracle where it can stick Java.
So you are telling me there is zero opportunity for a malicious code. Have you heard of a term called "bug in the code"??? Or you telling me the code Google has written is totally bug free and it is impossible for malicious code to do anything nasty-I wish I could write that kind of bug free code
The difference is that ActiveX is insecure by design - once the control is 'trusted' -- which has nothing to do with what's in the code -- anything is possible. It may be that no implementation is perfect, but that's much better than no protection at all. Also, it's all open source (unlike Active X trust code) so problems will get found much faster.
..it can be exploited. It doesn't matter how securely you design it, it's either crippled in fundamental ways or exploitable. Code can't tell a users intent, I may need to write something to a sensitive area of my machine, it may be some trojan trying to install a root kit.
I don't doubt google are trying hard to make this secure, but the fact is if I want to run native code on my machine that's not currently a problem. Installing apps locally is a great way to do this. It's google's business needs that are driving this, not the needs of users. The way the internet is used is currently too insecure for this to be a sensible, secure way of working.
All the arguments you brought up against Native Client are based on "how can we know the implementation is perfect" ?
This argument can be used in the same way against Windows/Linux process memory protection, the Firefox JavaScript engine, PDF viewers of all shades, Flash players and even "simple" things like HTML renderers.
And yes, each of these had horrible exploits in the (not so recent) past. Including Firefox JS and the Linux kernel. But at least with Linux kernel and FF, all of it has been immediately (less than two days) patched.
The question is "is the concept rock-solid" ? And that question can be answered with a whole-harted "yes" for FF, Linux kernal and Google Chrome.
ActiveX, on the other hand, is simply unfixable. It's associated to lots of malware attacks and I grew a bit angry to see people throwing dirt at a very interesting and very solid concept.
I don't work for Google, but did interviews with them. I don't earn money from them and I don't like that their huge trove of data could be used against me (e.g. by USG) . But that's not the fault of this technology.
When they say native code they actually mean you write in C++ or whatever and compile to LLVM bytecode. The byte code is then translated into the equivalent native instructions with whatever metrics / security / hooks they wish to generate at the same time. So it's not really native code and presumably they can control what you can or cannot do from a sandbox. So theoretically it is inherently no worse or better than any other virtualization layer. The devil is in the details of course.
The biggest problem I would have with native code execution is that while it might be open source, it's really more closed as Flash, Silverlight etc. since its tied to just one browser. At least those other techs are relatively browser agnostic and implemented through an NPAPI plugin. I wouldn't be surprised if Google tried to make an NPAPI wrapper which allows native apps to run in other browsers but I suspect it will be filled with all kinds of limitations.
Google also seems to be going schizophrenic, simultaneously promoting two operating systems with two distinct virtual machine technologies. Why is ChromeOS pushing a LLVM solution and Android is pushing Dalvik? Someone high up in Google really needs to knock some heads together and merge these efforts. An android with both Dalvik + LLVM would be a nice thing and port over the fancier Chrome browser too to run on top of it.
It's finally clear that Google are trying to lock people into their technologies ala Microsoft. The only difference is how they get paid: not up front by the customer but after selling your personal data to advertisers or the government. I call BS on all their babble about openness.
While I agree that the number of web "standards" should not be too high, I don't see this as a valid argument against new technologies. We can't keep using the same old technologies forever.
LLVM is in many ways a better VM than JVM and Javascript, even though these (by virtue of Turing completeness) are theoretically enough. LLVM is less tied to a specific language paradigm than both JVM and Javascript, so it offers better support for more different high-level languages. While you can implement, for example, statically-typed functional languages on top of Javascript and JVM, it is rather cludgy and you can't get rid of the inherent overhead that the object-oriented or dynamically-typed paradigms og JVM and Javascript offer.
LLVM is not ready yet, though. There is not a precise and complete enough description of its semantics and not enough stable backends for different platforms. But I think these will come.
There will never be zero opportunity for a malicious piece of code to simply issue a system call. How will Chrome code verify the 'correctness' of every request? How could it? And if the checking code does indeed run in the same process, someone will easily find a way to manipulate it.
Please, Mr. Metz, press the "spell-checker" button once in a while, or have someone proofread your articles before publishing.
Other than that, I found this to be an interesting on Google's continuing strategy of throw stuff to the wall and hope that at least one sticks. The problem is that, even when one sticks, they are too busy cooking more pasta to pay attention to it!
By the way, when Google talks "close vs. open," especially in the context of Native Client, they are it is obvious they are referring to Apple. My take is that they have realised that Apple has a good strategy of supporting native as well as web applications in their iOS devices, and that perhaps their "everything runs on the web" may not be able to compete directly with that. Therefore, they are offering a way to leverage native-ish application support on their "die web ist alles" platform, Chrome OS.
Of course, Android already did this rather sanely and successfully, but they realised that all those Dalvik applications running outside their precious web, do not necessarily expand their web-advertising empire. That, or they didn't noticed that particular strand of spaghetti stuck on the wall.
Seriously, Mr. Metz: spell-checker please.
-dZ.
..so I would say the organic Native Client GUI solution could be
* C++ with the Juce GUI Toolkit (based on NPAPI)
* Google Go with GTK
(all of that running completely inside the browser window)
I assume GWT is there to stay until Native Client is part of FF, Opera, Konqueror and IE. Which is not that likely at the moment. We will see.
If you are Java Developer and use GWT (I am doing so currently), you quickly realize that GWT only really make sense using Java. Here is why, a big part of what makes GWT appealing is because the huge army of java developers out there get a very familiar API/environment to develop JS webapps in, and the front and backend code are all in the same language. This is the same reason Andriod uses Java, and not because Google felt Java is the best platform out there. When it comes to platform success, number of developers matter.
Basing GWT on some other language/platform (except maybe .Net) simple wouldn't make much sense.
This is a technology site, so if you really want to know what Native Client is all about, maybe you take the time to read this
http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf
,before you write half-truths here ?
And if you still think it is less secure than a JVM, please post your questions for people like me who actually read the paper.
Regarding Security Managers, I think there is a consensus in academia that you can make them safe. Whether SUN ever got them right, I have some doubts, though.
There is a consensus that SE Linux and AppArmor have strong and dependable security managers. There is a consensus that an OS like Linux and the MMU can lock processes out of the kernel. So if they manage, why shouldn't Native Client ?
Secondly, NaCl does not need LLVM. It might be useful as an ANDF
http://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format
though.
Thirdly, NaCl allows for basically any programming language to compile natively against a CPU, if a small number of precautions are taken during code generation. You don't need to use Garbage Collection if you don't like it, which is different to the JVM. You are not forced to use the simplistic memory layout scheme of Java or .Net. Neither that funny bag concept of JavaScript.
It would not be a major effort to port COBOL, FreePascal and a ton of other compiled or interpreted languages to NaCl. Only a little change in the code generator is required (alignment of jump target addresses , alignment of indirect jumps, and instruction white-listing, basically). I find the Googlers had a refreshingly new idea and the fact they made it open source made it even more attractive.
Think of this application: An algotrader submits his trading code to the Stock exchange as a NaCl executable and the exchange will execute the algorithm directly in the process of the trade matching engine. Delay: 1 microsecond.
I love this line, "Mozilla argues that JavaScript is already approaching the speed of native code and that the gap is shirking rapidly." Especially the link to the article which compares JavaScript to Google's "native code" system which still has a translation layer. Compare JavaScript to some C or C++ equivalent and then come back and tell me the gap is shrinking rapidly.
>Google will continually update the operating system with new tools via the net.
Unless of course it flops doesn't make us money in which case we will pretend like it never existed like many of our other products in the past. Oh and if we get sued of course we won't indemnify you. Anybody that would risk their business on a Google product is a risk taker indeed.
If you want to develop a webapp (say a flight sim) with Google Native Client, you can use the free GNU C compiler with some small tweaks from Google to implement your algorithms.
To output pixels, you program against NPAPI. File and network access would be handled through a Google-provided API. Then, create a webpage and slap the Native code DLL on that website.
The Google runtime will make sure you only use proper x86 (or ARM, whatever) instructions in the proper way (especially branch targets must be taken care of). If you fiddle with the binary code in an unsafe way, the Google Native Runtime will refuse to execute the code.
Very similar to the Java or Flash runtimes except that the target is not bytecode but x86, ARM or any other supported CPU. The onus is on you to have all executables for all interesting platforms available. Which currently is just x86, so its easy.
The great thing here is that you can even program in assembly language and use the SSE instruction set, which is critical for quite a few applications. Just make sure your indirect jump (and call) targets are on 32byte boundaries. Use NOPs to achieve this. The penalty is not very large typcially. On ARM wideword (32bit) you don't even need to do that, IIRC. Of course, some instructions are prohibited (like software interrupts).
If you just use a GCC highlevel language (C,C++, Ada, Pascal fortran, GNU Java) it is just a rebuild with a new CPU target to "port" to ARM, PowerPC or S/390. GCC already supports all of that. Whether you can already use anything except C/++ at this point I have doubts, but due to the modular architecture of GCC, this should not at all pose a problem. Google only changed the code generation stage slightly. Any frontend (like fortran) can be used with any backend (e.g. S/390).
Whether there will ever be a Google Chrome browser on S/390, I don't know, though :-)
Unless, Google makes this a browser natural technology, don't see this being successful. Most of situation you would use this in can already be done using Java. And if you really need performance then my guess it native apps will still be the way to go.
Those anyone have any comparison between performance of a realistic piece of code in NACL and a Java applet? I bet the applet competes pretty well, and least well enough as far as the end user is concerned.
..would dispute that Java claim. Cue: simpleton memory structures, no stack allocation, no destructiors, Garbage Collection, lack of real-time capabilities.....
But you can surely point me to that Java-based Flight Simulator/Quake Copy/Voice Recognition SW/Radar Processor/Image Recognizer ?
All those things you mention would be best done as a native apps, and that's my point. You could do them as Java Applets very easily (There was a quake port to java and there are voice recog java software out there), but that's not going to make much sense from a business point.
Very little reason any one would want to have those things run in a browser. The point about applet is that, if you compare performance of the JVM on modern hardware to that of native code the difference is minor for most task. Even google recognizes this, and that why the are basing NACL on reuse of native code that already exists and not rewrites. This is the same thing with JNI(access native libraries) and Java.
see this:
http://www.xmlbooster.com/benchmark.html
Then explain away the Java inefficiency. And no, XML is not the most efficient data format, but I think the benchmark above says something about the general question of Java efficiency. I could go on providing arguments, but I leave it as homework for you.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
