Native Client: Google's craziest idea yet | Hacker News Reader

Native Client: Google's craziest idea yet

weblog.infoworld.com

86 pointsccraigIW39 comments

This article is really terrible. It spends half of the article before mentioning the actual contribution of Native Client, which is that it securely sandboxes C programs with little effort on the programmer's part, confuses source code analysis with object code analysis, talks about memory virtualization for security as if it had been invented in 2008 instead of ~1965 (and as if it weren't already a feature of every mainstream OS), glosses over the API differences and the difficulty of designing a secure OS API, and confuses Intel (one ARM licensee) with ARM.

In summary, it is an unreliable article written by someone without a clue.

Like VMware this is all based on problems with existing operating systems. I should be able to download, install, and run any application from anybody without compromising my system or adding much bloat. That's the real problem that needs to be solved and I think the first group that get's this working is going to become extremely wealthy.

PS: When you think about it VMware is one of the few operating systems that has real working security, but I wonder how much else an OS can do while still providing that level of safety and efficiency.

"Any application" would have to include applications that compromise your system.

For example, suppose you want an application that deletes any files on your hard ending with tmp. I offer it for download, you get it, run it, like it. Now (just because I can) I change the application (without telling you) to delete all files ending with doc. You've been compromised.

If "Open File" (which may or may not mean a dialog) is a service provided by the Operating System, then there is no reason why a sandboxed application would have access to anything more than the particular file you have open.

People have been researching other security models for decades now. I'm afraid I have to say: they're way ahead of you!

Right, but then you are only including applications that have limited access to files, not any application. I was just lured into a good paradox. :)

In such schemes, all applications have limited access to files. Again, these guys are way ahead of you.

Not true; in KeyKOS, for example, the shell had full access to all the files the user had access to, because that is where the user held the keys of their directories. In CapDesk the window system has the same role. In general you need to be able to run "utility" programs like the tmp-remover in the example.

That doesn't necessarily mean the author of the utility programs has to be able to send updates without your approval, or that they need to be able to receive communications from their utility program, or that you can't delegate your approval of application updates to a third party who vets the code, or that the utilities can't be small and clear enough that you don't have any doubt about what they're doing, or that all programs need to have full access to your files, or that you can't store your files somewhere where you can roll back undesired deletions.

In those cases, the security schemes are somewhat weak. A proper sandboxing scheme wouldn't need a .tmp file remover. Once you removed a given application, all of the .tmp files it produced would just disappear with it.

The only reason you'd want to run such a utility would be to clean out the .tmp files within a particular sandbox. In that case, you'd give permission for it to operate on the whole of that particular sandbox's contents. Worst case, it trashes that sandbox, then you roll back to your previous backup.

They were supposed to have a sandboxing scheme along these lines in the OLPC.

If you think KeyKOS's security scheme was "somewhat weak", you should read the DTOS review of it (in http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/final-docs/...), which was mostly positive. It includes a pretty balanced picture of its pluses and minuses, although it doesn't seem to have been based on experience actually using KeyKOS.

If your files belong to your applications instead of to you, or if your sandboxes don't nest, then your sandboxing scheme is pretty lame.

Most of the time there are worse cases than just deleting your documents: the utility could send all of your documents to its owner over the internet. You can prevent this with sandboxing policies too; KeyKOS solved an analogous problem in the context of a multiuser non-networked mainframe. More difficult is to keep it from inserting backdoors into your programs or subtly corrupting your files.

I don't see how the solution "then you roll back to your previous backup" is dependent upon only the utility only having access to a single sandbox. It seems like it works just as well if you give it access to everything except your basic UI (and the TCB it depends on, e.g. the kernel, the bootloader) and your backups.

Ah, so you're talking about capabilities? I thought you were arguing in favor of the other guy's position -- that there's nothing you can do about malicious apps. (And maybe in the face of ignorant and gullible users, there ultimately is nothing, but lets leave social engineering out of this for now.)

I just didn't want to explain capabilities for the nth time, so I thought I'd throw the OLPC at him. Even a sandboxing scheme like the OLPC's addresses his objections. Not sure if it was supposed to nest.

There are lots of ways of implementing sandboxing; I think capability systems are the most elegant and flexible, but I don't know for sure that they are the best way, given that the judge is the messy real world, not mathematical abstractions.

I was arguing that the other guy was right that sandboxing in itself is not sufficient; you still do need to have a way to deal with code that you give the full run of your system, even if you keep the amount of that code to a minimum.

What if no application could delete files?

I don't mind a program flagging them as unimportant but if I have enough space to restore any file deleted in the last month what's the problem? Toss in a wizard to restore things to before I installed that program and it becomes harder to damage the system. Heck, add a pop up if the OS wants to destroy a file that was marked as unimportant in the last month and it's going to become hard to damage the system like that. You can even treat updates like deletes where the OS protects the old state for a week / month / year.

I'm not sure where you're coming up with this "real security of VMWare" idea:

(1) VMWare has had plenty of security problems, ranging from guest-hopping attacks to remote code execution.

(2) If VMWare is more resilient than Win2k3 or Linux, it's because VMWare does less and has less of an attack surface.

(3) In any realistic compute environment, VMWare adds security concerns; it doesn't subtract them. That's because you still care about the security of your guest OS, even when it's running underneath VMWare, because that's where your actual data lives.

I think of secuirty as a reasonable spectrium. I would like to be able to install software from my bank, a well known software company, and NBC without consern that they will corrupt my system. I don't really need a system that let's my bank run any hackers program on their servers without concern, but it's gotten to the point where I don't install software without a significant background check which is just silly.

This works exactly until you hit the point where you want to (a) re-use an app-specific VM for multiple runs of the same app, so it can save state, or (b) share any kind of information between your apps or your Desktop.

I don't see why I cant treat installing apps like I do updating files in SVN. I can have branches and merge them and if the changes are independent I can even undo changes without upsetting the whole system. As to updating shared files HDD space is cheep, outside of a few huge media files I could keep every file I have ever updated in every state it's ever been on my hard drive and still have room to spare. But, this is starting to turn into a rant so let me just say I want an OS designed around today's hardware not assumptions from the era of single core CPU's and sub megabyte hard disk drives.

PS: Most OS already try and split USER data from installation data just limit updates to installation files to installers which are carefully managed. Changing the windows uninstaller from independent applications to a branching tree would not be hard for most people to understand.

Now, it isn't an OS, but ZFS really does address some of these ideas: http://en.wikipedia.org/wiki/ZFS

It shares some of the features of other versioned filesystems, but with other nice additions. I know I'm planning on trying Opensolaris or Nexenta sometime soon.

Security, just like privacy, is one of these things that generates a lot of noise and heat, yet only people with vested personal interests are really worried about it.

Users don't give a shit. I've seen tons of support emails confirming this. They will continue to download and launch viruses just because their friend who sent them an infectious link thought that sheep jumping from under your windows look funny. And they will disable any software jail that stands between them and the sheep or the singing cat photos.

Most security-minded consumer software only makes everything else work worse, slower and annoy the hell out of people. It saddens me enormously that everything but port #80 on the Internet is blocked, everything except HTTP is banned and most users of my application will be threatened and screamed at by their own computer simply for trying out what I'd built.

This security hysteria not only doesn't work, but it chokes the innovation, restricting us to sit forever in this little crippled world of Mozilla/IE/WebKit runtime with 90% of what a computer can do unavailable to us.

JVM has been around for nearly 15 years, being many times more powerful than Mozilla and WebKit's wildest dreams, yet it has failed outside of data centers because it never allowed OSX programmers to write true OSX programs or Windows programmers to write true Windows programs, and I see no reason why browser-based "boxes" will be different. And you need true OSX programs if you want the consumer market. For the enterprise - yes, they eat anything, users of enterprise software get paid to use that shit, but if you want software markets to strive, if you want people to open up their wallets, you'd have to do a lot better than that. Otherwise we'll be locked forever in this eyeball market of free crap supported by canadian pharmacy advertising.

Let's take the average user who goes to www.cwtv.com and installs a plug in to watch their videos. Now if it works that's great, but what if there are problems? What if you install an old game that messes with your system? What do they do next?

Users want the systems that "just work", so adding something as simple as an OS level uninstall that always worked would be a major boon that people would notice. Is it really that hard to build an OS that protects it's self from unintended harm? Plenty of people buy Ant Virus software for a wide range of reasons but it helps is enough to make the developer a lot of (Edit: Money).

PS: I am suggesting that VMware, Java and all the others don't own the market at this point. It's much like search before Google where it almost works, but nobody seems to be focusing on the real problems.

A lot of this is a matter of packaging/marketing. Technology that looked a lot like the JVM had been around for well over a decade. One way to think of the success of Java, is that it "packaged" such technology in a way that was attractive to a large user base.

Most security software is not packaged and marketed in a way that is really attractive and useful for end users. From what I've seen, it's usually good for the nerds, but a bit of an obscure PITA for the average Jane/Joe. Contrast this to OS X's incidental low virus rate through obscurity. Now that was packaged and marketed very well to end users, and I'd wager that quite a few users paid a pretty penny for it. Technologically, there was hardly any substance there.

The technology is already out there. Whoever manages to package it for end-users is going to cash in big time. (Witness Dropbox. The ability to diff a directory and create a recoverable log of the changes has been around forever. They're just succeeding at marketing it to end users.)

VMware has real security? I do not think that everyone agrees:

http://kerneltrap.org/OpenBSD/Virtualization_Security

On a side note, Google has tried to hire Theo de Raadt. Perhaps they wanted him to work on this project.

Did they fail to hire him?

Looks that way. Of course I can only speculate about the reasons, but if I were in his position I'd turn down a Google offer.

VMWare is an operating system? must be some stretch of the definition; it's a "Hypervisor" http://en.wikipedia.org/wiki/Hypervisor running on top of an existing operating system.

They do sell a "bare-metal" VMWare, based on Red Hat Linux for what I know.

I think ESXi server and VMware Infrastructure are both "bare-metal" but I don't use their tools so I don't really know.

The thread off this comment is a great, intelligent discussion of many of the issues we're dealing with at BaseShield (YCW08 - http://baseshield.com). Specifically where the balance between ease of use and security sits for normal users and how software installation would work in an ideal world.

Sorry for the self-promotion, but I'd love to talk more with any of you about how our product is hitting or missing on these points. I'm at pat -at- baseshield.com if you want to email.

Thanks!

Hi, I have a working prototype that aims to solve this problem, and a good partner with a good b-plan, and an initial system design. I would like to hook up with a few other talented individuals to get this done on the cheap. We've been told by many potential investors / VCs that the idea is fantastic, but they want a working beta first with customers. It is a chicken/egg problem right now. If you want to discuss ping me at davisford at gmail.

In Sugar whenever you join a group activity the application is downloaded and run from the group. Whilst their security system is fairly untested I think that this is a more sensible model than moving everything into the browser.

There's some more information on the security system here: http://wiki.laptop.org/go/Bitfrost

I just don't get this stuff. The browser just isn't a great place to be running applications like that. It's a good place for consuming document based data. At the point where you have delivered an application that doesn't need to transfer any data as html-over-http, why would it be running inside the browser?

Maybe it's just that quake is a bad example use of this technology.

Right now, there is a Web site (pogo.com) where people actually pay money to play pointless, boring games (such as Solitaire, Mahjong, etc), all of which are written in Java.

A similar Web site, using Native Client, could roll out higher quality games (like Quake) and charge higher prices for access.

It all comes down to the fact that for Google the browser is an advertisement delivery tool. Hence every browser improvement has the potential to increase revenues for them.

" The code runs on the actual processor"

...as opposed to... magic?

(and yes, I understand what he means, I just found it amusing)

Great idea.. clearly Google has its eyes set on the OS market. First, move as much stuff to the cloud as you can, then open up NC for legacy apps.

"this method leaves many handheld devices in the cold, including those based on Intel's ARM chips."

haha

What's funny about that? It's a real issue and the first thing I thought of when I head them say "native x86". Consider that there are also netbooks that have ARM architecture as well (unless I'm mistaken).

Or are you referring to only the last 3 words? Intel's ARM chips?

It could be a problem for device vendors, but it shouldn't be a problem for web sites that want to serve ARM9 devices with MMUs, such as Intel's StrongARMs; the Native Client approach will work fine on ARM, although it will take some work to make it happen. The bit about "Intel's ARM chips" is pretty goofy, though.

One question: If they are using 80386 memory segments, how do they cope with systems like AMD64 and the linux kernel both of which have flat memory systems? Besides, normal desktop OSes already isolate programs in their own memory segments. Its the device access permissions and systems syscall accesses that cause all the problem with secure object code usage.

uh, no thanks!

Yawn! I hate it when people link anything from infoworld.

Reply on news.ycombinator.com