ike at apple.com
Tue Feb 1 22:15:31 PST 2011
On Feb 1, 2011, at 9:58 PM, Leonard Rosenthol wrote:
> And this can be done either by the browser running the plugin in some form of sandbox (ala Chrome) _OR_ the plugin itself having its own sandbox (ala Adobe Reader). In the latter case, there is no need for any special API to see this happen (as demonstrated by Reader X today on Windows).
I think we're speaking past each other. If Reader X needed to also run sandboxed on the Mac, how would it implement that sandbox? Mac OS X doesn't expose the requisite sandbox primitives as API. You could use private OS X interfaces like Chrome, but those could change or disappear entirely without any prior notice.
The sole purpose of this API proposal is to provide a cross-platform way of entering a sandbox defined narrowly in terms of filesystem access. This gets plugin writers — at least those who don't need more complex sandbox facilities — out of the business of implementing and maintaining different sandbox implementations for every platform on which they run (tokens pre-Vista, tokens and integrity levels post-Vista, private interfaces on OS X, and so on).
> In the former case, I am not sure I see what API you need either
You need the API to say "I want the OS to restrict my access to resources". On Windows, that API is there today, but the usage complexity is high enough that almost no one has taken on the implementation burden. Chrome and Reader X are among the very few widely-used exceptions; not relying on the OS for sandbox enforcement comes with its own pitfalls (e.g. <http://j.mp/fR0WYZ>).
> SO, that puts you back to #2 - not doing anything in the API and letting it happen at the plugin level.
Plugins are complex and have vulnerabilities. It's not enough for the plugin to want to protect itself from the data it operates on. The OS must also be protected from the plugin.
> Lovely idea, but since you can't control the OS-level APIs that are used by any arbitrary plugin (unless it's a special environment like NaCl), then I simply don't see how you can accomplish this. And I say this based on the number of APIs that we've had to broker on Windows for Reader.
Complex plugins are not the intended consumers of this API. We're targeting what we believe are the vast majority of simpler plugins that have more modest needs.
More information about the plugin-futures