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 plug- …
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...
Is it me...
Is it just me or does Pinnacle or Portable Native Client sound an awful lot like Java was first pitched as?
It sounds worse than that...
...it sounds more like ActiveX.
@Active-X FUDers: NO !
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"
"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.
Zero opportunity is not quite true
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 I was right then...
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.
Really "zero opportunity"
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
And that's just great...
...until someone finds a hole to exploit, and that's what happened with ActiveX.
If it can do useful stuff..
..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.
@Arguments Against Sandboxes
All the arguments you brought up against Native Client are based on "how can we know the implementation is perfect" ?
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.
AC says "I tend to find people who emphasise words in caps are either raging about religion or alternative medicine. [..] Therefore I choose to ignore all that you say."
Says the guy who chose an icon with "FAIL" in large capitals.
ActiveX insecure by design
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.
take it with a grain of salt?
Nothing wrong with native code per se
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.
CPUs are not bug-free
What happens if there is a privilege escalation but in the CPU allowing you to gain kernel mode privileges from userland code? Who patches their CPUs?
The CPU vendor?
NaCl is not your worst problem then.
If you can find a way to escalate privilege using the restricted "whitelist" instructions that are allowed by NaCl, then you've got a serious problem and the CPU is to blame. NaCl won't even load the program if it contains non-whitelist instructions.
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.
Evolve or die
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 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.
If it's unchecked native code...
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.
how to check correctness
(1) define correctness in a spec (2) review the spec, including publishing it (3) implement code which checks correctness according to that spec (4) publish, review, test, and verify the code
yeh fine, it's secure and all.. Just hope it really does perform well and not make the beloved browser unstable! heh
OMG! The typos... they' coming!!!
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-Jay: Spell checker? pott blames kettle...
Yes, I saw that. Ironic, innit?
However, in my defense, there is a universal law that states that any post from a grammar-nazi pointing out mistakes, will itself be riddled with the same. So it's not really my fault, you just can't fight the Internet Forum Fairies.
DisASSembling is what I'm supposing to be doing to now. Dissembling is what I'll do when the boss asks me how it's going.
"that allow it to dissemble instructions"
is someone telling porkies or did you mean "disassemble" ?
Does this mean Google will be releasing a non Java, native version of GWT? And what does the spat with Oracle mean for the future of GWT?
I can only guess
..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.
Not Really, GWT will always be based on Java
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.
Let's Try Again in Merkinish: "Education Is Key"
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
,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
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.
don't bet the farm
>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.
Fear, uncertainty, doubt.
Native C code?
I'm not sure I understand the concept here. Are they talking about embedding C code in HTML and then JIT compiling it in the browser?
That in itself sounds pretty bad, but it is a lot better than the alternative, which would be embedding compiled binary blobs into interwebsites.
Indeed, Native Code Downloaded
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 :-)
Can't see this being successful
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.
@Nathan 6Whoever Codes C For A Living
..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 ?
Miss my point
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.
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.
Native Code in a Google World
..its a Google World !
Merry Christmas, everybody.
- Fee fie Firefox: Mozilla's lawyers probe Dell over browser install charge
- 20 Freescale staff on vanished Malaysia Airlines flight MH370
- Neil Young touts MP3 player that's no Piece of Crap
- Review Distro diaspora: Four flavours of Ubuntu unpacked
- Apple releases iOS 7.1 update in response to cars, complaints, vomit