[b0]

Not quite, and I'm not confused.

Both have sandboxes (ActiveX since Windows 6.0, IE7), both have restricted APIs, both run native code.

PNaCl is equivalent of silverlight which is cut down CLR.

More performance - I doubt it. CLR+JVM is pretty much up there. The moment you add any virtualization, trap code or translation layer to native code via NaCl which you will require for security, there is going to be overhead which will knock it inline with a VM architecture. Startup time might be less - that is it.

Better security - that's a lie. Virtualization on any layer never gave anyone better security. It's throwing stones in glass houses. The only hard security boundary is at the MMU/page table. As NaCl grows, you will see it break.

No-one getting sued? I'm sure the EU will have something to say when no other vendor implements it and Google uses it to leverage market share, much like Microsoft did in the late 90's and early 00's.

[justinschuh]

I'm sorry, but you are so grossly wrong in your statements that the only valid response is a bit of a fisking. Normally I'd prefer not to respond this way, but I've already engaged you, and I can't really let this much misinformation stand.

> Both have sandboxes (ActiveX since Windows 6.0, IE7), both have restricted APIs, both run native code.

ActiveX is a general purpose object API and has no sandbox at all. IE 7+ on Vista+ can instantiate ActiveX controls in a weak sandbox via low-integrity mode, but to imply it's comparable to the NaCl sandbox is just comically ignorant. NaCl validates the nexe's conformance and its subset of x86 instructions before it will run it (in that way being very similar to Java and .NET CLR). And NaCl runs entirely in an outer, system-level sandbox that denies all system and object access.

In contrast, IE's low integrity mode lets you read anything the user can, exposes massive chunks of the system as attack surface, and provides various writeable locations. On top of that, all non-trivial ActiveX controls in IE implement brokers which run fully outside the sandbox--something that's not even possible with NaCl.

> PNaCl is equivalent of silverlight which is cut down CLR.

Nope. And making that claim begins to underscore just how little you know about this.

> More performance - I doubt it. CLR+JVM is pretty much up there. The moment you add any virtualization, trap code or translation layer to native code via NaCl which you will require for security, there is going to be overhead which will knock it inline with a VM architecture. Startup time might be less - that is it.

Virtualization or trap layer? That's not even close to how NaCl works. It's really sad that you couldn't be bothered to read a one-page explanation of before you launched into this completely wrong-headed diatribe. Please, start here next time, so your trolling can at least be superficially informed: https://developers.google.com/native-client/overview

> Better security - that's a lie. Virtualization on any layer never gave anyone better security. It's throwing stones in glass houses. The only hard security boundary is at the MMU/page table. As NaCl grows, you will see it break.

Once again, premised on your total ignorance of the subject matter. Come back when you have at least a basic knowledge of the thing you're criticizing.

> No-one getting sued? I'm sure the EU will have something to say when no other vendor implements it and Google uses it to leverage market share, much like Microsoft did in the late 90's and early 00's.

I'm sure there was an attempt at making an argument in this last line, but mostly it just seems to be randomly scrambling for scary sounding words.

[b0]

Excuse my ignorance on the matter but you make yourself look immature, arrogant and patronising and this does no credit for your project or yourself.

So basically, NaCl:

1. Validates the binary image. Of course that validation has no holes in it. When it does it...

2. Stops unsafe operations. Of course it never misses any and knows every instruction side effect...

3. Oh wait...

I'd put cash on someone breaking the sandbox, I mean after all it's perfect isn't it:

http://www.matasano.com/research/NaCl_Summary-Team-CJETM.pdf

You can't build a flawless sandbox on top of a system by closing the holes one by one, especially on x86/x86-64. The number of edge cases is immense.

[justinschuh]

I'm sorry if you feel slighted, but I'm only attempting to dispel your ongoing stream of misinformation. And even after being corrected, you've persisted to the point where it's hard to perceive your behavior as anything short of intentional malfeasance.

As for the strawman in your latest comment, no one made any claims of "a flawless sandbox." I rightly pointed out that the security model of NaCl is far more robust, and you've offered nothing to counter that. Now, of course, software is going to have bugs, and the ones listed in that paper are significant. Fortunately, no combination of those bugs could have breached the outer sandbox, and would not have represented a real-world system compromise.

The origin of that paper also circles back to a very important point. We realize that we need to attack security from many different angles (fuzzing, sandboxing, bounty programs, etc.). And that paper you cited was actually the result of Google sponsored competition in 2009 against a pre-release version of NaCl. The authors were the second place winners, and have continued to research NaCl's security both as independent researchers and paid consultants. (One of them is actually presenting at Black Hat on NaCl security this week.)

My point here is that an objective read of the paper really paints NaCl very positively from a security perspective. Had you actually looked at the content rather than just made an assumption based on the title you would have been aware of that.