[whatwg] Sandboxing to accommodate user generated content.
frode at seria.no
Tue Jun 17 15:58:30 PDT 2008
2008/6/17 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> This particular explanation is irrelevant to the topic because sandboxed
> fragments can contain scripts, whether within CSS or not. The idea of
> sandboxing is to disable scripts, not to purge them.
You asked me to comment on your questions. It's obvious (when you read
the discussion) that the point of sandboxing is to disable scripts.
But to establish that we need sandbox, I wanted to show how difficult
it is to sanitize html - and also that it can't be done in a future
proof manner from the server side.
Preventing users from inserting scripts, and at the same time allowing
user submitted html is extremely difficult to do on the server side -
ergo we must have sandboxing.
Method with iframe and content attribute:
1. Makes it very impractical to use sandboxing on short texts - such
as an article title.
2. Impossible to have user generated content inside a <select>.
words inside the text on the server side.
4. Graceful degradation requires two separate domain names. One for
user generated content, and another for the website itself.
5. Graceful degradation requires significant programming effort on the
server side. First of all, the user must be authenticated on both
domain names - and each page that should display user generated
content must have separate scripts to create the iframe content.
Method with <sandbox> tag, or sandbox='on' attribute:
1. Easy to use sandboxing on short texts. PHP example: <?php echo
2. Easy to sandbox a select box.
echo "<sandbox>".htmlspecialchars("User ")."</sandbox><span
4. Graceful degradation is automatic. User inserted scripts and is
entity escaped, and will never execute in any browser.
5. See point 4.
More information about the whatwg