lrosenth at adobe.com
Wed Feb 2 17:58:31 PST 2011
If a plugin is going to have to write a broker for everything else anyway, why special case the file operations? If I have to write a broker, then I am broker my own file calls since I have more control over them and a common implementation for brokering OS APIs. Otherwise, I have to do completely differently, and that doesn't seem productive to implementation and testing.
So I would favor removing the file system "callbacks" and keeping it pretty simple...
From: plugin-futures-bounces at mozilla.org [mailto:plugin-futures-bounces at mozilla.org] On Behalf Of Maciej Stachowiak
Sent: Wednesday, February 02, 2011 2:34 PM
To: Brett Wilson
Cc: Darin Adler; plugin-futures at mozilla.org
Subject: Re: Sandbox NPAPI
On Feb 1, 2011, at 10:32 PM, Brett Wilson wrote:
> My apologies, I've been barely paying attention to this thread when I
> noticed this.
> I'm actually kind of confused about what you say here. You're
> proposing a way to sandbox plugins which is great. But now you're
> discarding 99.999% of those installs as being "complex" and not
> covered by your proposal (Flash, Reader, Real, QuickTime, Java seem
> like they all do various things like printing or want graphics
> acceleration, etc). What is an example of one of the "vast majority of
> simpler plugins"? Do you imagine NPAPI will be a popular platform for
> people writing new plugins that we've not already seen? As one of the
> very few people who has written a test NPAPI plugin, I would suggest
> that's unlikely.
I think you're misunderstanding what Ivan is saying. The API proposal *is* sufficient to cover all of the plugins you mention. However, they'll have to use their own means to perform privileged operations, either by acquiring necessary resources before entering the sandbox, or by launching a "broker" process and setting up an IPC pipe to it before entering the sandbox.
What Ivan is saying is, for the subset of plugins where file access is the primary privileged operation they need, the special provisions in the API for files provide for that without the need to specially pre-acquire resources or use a broker.
My understanding is that this is very similar to Google and Adobe's work on sandboxed Flash for Chrome - the plugin enters a sandbox and uses a broker for privileged operations.
The key differences are:
(A) We don't provide an API to get the browser to launch a privilege broker process and manage IPC to it, since it seems like this is something the plugin can do for itself (and it's very hard to make a portable API that provides all the IPC facilities that might be needed).
(B) We provide direct provisions for filesystem access, since we think this will be a common need.
We'd like to refine this API and get it going. We think it's critical to have a cross-browser solution for plugin sandboxing, and soon. If it would help, we can implement the proposal in Safari and port a plugin to it, before coming back for further discussion. Hopefully that will reduce the skepticism over whether this approach is workable. We hoped to get rough consensus before proceeding with implementation, but it seems like this may create a chicken-and-egg problem.
plugin-futures mailing list
plugin-futures at mozilla.org
More information about the plugin-futures