[whatwg] Sandboxing ideas

Gervase Markham gerv at mozilla.org
Thu May 10 06:09:03 PDT 2007

Ian Hickson wrote:
> Now we could exand that 
> by putting, e.g., a hash into the <sandbox> element's attributes:
>    <body>
>     <p>Hello, you said:
>      <sandbox md5="e59ff97941044f85df5297e1c302d260">Hello World</sandbox>
>     </p>
>    </body>
> ...but that doesn't actually help us determine where the end should be. 

If attributes on closing tags were allowed, you could do:

<sandbox secret="09f9...">Hello World</sandbox secret="09F9...">

In other words, make them match. So any inserted </sandbox> tags 
wouldn't close the sandbox unless they knew the secret - which they 
couldn't do, because they have the chicken-and-egg problem of having to 
be able to read the page first.

> In fact I cannot see _any_ solution to the problem of allowing safe and 
> server-side-free inclusion of arbitrary text in the body of an HTML page 
> that doesn't have obvious attacks or limitations.

Other than the above, neither can I.

> The sanest way I can see of limiting scripting is to give it its own 
> browsing context (aka scripting context, or global scope). Anything short 
> of this would make the security model overly complicated -- the security 
> model is what we want to keep at its simplest, as I've said several times 
> in this e-mail.

I agree 100%.

> This basically implies an <iframe>, again possibly with the data in a 
> data: URI, and combined with a way to ioslate the content in the <iframe> 
> from the content of the parent browsing context:

http://www.gerv.net/security/content-restrictions/ , specifically the 
"hierarchy" restriction, allows the <iframe> content to be isolated from 
the parent.

You also need <iframe>s which resize to content; that's

IE has the proprietary "security" attribute on <iframe> which restricts 
script in various ways:


More information about the whatwg mailing list