Thanks for all the feedback!

[Brad Chen]

There's some great feedback and discussion here and in the comments on the Code Blog post. I wanted to respond to a few points here. In general the team will be participating in this discussion group but will not be following up on comments on the other pages.

A number of people have asked about Java and other virtual machine strategies. I think these are great, and that the people who like them should use them and help make them successful. At the same time, a part of the motivation for Native Client is to give people more choices. Native Client was created in part for people who want to use other programming languages, and not be locked into a single language or programming environment just because that's all they get from a particular VM.

Some of you are concerned about the technical challenges in making Native Client secure. So are we, and that's why we are sharing the system in this research release, so the community can review it with a critical eye. These concerns have been with us from day one of this project, but as we continue to work on the system we have increasing confidence in what we can do with this approach. So, while feedback and discussion are very welcome, we also hope our critics will show us specific design and implementation defects that allow them to break out of the sandbox. Such specific defects are the real key to whether or not we can make this system secure.

Thank you for your interest in Native Client.
Brad Chen

[Peter da Silva]

On Dec 9, 11:39 am, Brad Chen <bradc...@google.com> wrote:
> Some of you are concerned about the technical challenges in making Native
> Client secure. So are we, and that's why we are sharing the system in this
> research release, so the community can review it with a critical eye.

You can't "review in" security for a technology that's inherently
insecure.

[Velo]

> You can't "review in" security for a technology that's inherently
> insecure.

The chance for abuse of any technology will never reach 0%.

It's worth doing everything possible to get it as close to 0% as
possible,
but a technology that offers substantial standards and application
benefit
should not be shelved just because you can't get to 100% exploit proof.

[Kekoa]

> > Some of you are concerned about the technical challenges in making Native
> > Client secure. So are we, and that's why we are sharing the system in this
> > research release, so the community can review it with a critical eye.
>
> You can't "review in" security for a technology that's inherently
> insecure.

Although I don't want to cast myself as a critic, but have to agree
with the previous sentiment... If you had security concerns from the
beginning, why even go down the path? Do you think the true
exploiters will be so kind as to give you the exploit? If I found an
exploit(and if I was an exploiter), I'm holding on to it, hoping it is
not caught until this thing is released.

I just learned of native client today and glanced through the
whitepaper. I am confused as to how replacing all jmp statements with
your own is reliable. Why can't someone just modify their own
compiler NOT to do this, linking in all the other code to make a
program look like a valid NaCl implementation?

Where is the real security implemented? At compile-time or run-time?
Relying on compile-time compliance to your rules is prone to error and
exploit in my opinion. I think in order to give a real educated
opinion I need to do more research, but I probably won't spend much
time on it.

Is there any real documentation as to how it works? I was a little
frustrated that I couldn't find good information within a couple of
hours, other than a long and speculative whitepaper, and the source
code of course.

I am naturally concerned about developing a product that intends to
directly challenge exploiters, instead of not even letting them on the
playing field.

Also I love the end of the paper that aligns NaCl as similar to
ActiveX. Basically it said that Microsoft couldn't do it, but we can!

[moodz]

... too much focus on security in such a new project.
... on sandbox security .. this is no more a task than that
implemented in virtualisation
which has been happening at the enterprise level for some years now
( in X86 and others ).