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