- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 25 Jan 2010 04:45:55 +0000
- To: Leonard Rosenthol <lrosenth@adobe.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
The problem with that approach is that authors will have a difficult time predicting how user agents will behave. Perhaps a more operational definition is in order? We could say that sandboxed content will not be able to use the <object> or <embed> elements (including the implied versions that can be created via frames). Adam On Sun, Jan 24, 2010 at 11:03 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote: > BUT a browser/UA is allowed to instantiate AY content that it believes complies with the provided security model, correct? > > So Safari, if it believes that their built-in PDF support is "sandbox safe" could display such document on the Mac even though on Windows the same browser would not do so. OR for that matter, what about a UA which relies on a plugin for SVG? Are they to not allow embedded SVG in a sandbox simply because they have to use a plugin to implement it? > > My point isn't to try to avoid the sandbox - I fully support the idea. HOWEVER, I believe that "plugins" are being singled out inappropriately and that the correct solution is a more well thought out definition of what exactly we are trying to achieve. > > Leonard > > > -----Original Message----- > From: Adam Barth [mailto:w3c@adambarth.com] > Sent: Sunday, January 24, 2010 10:56 PM > To: Leonard Rosenthol > Cc: Maciej Stachowiak; public-html@w3.org > Subject: Re: What defines a "plugin"? WRT sandboxing? > > The fact remains that we cannot permit sandboxed content to > instantiate plugins that do not understand the sandbox security model. > If we allowed that, then the sandboxed content could use those > plugins to circumvent the sandbox, rendering the feature useless. > > Adam > > > On Sun, Jan 24, 2010 at 6:12 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote: >> If I understand what you are saying, then it also means that your internal >> support for ANY format - whether it be specifically listed in the HTML5 spec >> or not AND whether it is implemented via plugin or not - would need to be >> covered by the sandbox rules. That seems completely valid and logical (and >> consistent). >> >> >> >> In that case, I would argue that plugins NOT EVEN BE MENTIONED in the >> sandbox specification - and that instead, the general rules for sandboxing >> (scripting, external refs, etc.) be applied to the content regardless of how >> that content is displayed. >> >> >> >> So in Safari's case, if someone references QuickTime and they are allowing >> external references, then it would be OK for you to use it. OR if your PDF >> viewer DID support scripting AND the sandbox rule was allow scripting, then >> it would be OK for you to view it, otherwise it would not. >> >> >> >> The rule for plugins then simply become whether the UA can establish whether >> the plugin is able to adhere to the requirement(s) for that sandbox. If it >> can, then it runs - if it cannot, then it can't. BUT explicit disabling of >> plugins should not be an option! >> >> >> >> Leonard >> >> >> >> From: Maciej Stachowiak [mailto:mjs@apple.com] >> Sent: Sunday, January 24, 2010 6:03 PM >> To: Leonard Rosenthol >> Cc: public-html@w3.org >> Subject: Re: What defines a "plugin"? WRT sandboxing? >> >> >> >> >> >> On Jan 24, 2010, at 5:44 AM, Leonard Rosenthol wrote: >> >> When defining and implementing sandboxing, is the requirement to disable >> plugins restricted ONLY to actual technologies implemented by plugins to the >> browser/UA _OR_ does it really mean content not in a format documented by >> the HTML5 spec. >> >> >> >> For example, Safari (on the Mac) knows how to natively view PDF documents. >> If Safari encounters an HTML document with a reference to an embedded PDF >> (<object> or <embed>) it will currently render that document through its own >> technology, whereas other browsers will use available plugins to do so. >> When that same HTML is now served as sandbox, then clearly the other >> browsers will stop viewing PDF - but should Safari? >> >> >> >> OR consider Adobe AIR which (through WebKit) can act as an HTML5 UA and >> incorporates native support for Flash. Does it have to disable Flash, since >> it isn't using sandbox? >> >> >> >> For data types where Safari has built-in support, we'd likely turn off any >> that are able to do scripting or that may fetch additional resources over >> the network, unless we know how to apply the sandbox rules to that content. >> So PDF would be ok, because our built-in PDF doesn't do scripting. As would >> our built-in audio and video support via media elements. We would allow SVG >> and HTML because it's straightforward to make them follow the sandbox rules. >> But we would not allow Java (which is actually implemented partly as a >> plugin and partly via built-in code, but that's not super relevant). It runs >> code, and that's sort of intrinsic to its function. We would now allow the >> QuickTime plugin, even if it were built-in, because it fetches remote >> resources. >> >> >> >> I think the bottom line is for any given piece of code, can you verify that >> it enforces the sandbox constraints? >> >> >> >> Regards, >> >> Maciej >> >> >
Received on Monday, 25 January 2010 04:46:47 UTC