Sandbox NPAPI

Ivan Krstić ike at
Tue Feb 1 15:30:30 PST 2011

On Dec 24, 2010, at 10:43 AM, Adam Barth wrote:
> Here are some comments on the substance:


> Another approach might be to pass a struct that we can later extend if
> we change our minds about how strong the sandbox should be and what
> sorts of holes we're willing to poke in the sandbox in the future
> (forgive my lack of knowledge about NP API style):
> NPError NP_LOADDS NPN_EnterSandbox(NPP instance,
>                                   NPSandboxPolicy* policy);
> If you don't like binary-extensible structs, you could imagine passing
> in a policy as a string, e.g., like the way you can configure the Mac
> sandbox.

I'm fundamentally not sure that a general sandbox facility will be particularly configurable across platforms. Per my other answer in the thread, files are among the few sets of primitives which can be reasonably characterized across OSes. Processes, at least in terms of their creation, may be another. But after that, it's at least my experience that we run into deep platform-specific morasses. HWNDs have no meaning on Mac OS X, and Mach ports mean nothing on Windows.

What's a plugin author to do? If we force them to understand the full set of sandbox primitives on every platform they run on in order to ship with platform-specific NPN_EnterSandbox() policies, I think we'll get no traction at all for this API.

> Perhaps it would make sense to deliver the NPFileHandle
> asynchronously?

Yes, that would be a fine change.

> Another thing to consider is how this API relates to the W3C work on
> File and FileSystem.  Of course, there's no reason that NPAPI needs to
> match the rest of the web platform identically, but one approach to
> reducing complexity and improving security is to leverage the work
> folks have put into designing and analyzing those APIs.  For example,
> FileSystem has a security policy surrounding the sorts of file names
> that you can read and write from.  I didn't see anything about that in
> this proposal, which makes me wonder if this API is vulnerable to the
> same attacks that are mitigated by that policy.'

I'll have to take a deeper look at File and FileSystem.


More information about the plugin-futures mailing list