- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 13 Jan 2010 08:31:03 -0800
- To: Leonard Rosenthol <lrosenth@adobe.com>
- Cc: Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
-public-web-security (since it's not relevant to the thread any more) On Jan 13, 2010, at 8:14 AM, Leonard Rosenthol wrote: > Hadn't read that, thanks for the pointer! Agreed, as long as > plugins are explicitly disabled in a sandboxed page, then there is > no need to extend any relevant APIs. That said, since the author of > the page is the one determining the context (as per your black/white > list comment), I would think they may wish to enable content that is > plugin based but "trusted" to run in sandbox mode. So the addition > of an "allow-plugins" keyword to the list of keywords for sandbox > mode seems like a logical and reasonable extension. Do I need to > file a formal "bug report" to see this included? If you'd like to have your idea get consideration, then yes, an appropriate first step would be to file a bug in W3C bugzilla. My own opinion is that it would be premature to add allow-plugins until we have worked out how plugins might participate in enforcing the sandboxed iframe restrictions. I think maybe plugin-futures would be the right forum to work out an API. > > Also, from what I can see about disabling of scripting, that applies > to ALL scripts run in the context of the page. This would include > use the Canvas/2D API, the proposed 3D APIs, SVG-embedded DOM > manipulation, etc. Correct? That is correct, no scripting at all would work, though you can opt back into scripting with allow-scripting. Regards, Maciej > > Leonard > > -----Original Message----- > From: Maciej Stachowiak [mailto:mjs@apple.com] > Sent: Wednesday, January 13, 2010 10:57 AM > To: Leonard Rosenthol > Cc: 'Ian Hickson'; public-html@w3.org; public-web-security@w3.org > Subject: Re: text/sandboxed-html > > > On Jan 13, 2010, at 6:38 AM, Leonard Rosenthol wrote: > >> How would this work for content that references resources that >> require the use of a plugin to view? >> >> How would a UA know if the specific plugin can run sandboxed or >> not? How would the UA communicate to the plugin that is should be >> running sandboxed? > > At present, content running in a sandboxed iframe cannot use plugins > at all. See the sandboxed plugins browsing flag: <http://dev.w3.org/html5/spec/Overview.html#attr-iframe-sandbox >> . > > You are correct that without changes to the plugin API to allow > plugins to participate in the sandbox security model, there would be > no safe way to allow plugins. If we come up with such a mechanism for > popular plugin APIs, then we could consider whether to have an allow- > plugins keyword for the sandbox attribute in addition to the existing > ones like allow-forms, allow-scripting and allow-same-origin. I think > it would only make sense to respect allow-plugins if allow-scripting > is on, and to only let it enable plugins that know how to enforce the > sandbox restrictions against their embedded plugin content. > >> I would think that these problems would need to be addressed >> otherwise the usefulness of "sandboxed" is significantly reduced >> since it wouldn't actually mean anything in such contexts. > > Right now its usefulness is only restricted in that you can't use > plugins in a sandboxed context. However, we expect the main use cases > for sandboxed iframes to be cases where site authors are already using > blacklists or whitelists to filter out plugin content. > > Regards, > Maciej > > >> >> Leonard Rosenthol >> Adobe Systems >> >> -----Original Message----- >> From: public-html-request@w3.org [mailto:public-html-request@w3.org] >> On Behalf Of Ian Hickson >> Sent: Tuesday, January 12, 2010 8:52 PM >> To: public-html@w3.org >> Cc: public-web-security@w3.org >> Subject: text/sandboxed-html >> >> >> In response to implementor feedback regarding the sandbox="" feature >> of >> <iframe> in the WHATWG list [1], and based in part on a 2007 research >> paper from Microsoft [2], I have introduced a new MIME type for HTML >> (text/sandboxed-html) that is identical to text/html in every way >> except >> one critical aspect: resources served with this MIME type are forced >> into >> a unique security origin context. >> >> This feature can also be used with <iframe sandbox=""> to force the >> desired behaviour in legacy UAs -- fallback to either no sandbox is >> possible as before (for the case where sandbox="" is being used for >> defence-in-depth), and fallback to load failure is now possible by >> serving >> the content with this type (for the case where legacy UAs are not >> intended >> to be supported and sandbox="" is being used for first-line >> security). >> >> This is somewhat experimental, and so feedback (especially >> implementor >> feedback) regarding this proposal is encouraged. >> >> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024732.html >> [2] http://research.microsoft.com/en-us/um/people/helenw/papers/sosp07MashupOS.pdf >> >> -- >> Ian Hickson U+1047E ) >> \._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _ >> \ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'-- >> (,_..'`-.;.' >> >> > >
Received on Wednesday, 13 January 2010 16:31:37 UTC