Google has released the first official version of the software development kit for Native Client, its controversial plug-in for running native code inside the browser. In a blog post, Google product manager Christian Stefansen called the release an "important milestone" in Google's efforts to make native code as portable and …
An admission of failure
If they can’t run sh** fast enough in the browser, which has to run on top of an OS, then they’ll run the equivalent of ActiveX inside the browser. So now, instead of launching an app from my OS – whether Linux, Windows or Mac OS X, I’ll first need to open Chrome? F*** that.
@azimutha: Please Read Before You Write
Native Client technology will make sure the damage of the Buffer overflow is limited to the privileges of the applet, NOT the privileges of the user running the applet. Native Client comes with a layer of code which will check operating system call requests by the applet and will only allow access to a limited set of resources - similar to SecurityManagers of Java.
Like the Sandbox of Chrome, Native Client is an innovative and useful technology and it would be an enlightened approach to first read the papers they published, before throwing around mud. But who said "IT professionals" are enlightened persons ?
As a last remark, I don't work for Google, nor do I condone excessive data collection by any private or public body. Native Client is Free Software, it is very interesting and can be used without handing your data over to a third party. That's why it is good.
In reply to my previous message, i see that its just another VM, so i didnt read the article properly. Still dont see how this makes things any better though.
Native client is another sandbox for the Hackers to target, because after all, sandboxes have proven so secure in the past. I dont expect this one to be any different. Its just another attack face to have to defend.
No doubt the anti-virus people will be glad of the work though.
The other issue is that we will end up with the other effect of ActiveX, the fact that parts of the web will only work on certain OS's and processors. (Cos after all, the idea of using native code is to target OS's directly, and which OS do you think will be the primary target?)
More excitingly, they appear to be claiming they've solved the halting problem...
You can't analyse an arbitrary machine code program, but you can determine if an arbitrary machine code program is in the class of programs that you can analyse.
If "Native Client" is NaCl, what would that make "Arctic Sea"... ?
They didn't think that one through properly did they?
... or did they ... ?
Sorry, this sounds a lot like yet another Java / .NET --- especially the "portable" Native Client. Except it will be harder to program, because you'll be using C++ to generate your bytecode, instead of a modern language like Java or C#. Java and .NET both have it right in so many ways, I doubt that Google can do better on a core technical level.
How will Native Client take off when Java and Silverlight are still niche player?
And then we can look forward to spending years applying one patch after another, as it's discovered that Native Client's security looks like a piece of Swiss cheese.
At least it looks like Native Client will be better than ActiveX.
@Bob 18: Except
..that you do not know what you are talking about. NaCl with or without LLVM bytecode does not mandate inefficient storage strategies. Java and .Net do so.
NaCl allows for efficient strategies like stack allocation, value arrays, aggregated value structures and refcounting. Java and the like mandate "everything on the heap, please". And that makes it dog-slow. Systematically dog-slow. Even in 20 years time with extraterrestrial VMs written by the uncle of E.T.
So this is part of Google's new "make Chrome 9 as insecure as IE6" campaign then?
This is so hard to believe I just don't get it.
Stop talking crap azimutha
azimutha, no you will not need to open Chrome first.
You will simply just create a shortcut that excist in the OS desktop an one click is all you will need to open any application, an then it will just launch the application.
This is already possible to do in Chrome and Firefox.
Java applets, anyone?
How is the Portable NaCl different from storing the program in platform-independent Java bytecode...? There's no need to reinvent the wheel, people.
Native Apps vs Browser Apps
It simply all about the money. Once you make people need you you have a direct pipeline to their wallets. With the Internet increasingly becoming something that the politicians want to control, wanting the ability to turn off access to it anytime they desire <sarcasm> which of course will only be in times of DIRE emergency</sarcasm> it becomes something not to be relied upon.
I trust that the almighty dollar is what is driving all of this hosted-browser based applications stuff. I thought it was a good idea when anyone could host their own OR you could subscribe to a service OR you could use desktop apps (even on a thin-client with X), but the bureau of 'they' even want to retire X!
Allowing people to rent access to their own information (and being the one who controls the means of access) means a huge revenue stream for the landlord and ultimate control over communication (for business or otherwise) for the politicos (or those with aspirations of despotism). The problem becomes one of how do you get the herd to actually WANT to enter the abbatoir? Apparently you simply design something they will gravitate toward, like a magpie gravitates to a shiny bauble, or a moth to a flame.
I wonder if this is Googles version of 'Embrace and Extend'?
This already exists...
Note to Google - there already IS an environment that can download code dynamically, check it for structure, apply security constraints, and then provide low-level services to support the execution of that code on a given platform. It can even be used to dynamically re-compile code to execute on different architectures.
It's called an "operating system". Why add another layer to run it inside a browser?
Yes, you could get the operating system to do the fine-grained security, but:
* Existing widely-used operating systems don't do this very well.
* Writing a new operating system is a lot of work.
* It's hard to get people to install a new operating system.
So Google build these layers on top of the existing operating systems. Then perhaps one day, if people are only using Google's upper layers, they could get rid of or simplify the lower layers.
I think that's a more realistic approach to displacing Microsoft than telling people to wipe their discs and install GoogleOS instead.
If Native Client is NaCl, and NaCl is sodium chloride, then we have Arctic Sea salt, twinned with Pepper, and the Household Condiment naming theme continues ....
Using LLVM is the interesting bit.
I was in the cynical camp when google first announced “Native Client”… because yes, it is just does what Java or .NET has done before, but LLVM make the different and (for an organisation with deep pockets) worth building on. LLVM can support C & C++ because it a lower level VM than Java or .NET.
The emphasis has been on C & C++, but that does not preclude other languages. Mono has the option of using LLVM for runtime optimisation and RVM on LLVM often scores at the top Java VM performance tests.. so it should not be long before there are development kits for higher level environments (including Haskell).
That could be fun...
Havent' worked with Haskell in years... :)
Thanks Stephen for the enlightenment. This does indeed look promising:
1) LLVM is not a "low level VM" like I thought. It is a framework for cross-compiling
2) The LLVM framework has some very interesting tools like code validation. Not the standard crappy stuff, but what looks like the "provably secure" verifier stuff I read about a while ago.
3) LLVM is modular, so many languages could be used
However, since LLVM is not actually a VM, it looks like no garbage collection or other high-level features we've come to expect from Java/.NET. Indeed Mono is crippled when outputing LLVM bytecode. But, what if it were to be combined with this:
It is essentially a compiler / runtime that can impelement a "VM" in hardware using creating garbage collection, modern processor memory mapping, and memory barriers.
I retract my previous comment, this could be something. Looks like it needs some more time to bake though, and better developer tools.
It Could Be Argued That Garbage Collection
..is Not a Good Thing at all. See this:
C++ is acutally a very sophisticated language and offers many more options to manage memory than GC-langauges do. Just as an example, if I temporarily need 100 bytes of storage, I can allocate it in 100ns, use it and release in 100ns. The Cache line will be reused for the next allocation.
I still have my concerns, but damn... Real APIs and programming in Mono (C#)?
I'll wait and see how this plays out...
Oh, I see...
They're doing a version of Dalvik which works for any language (starting with C and C++)...
Are they getting worried about Oracle, planning on taking over the entire world, both, etc...?
- Boffins attempt to prove the UNIVERSE IS JUST A HOLOGRAM
- China building SUPERSONIC SUBMARINE that travels in a BUBBLE
- Review Raspberry Pi B+: PHWOAR, get a load of those pins
- Experimental hypersonic SUPERMISSILE destroyed 4 SECONDS after US launched it
- That 8TB Seagate MONSTER? It's HERE... (You'll have to squint, 'cos there are no specs)