ike at apple.com
Tue Feb 1 20:18:33 PST 2011
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
> 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.
More information about the plugin-futures