Slashdot Mirror
Google x86 Native Browser Client Maybe Not So Crazy After All
GMGruman writes "Google's experimental technology to run native x86 binaries in the browser shows lots of potential, writes Neil McAllister. He's previously said it was a crazy idea, but a new version of Native Client (NaCl) caused McAllister to take a fresh look, which has led him to conclude the technology is crazy like a fox. McAllister explains what NaCl is useful for, how to use it, and why it's not a Java or a Flash or a JavaScript replacement, but something else."
Now all they need to do is give it full access to the Windows Registry and we'll be right back to where we started.
I am qualified to comment because I have skimmed the article summary. Furthermore, I know perfectly well that any time a browser allows for new features, it's a way to get hacked by eastern bloc countries. Finally, I can't remember why I was angry in the first place, but I can guarantee you that if whatever it was is also the reason the honeybees have been dying off. I am getting so sick of this stuff!
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
So a proprietary, but open SDK to run native binaries on one vendors browser. What could possibly go wrong?
I hope Google put a heck of a lot more effort into security/sandbox issues than Microsoft did or I'm going to have to start telling people to never install Chrome. ActiveX was the best attack vector for Windows for the longest time, and as far as I know it's still pretty effective against the great unwashed who will click anything to make a dialog go away.
XML is a known as a key material required to create SMD: Software of Mass Destruction
The article is light on details, but they do say that the executables are contained in .nexe files which are apparently NOT your run-of-the-mill PE format, so they can't just execute from a double click. And they do say that there's this annoying multi-second lag as the thing fires up. From this, I assume they are doing dynamic code instrumentation to implement whatever security measures they have in place.
If done correctly, this can be secure. I've been working with Intel's Pin library a lot lately, mostly for security-related projects. With these sorts of things you can intercept all memory accesses, function calls, system calls, instrument and analyze arbitrary instructions in arbitrary ways, etc. Again, if done correctly a dynamic instrumentation approach could make this idea viable. But you'd need a very skilled team to do it right.
Yes. The media framework (audio, OpenGL, etc) is called Pepper.
If you havn't noticed, one of Google's intents is to make the browser you go-to place for all your needs (kinda makes sense with their business plan). And honestly i think that it is a worthy goal. This way people can make cross-platform applications and a way to distribute them all on one platform.
Violence is the last refuge of the incompetent. -- Isaac Asimov
That's been around for a while. x86 machine code has to be written in a special way which prevents certain problems, such as buffer overflows into return addresses. Google has a modified GCC for this. Read the research paper. It uses the rarely-used segmentation protection features of x86 CPUs to help provide an inner section of sandboxing. That's not enough, though; static analysis of the code, to check that all branches go to valid instructions, is necessary. This works much like the Java byte code verifier, the checker that runs as Java code loads. All returns and calls have to go through some extra code to insure that control goes where it is supposed to.
The 64-bit extensions to the x86 instruction set don't have the segmentation machinery. The AMD designer of that mode once told me "nobody uses that". So this approach doesn't translate well to 64-bit code, and all code under this system runs in 32 bit mode.
This comes with an API and an OS shim. Executable modules can make about a hundred system calls, which are portable across Windows and Linux. In the original version, you couldn't get at the graphics hardware, so it wasn't a suitable delivery mechanism for games. But now, Google has a connection to OpenGL in the thing. That makes it more useful. Games with full system performance could be delivered through this approach, while appearing to run within the browser. The performance is about 90 to 98% of unprotected code.
It's very clever, and a good idea from a security standpoint. Untrusted processes communicating through narrow interfaces are always a good thing from a security perspective. The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.
I really wish folks wouldn't intermix this crap with a web browser. I'm all for having some kind of a cloud browser for accessing Internet-based applications with the client running java or nacl or whatever. But when I'm surfing the web looking at untrusted sites, I don't want ANYTHING running browser-side. Not even javascript.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
The Java sandbox was at the interpreter level and did not provide protection at the OS level. The google native client stuff sandboxes it at the OS level and only allows for communication via RPC calls to the parent app (e.g. drawing on a canvas), much like the seccomp approach for Linux which is a true sandbox
Chrome is extremely sandboxed. Scripts running in Chrome don't have permission to randomly alter files, install software, etc. like ActiveX did.
I imagine they'll keep NaCl in a similar sandbox.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
While I appreciate the funny mod, it wasn't meant as a joke. http://code.google.com/chrome/nativeclient/docs/reference/pepperc/index.html
I don't see how it could be made secure at all
This may have something to do with you not making any effort whatsoever to read up on what NaCl actually does.