RE: text/sandboxed-html

Exactly, Eduardo!  Thanks,


From: [] On Behalf Of
Sent: Tuesday, January 26, 2010 9:37 PM
To: Devdatta
Cc: Maciej Stachowiak; Collin Jackson; Helen Wang (MSR);
Subject: Re: text/sandboxed-html

a <script src=> inside an <iframe sandbox=> is the same as a <sandbox src=>, the difference is that the later is only javascript, and the former is JS and HTML (and css maybe).

If I understood correctly, Helen things that HTML is dangerous, since it executes in the context of the page serving it, while JS by itself is not..

-- Eduardo

On Wed, Jan 27, 2010 at 12:55 PM, Devdatta <<>> wrote:
Hi Helen,

It seems to me that your proposal and the HTML5 proposal are solving
different problems.  This proposal talks about how to serve scripts
with null privileges while the HTML5 proposal is how to serve HTTP
resources (a.k.a HTML documents) with null privileges.

Am I correct in thinking that whatever a script with null privileges
can achieve, an iframe sandbox can also achieve ? In particular, what
are the usecases that are covered by serving untrusted scripts but
aren't covered by serving untrusted resources ?

2010/1/26 Maciej Stachowiak <<>>:
> On Jan 26, 2010, at 2:44 PM, Collin Jackson wrote:
>> Since there is no mechanism preventing the attacker from making an
>> iframe that points at the <sandbox>'s "src" attribute, the site needs
>> some way of preventing the content from rendering as HTML, even though
>> it will normally be script in non-attack scenarios. Serving up content
>> with the mime type text/javascript (or application/x-javascript) works
>> about as well as text/html-sandboxed (same IE6 and Flash caveats).
> Using a JavaScript type is likely to make some or all of the content readable (and not just embeddable) cross-site. So even though it won't then be rendered as HTML, this choice of MIME type has risks.
> Regards,
> Maciej

Received on Wednesday, 27 January 2010 15:24:25 UTC