On Wed, May 6, 2009 at 9:40 AM, João Eiras <[email protected]> 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 <[email protected]> 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
