Sandbox NPAPI

Leonard Rosenthol lrosenth at adobe.com
Tue Feb 1 22:14:08 PST 2011


So let's take a very common case of something that users do with Adobe Reader - Printing.

How would you envision enabling printing from a plugin in your sandbox?  Let's even take platform-neutrality out of the picture...how would you imagine that working on Mac OS X?   Let's walk through it a bit...(and I may miss something in the following example, but it should be instructive enough)

First, the user needs to see the print dialog.  Who brings that up - browser or plugin?  If the plugin, then you now have all the driver code executing in the sandbox - probably not good.  If the browser does it, then any plug-in-specific extensions (and we have some) need to someone run outside the sandbox...but that's what you're trying to avoid in the first place.

But somehow we get past that issue and the user has decided that they want to print by clicking OK.  Now what?

Well, in our case, we need to know what type of printer is involved and its capabilities. Do we print Postscript, raster or other?   And how do we send those different formats?  We certainly can't send the PDF into CUPS, since the cgpdf filters don't support the full ISO 32000-1 standard and it would be wrong if what the user saw on screen didn't match the print out.  


Hopefully this gives you some indication of why I think you are tilting at windmills on this one...

Leonard

-----Original Message-----
From: plugin-futures-bounces at mozilla.org [mailto:plugin-futures-bounces at mozilla.org] On Behalf Of Ivan Krstic
Sent: Tuesday, February 01, 2011 8:19 PM
To: Adam Barth
Cc: Maciej Stachowiak; plugin-futures at mozilla.org
Subject: Re: Sandbox NPAPI

On Feb 1, 2011, at 4:10 PM, Adam Barth wrote:
> 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.

This works because the DOM is a synthetic, cross-platform construct. The question is how to carry that approach over to OS primitives which are not. I think it would be quite hard for the API itself to keep exhaustive lists of what's available inside the sandbox on every possible platform. 

I think it's better to codify what we can (files), express the intention of the API in terms of what we can codify (don't steal, corrupt or delete files), and have platform experts from different browsers agree on how that API intention translates to specific restrictions on their platform.

Given that the API explicitly states that resources acquired before entering the sandbox will remain available once in it, I think plugin authors will rarely find themselves in a really hard spot because of evolving restrictions. We can certainly make the language around expectations firmer to stress that after entering the sandbox, plugins should not rely on being able to acquire any OS resources that directly affect other processes or the rest of the machine, and list some canonical examples for the different platforms.

> In any case, I certainly don't want to derail this effort.

You're not derailing anything; these are useful comments.

Cheers,
Ivan.

_______________________________________________
plugin-futures mailing list
plugin-futures at mozilla.org
https://mail.mozilla.org/listinfo/plugin-futures


More information about the plugin-futures mailing list