abarth-mozilla at adambarth.com
Tue Feb 1 20:50:13 PST 2011
On Tue, Feb 1, 2011 at 8:18 PM, Ivan Krstić <ike at apple.com> wrote:
> 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.
In some sense, that's what PPAPI is trying to achieve, but I
understand that's a different technology path.
> 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.
Maybe a reasonable adjustment would be to use a versioned struct as a
parameter instead of a fixed set of parameters? That way we could add
more things to the end of the struct in the future.
> 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.
As an example, are fonts available after enabling the sandbox? In
some sense, using fonts implies the ability to read files. In the
Chrome sandbox, for example, we have to jump through some pretty
ridiculous hoops to let the renderer access fonts. It's easily
something we could get wrong in the first iteration and then worry if
we're going to break folks by fixing.
More information about the plugin-futures