W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: text/sandboxed-html

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 13 Jan 2010 08:31:03 -0800
Cc: Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
Message-id: <9986F5C6-51E4-4887-89B5-96C81AB80185@apple.com>
To: Leonard Rosenthol <lrosenth@adobe.com>

-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.


> 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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:56 UTC