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

Re: <iframe doc="">

From: Kornel Lesinski <kornel@geekhood.net>
Date: Mon, 25 Jan 2010 20:24:53 -0000
To: "Shelley Powers" <shelley.just@gmail.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.u63uzrx5ptj49s@aimac.local>
On Mon, 25 Jan 2010 16:34:08 -0000, Shelley Powers  
<shelley.just@gmail.com> wrote:

>> 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).
>>
> No, I brought up the stated use case, and then highlighted the state of  
> art that exists today related to that specific use case: comment  
> security.

@sandbox is not solving broadly-defined "comment security". It is only  
meant to solve a specific narrowly-defined problem: (technically) safe  
inclusion of untrusted HTML markup (which may be useful for comments, ads,  
widgets, feed readers, and other mashups).

Problems you've brought are not directly related to XSS/CSRF/clickjacking  
that @sandbox is trying to prevent, they're only related to comments.  
Blocking of spam and shock images is desirable, but it's outside scope of  
@sandbox.

Solutions to problems you've mentioned are also technically very different  
than HTML sanitisation. SQL injection can be completely prevented with  
simple escaping which is trivial to implement. HTML sanitisation (not  
escaping) is *much* more difficult to implement properly.
Spam is inexact science and it's a problem that hasn't been completely  
solved yet. HTML sanitisation is complex, but well-defined solvable  
problem.

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

Yes, tools for sanitisation are complex, and HTML is no exception. There  
are tools for server-side HTML sanitisation, which only prove how  
difficult it is (e.g. even "lite" version of HTML Purifier contains 800KB  
of code. Filter in WordPress is smaller, but at cost of allowing only tiny  
subset of HTML).

And this complexity is exactly why authors would benefit from easy to use,  
well-implemented sanitisation available in browsers. And with sandbox, use  
of @srcdoc avoids pitfall of relying on special MIME type, which we know  
authors have problem setting correctly.

-- 
regards, Kornel Lesinski
Received on Monday, 25 January 2010 20:25:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT