W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] innerStaticHTML

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 7 May 2009 09:25:51 -0500
Message-ID: <dd0fbad0905070725v37b4754dgbbf76d2f51d759fb@mail.gmail.com>
On Wed, May 6, 2009 at 4:01 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Wed, May 6, 2009 at 9:40 AM, Jo?o Eiras <joaoe at opera.com> wrote:
>>
>> As part of a browser implementation team I can clearly say that the cases
>> where scripts should, or should not run are very hard to implement in a
>> cross browser compatible way. Marking those scripts or plugins are
>> non-executable would make everything much more complex and bug prone. Also,
>> it would be impossible to do that for a onevent attribute without all sorts
>> of problems.
>> The suggestion of marking content as non-executable doesn't solve
>> anything, because after setting innerStaticHTML another script might
>> serialize a piece of the affected DOM to string and back to a tree, and the
>> code could then execute, which would not be wanted.
>>
>> The only viable solution, from my point of view, would be for the UA to
>> parse the string, and remove all untrusted content from the result tree
>> before appending to the document.
>> That would mean removing all onevent attributes, all scripts elements, all
>> plugins, etc. Basically, letting the UA implement all the filtering.
>
>
> I think that's actually what Adam is proposing. At least, it's what I had in
> mind when we discussed it.

I'm in favor of this.  Browser-specified sanitizing, woo!

Obviously this doesn't replace the need for sandbox iframes (those are
still necessary for building a page using external html without
javascript), but it's a much easier solution for pretty much any
js-based sandbox-iframe situation.

~TJ
Received on Thursday, 7 May 2009 07:25:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:48 UTC