Sandbox NPAPI

Leonard Rosenthol lrosenth at
Tue Feb 1 18:22:58 PST 2011

> I'm fundamentally not sure that a general sandbox facility will be particularly configurable across platforms
I guess I am not sure what you are trying to accomplish here then...

I've always been under the impression that the actual "sandboxing of the plugin" (eg. Ensuring that it only does what it is supposed to do) is up to the plugin author - the browser has to "take it at its word" that when it says that it supports the request to run in a "sandboxed frame" that it will do so properly.

In that regard, the browser needs to inform the plugin as part of the initialization phase that this particular instance is running in a sandbox and here are the restrictions (no-script, etc.)  And that's it.  After that, life/APIs continues on as before.   The plugin will simply adjust its behavior (as does the browser itself!) for that particular content.

Why is more than that needed?!?!


-----Original Message-----
From: plugin-futures-bounces at [mailto:plugin-futures-bounces at] On Behalf Of Ivan Krstic
Sent: Tuesday, February 01, 2011 3:31 PM
To: Adam Barth
Cc: plugin-futures at
Subject: Re: Sandbox NPAPI

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.


plugin-futures mailing list
plugin-futures at

More information about the plugin-futures mailing list