Sandbox NPAPI

Adam Barth abarth-mozilla at
Tue Feb 1 16:10:52 PST 2011

On Tue, Feb 1, 2011 at 3:20 PM, Ivan Krstić <ike at> wrote:
> On Jan 20, 2011, at 11:10 PM, Adam Barth wrote:
>> Does the QuickTime plugin use other operating system concepts besides
>> files, for example HWNDs or hardware video decoding?  I guess the main
>> thing I don't understand about this proposal is how the plug-in is
>> allowed to interact with the operating system once it enables the
>> sandbox (e.g., for OS resources other than files).
> These are good questions. I haven't found a way to reconcile the differences between different OS architectures — and their sandbox primitives — to the point where the API could give a precise answer to what the plugin is allowed to do after entering the Sandbox.
> As a result, the approach I've taken is to work backwards from the things I'm trying to protect. My strongest concern is protecting access to the user's files, which incidentally lend themselves reasonably well to having their behavior characterized across platforms. That's why the API deals with files explicitly, while leaving the remaining restrictions up to the implementors under the "implementations may additionally choose to restrict..." clause. I know what the set of restrictions would need to look like on Mac OS X, and presumably folks working on other platforms would know what their OS has to restrict so as to make it impossible for plugins to steal, corrupt or delete the user's files without authorization.
> If you have ideas on how to make the API more unambiguous about its protection model remaining applicable to different platforms, I'd love to hear them.

One difficulty with that approach is that it make for a rigid
platform.  What if we forget to sandbox some important thing in the
first version?  We won't be able to remove it later because we'll
break plugins that use enable the sandbox and use that feature.

An alternative approach is a whitelisting approach where we enumerate
the set of features that are visible inside the sandbox.  That's
essentially the approach we use in the rest of the web platform.  For
example, HTML and JavaScript can access only those things that we
explicitly make available via the DOM.

In any case, I certainly don't want to derail this effort.  Having a
sandbox available for plug-ins is certainly valuable.  I'm just
suggesting that you might want to consider how this API will evolve in
the future to protect more than just files.


More information about the plugin-futures mailing list