[whatwg] innerStaticHTML

On Wed, May 6, 2009 at 9:40 AM, Jo?o Eiras <joaoe at opera.com> wrote:
> 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.

Yes, we can't make it impossible for web developers to shoot
themselves in the foot.  We also can't stop them from calling eval on
a query string argument.  However, innerStaticHTML does make it easier
to display untrusted HTML to the user.

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

This is what I meant to suggest.

> That would mean removing all onevent attributes, all scripts elements, all plugins, etc. Basically, letting the UA implement all the filtering.

Exactly.  As you say, the UA is in a much better position to do this
correctly than an individual web site.

On Thu, May 7, 2009 at 3:24 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> If toStaticHTML prunes everything it is not sure of, the danger of a known
> language construct suddenly introducing active content is negligible.  I am
> sure HTML5 specification editors bear that aspect in mind and so shall they
> in the future.

Even if you believe that we've already committed to not introducing
active content that breaks toStaticHTML (which I'm not convinced we
have, especially because I don't know what algorithm it uses), that
still leaves the performance and correctness issues of parsing the
untrusted content twice.  Parsing the content once is more efficient
and more predictable.

Adam

Received on Monday, 11 May 2009 09:16:23 UTC