Re: <iframe doc="">

On Mon, Jan 25, 2010 at 10:24 AM, Kornel <kornel@geekhood.net> wrote:

> On 25 Jan 2010, at 15:28, Shelley Powers wrote:
>
>  I'm not being disingenuous. And I ask you to remember to be civil in
>> responding to me. I also ask that you stop dictating how and in what way I
>> can bring up concerns.
>>
>
> The concerns you brought[1] were mostly issues unrelated/orthogonal to
> @srcdoc, and some appeared to be strawman arguments (it should be obvious to
> members of this group that HTML is unable to effectively prevent spam or
> server-side SQL injection).
>
>
>  So I am trying to understand the purpose of this change, and who Ian
>> perceives to be the customer for this change. These are appropriate
>> questions to ask: we can not determine the technical merit of a solution
>> unless we have an understanding of all the particulars.
>>
>
> To understand this you must first understand relationship between @srcdoc
> with @sandbox. You seem to be debating merit of @sandbox, but insisting that
> it is issue of @srcdoc.
>
> Sandbox for comments and ads might still be implemented without @srcdoc,
> for example with src="data:text/html-sandboxed,…" or external file with
> appropriate MIME type. Do you oppose inclusion of markup in @srcdoc
> attribute (which is one of the options, mainly for authors' convenience), or
> any use of <iframe> for sandboxing of content?
>
>
>  Adam now has stated this change wasn't to do with comments, but ads. Or
>> not only to do with comments, but also to do with ads. That is an entirely
>> different thing: different customers, different uses, different concerns,
>> different technical challenges.
>>
>
> This is not entirely different thing. Both are examples of untrusted markup
> that would be useful to include inline in the page, without risk of XSS and
> need for very complicated sanitisation.
>
>
Sorry, will finish email. GMail is being a real problem today, so I'm trying
to do shorter emails.

What I demonstrated is that there is a reason the sanitation tools are
complex: because they are tools used by a host of different customers, who
have used these tools over the years, and generated new and more complex
needs for these tools during that time.

Complexity of these tools was driven by customer need.
And they have proven over time that they are capable of meeting these
needs, and adaptable to new challenges,
because they are focused on a specific task: security of input. If the
primary use case is weblog comments, that is.

Shelley




> --
> regards, Kornel
>
> [1] http://lists.w3.org/Archives/Public/public-html/2010Jan/1276.html