mjs at apple.com
Wed Feb 2 14:34:55 PST 2011
On Feb 2, 2011, at 5:55 AM, Leonard Rosenthol wrote:
>> 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.
> Hopefully the OS vendor for Mac OS X will recognize the need to provide OS-level APIs for sandboxing and provide them in a future version of their OS. Until then, we would do whatever we had to for our customers.
>> 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
> But as mentioned by Brett - file system access is such a small thing compared to all the other resources that the common plugins in use today require. Consider QuickTime, if you want something simpler than Reader. From what I remember of QT (and it's been a LONG TIME) - you need access to files, you need access to the network, you need access to sound hardware, and you need access to the GPU (and possibly other things). So how do you envision these other items being handled?
>> 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.
> So the OS vendor should provide the necessary APIs for plugin vendors to use and then they can be leveraged.
Exposing the low-level sandboxing mechanism to plugins would not help. The plugin can't assume it is ok to put the process embedding it in an arbitrary sandbox. That's why NPAPI is needed to enter the sandbox.
More information about the plugin-futures