Google Native Client Puts x86 On the Web 367
t3rmin4t0r writes "Google has announced its Google native client, which enables x86 native code to be run securely inside a browser. With Java applets already dead and buried, this could mean the end of the new war between browsers and the various JavaScript engines (V8, Squirrelfish, Tracemonkey). The only question remains whether it can be secured (ala ActiveX) and whether the advantages carry over onto non-x86 platforms. The package is available for download from its Google code site. Hopefully, I can finally write my web apps in asm." Note: the Google code page description points out that this is not ready for production use: "We've released this project at an early, research stage to get feedback from the security and broader open-source communities." Reader eldavojohn links to a technical paper linked from that Google code page [PDF] titled "Native Client: A Sandbox for Portable, Untrusted x86 Native Code," and suggests this in-browser Quake demo, which requires the Native Code plug-in.
Re:Two steps backward (Score:3, Interesting)
I really hope so. Does anyone actually enjoy programming JavaScript? No real objects, weak typing, etc. It's fine for small bits of code, but for larger apps? Ugh.
A "lite" version of Python would be nice. Shove (erm, specify) lots of interesting libraries into the browser itself, and let us use those.
Re:Two steps backward (Score:5, Interesting)
The only problem you seem to have with Java plugins is the load time -- this is only resolved by Javascript because JS is pre-loaded by the browser at all times (in modern browsers at least).
If other plugins were to be marked as 'frequently used' by the plugin engine and loaded at runtime instead of page load-time, they'd obviously be just as responsive as Javascript (or more so, since Java is compiled to native code in many cases).
Making a browser that integrates Java in a reasonable way and makes it work just as seamlessly as Javascript was tried already (by Netscape) but it was before we had computers with enough RAM to handle it IMHO.
Something similar from Microsoft (Score:5, Interesting)
You can find more details here [usenix.com].
Re:doesn't sound too secure yet (Score:3, Interesting)
Yes all new technology is bad even R&D concepts. Dag Nabbit I want my ASCII (no freaking colors) 300BPS BBS back you know the ones where you need to put your phone headset into the modem. Back then everything was secure. The password was the telephone number that you dialed. Brute force attacks were expensive. And if the BBS had a Password protection you were secured to no end, where no one can get in who you didn't want.
Um the way things work with software is the program sends opt-codes to the CPU which interns translates them to particular basic actions. You could emulate X86 across platforms and it has been done before. Virtual PC did that in the past allowing you to run x86 code on a PowerPC processor. For applications all that we really care about putting input in a black box that will do stuff and getting output back. The Web Interface is good at taking input and giving output (By no means the best, but it can get the job done with a lot of tricks) So if google approach is server side then it would in general be available across clients platforms. Allowing you to run a wide array of applications regardless of your client.
Re:doesn't sound too secure yet (Score:5, Interesting)
x86 code runs natively on 90% of the processors out there. Java or .NET bytecode runs natively on about 0% of them (Sun did have a Java chip once but it is long dead). So it is hardly any worse than the alternatives. There are many x86 emulators and some of them have reasonable performance.
If we were starting from scratch now, nobody would choose the barnacle-encrusted i386 instruction set as a way to distribute programs. But given the hardware and software that exists, it's not such a bad choice.
Of course, the way to do it is to define what instruction sequences are safe and allow only those. I assume that's what they are doing and 'modules may not contain certain instruction sequences' is just the one-line summary.
That said, you can make any instruction sequence you like using the assembler and run it on your Linux system, and it cannot break out of the process virtual machine to access hardware or memory belonging to other processes or the kernel. If it can, this would be a bug in Linux. So there is no reason why arbitrary instruction sequences couldn't be allowed in principle, if you let the operating system do the work of sandboxing the process. After all why reinvent the wheel?
Re:Two steps backward (Score:2, Interesting)
C/C++ are programming languages, not build environments. There's nothing to stop developers using qmake, or Jam, or one of many more user friendly build systems. The fact that the examples don't is more indicative of the intended audience (expert native-code developers) than anything else.
As to "why build this at all" ... because they can, they want to and it has the possibility to provide a feature set not currently available. No one who isn't a graphic designer likes websites made entirely out of flash; but flash games are undoubtedly popular and fun. In general I don't like the use of Javascript (if I see another stupid fading menu I'm going to hunt down the developer who wrote it and kill them as they sleep) but I love the GMail interface and wouldn't be without it.
The web is nothing if not Darwinian. If this technology has no real use it will go the way of Java applets and VRML. If a killer app can be found it will become part of the landscape and we'll all forget what it like to live without it.
Re:Two steps backward (Score:5, Interesting)
I do. And so can you. [yahoo.com] It's the C-based syntax that throws most programmers for a loop. Once you realize that the language is actually of a functional design similar to LISP, everything gets a lot easier.
Javascript has one of the most flexible Object systems I have seen in my 20+ years of programming. And its typing system is actually quite strong. Like another poster mentioned, it's dynamically typed not weakly typed. Which is an issue that fades into obscurity once you understand how to properly utilize the language.
Javascript (like most functional languages) is perfect for building large apps out of a massive number of small bits. Look up scoping in Javascript sometime and you'll understand that larger apps get built by having machines within machines within machines to go from simple tasks to ever more complex tasks. It is, in many ways, a more scalable solution than APIs and packaging. But it is different and therein lies the crux of its failure in the minds of many programmers.
Re:doesn't sound too secure yet (Score:3, Interesting)
Worse - their example doesn't even make sense ...
So you still end up downloading code ... and probably a lot more code, since you don't have libraries like javax.swing sitting on the users' machine to tap into, you have to download an entire UI ...
What would be better would be to more tha apps out of the browser completely. There's no reason that a java app sitting on your local machine can't do the photo touch-ups w/o having to be embedded in a browser, just like there's no reason you can't open up a remote file in the GIMP and edit it directly if you have the url, username, and password, without having to go through the hassle of right-click in your browser, save to disk, open in GiMP, edit, save to disk, then ftp'ing it back.
Of course, if too many people start relying on apps that interact directly with the net rather than through a web browser, google's business is threatened.
Re:doesn't sound too secure yet (Score:5, Interesting)
Pretty much all of Sun's offerings have HotSpot built in, which provides JIT compilation for the JVM. IBM's JVM, BEA, etc. all have JIT features. Google's Android has Java-like Dalvik, which is slow as balls and doesn't have JIT functionality.
Some ARM processors are capable of executing Java bytecode natively. The device developers have to pay for that feature though.
Really, it sounds like Google is poorly trying to reinvent Java. They've tried this with Android already and it doesn't work so hot from a performance standpoint.
Re:A remarkably bad idea. (Score:4, Interesting)
"In Native Client we disallow such [self-modifying code] practices through a set of alignment and structural rules that, when observed, insure that the native code module can be disassembled reliably, such that all reachable instructions are identified during disassembly."
Ok, when I read the post I had to chuckle when I read the asm joke. I've been programming in asm for 16 years now and there are a few rules of thumb:
- if assembly is allowed then the only real security is executed by hardware.
- malware writers love a challenge like this.
Re:doesn't sound too secure yet (Score:3, Interesting)
Well, a couple of things...
First, today there isn't a "first class" platform for Java. It's JIT everywhere (excepting a few devices with chip-based Java execution). So a web developer has to consider performance when using Java or Flash. In contrast, native x86 execution obviously favors x86 machines and creates a web ghetto - similar to ActiveX, though not quite as bad.
The second problem is that while Java, and now even Javascript, have been pretty well optimized on non-x86 hardware, I've yet to see a x86 bytecode emulator perform as well. Earlier in the thread someone pointed out how JIT-compiled languages are now about 50% as efficient as natively compiled languages. If this is true, then it seems really foolish to eek out that extra 50% by destroying the performance on all other platforms - especially when those platforms are growing so fast.
My experience with emulation is a bit underwhelming. My G5 Mac can emulate an x86 processor using Virtual PC, but it's slow enough that anything beyond Windows 98 is pretty annoying. I'd hate to see performance of x86 emulation on a phone!
Re:doesn't sound too secure yet (Score:4, Interesting)
my "platform" would be very linux and windows machine i've ever run - all on x86
try this for a "Slow platform"
Athlon 64 x2 6000+, 4GB DDR2-800, 250GB SATA-II drive
JVM initialization is slow because the JVM weights 9 million metric tons.
and initialization of the VM of any language is an important factor in it's effective performance - no matter if it's per-instruction performance once it's VM is started is almost as good as native code, it will take a long time for that to outweight the initial startup time.
Re:doesn't sound too secure yet (Score:5, Interesting)
Re:doesn't sound too secure yet (Score:4, Interesting)
1) They started the Android project before Java was open-sourced.
2) Sun has slightly different licenses for desktop and mobile use. The desktop license is GPL with a classpath exception (letting you write non-GPL java apps to run on the virtual machine), the mobile license is straight GPL. Google didn't want to force developers to only produce GPL apps for Android, so they could not use this.
See Stefano's blog [betaversion.org]
Re:doesn't sound too secure yet (Score:3, Interesting)
Don't modern processors that are pentium IV's and above feature protection from data vs application code? Windows XP service pack 2 features it and I am aware that programs have to be recompiled to take advantage of it.
In a few years it will make sense just to compile the code for the pentium IV and above and you can have the extra protection in your programs like RISC processors.
Re:Two steps backward (Score:2, Interesting)
Either way, the entire applet must be downloaded before execution can begin.
Wrong. Here are some enhancements that have been added recently:
Java6: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4690736 [sun.com]
Java6 update 10: "Lazy Downloading" at the bottom of http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html [sun.com]
I'm not certain whether the latter feature also works for applets (I suspect so) but it proves my point that this is technically possible and already implemented.
Re:doesn't sound too secure yet (Score:2, Interesting)