W3C home > Mailing lists > Public > public-html@w3.org > October 2010

Re: Working Group Decision on ISSUE-100 srcdoc

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 14 Oct 2010 09:34:15 -0700
Message-ID: <AANLkTimE3=6rD1Yy7BuL=yjn=X5VRLT+YHmrkp9ENS6Z@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Andrew Fedoniouk <news@terrainformatica.com>, HTML WG <public-html@w3.org>
On Thu, Oct 14, 2010 at 9:30 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 14.10.2010 18:23, Tab Atkins Jr. wrote:
>> ...
>> No, it does not.  This has exactly the same issues as the most naive
>> solution to the problem, a<sandbox>  element.  Namely, the content you
>> include inside the script can have an unmatched</script>, breaking it
>> out of the sandbox and letting anything that follows be treated as
>> part of the normal page.  Arbitrary XSS follows in the obvious way.
>> The discussion surrounding this issue went over this in depth, and my
>> Change Proposal quickly summarized the issues around it and several
>> similar solutions.  I suggest reading my Change Proposal first before
>> making further suggestions, as it is very likely that your idea has
>> already been discussed and found wanting.  This is a hard area where
>> the solutions are pulled in several different directions.
>> ...
> Well.
> Putting the user-supplied text into @srcdoc requires escaping. Putting it
> into an element requires escaping as well, but once you understand you need
> to escape, where's the big difference?

Again, this was discussed in depth on the mailing list, and was
summarized in my change proposal.

I could re-list the reasons why @srcdoc has better behavior than an
element, if necessary, but if you look either at the archives or my
Change Proposal it should be clear.  Do you need me to, though?

Received on Thursday, 14 October 2010 16:35:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:05 UTC