W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2008

[whatwg] Sandboxing to accommodate user generated content.

From: Kristof Zelechovski <giecrilj@stegny.2a.pl>
Date: Wed, 18 Jun 2008 02:25:24 +0200
Message-ID: <5878E066906442129D6DB70B7A7D4048@POCZTOWIEC>
What is the use case for having user-submitted content inside a SELECT
element?  A SELECT element is for the user to choose, not to insert
arbitrary new values (especially because the correspondence between values
and labels is known only to the server).
The argument about scripts attached to words is interesting; what is the use
case?  How do you make these attachments remain active in the user agent?
Chris

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Wednesday, June 18, 2008 12:59 AM
To: Kristof Zelechovski
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

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.

Fact:
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>.
3. Makes it impossible to attach custom javascript functionality on
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
"<sandbox>".htmlspecialchars($title)."</sandbox>"; ?>
2. Easy to sandbox a select box.
3. Easy to attach custom javascript functionality: PHP example: <?php
echo "<sandbox>".htmlspecialchars("User ")."</sandbox><span
onclick='something'>generated</span><sandbox>".htmlspecialchars("content");
?>
4. Graceful degradation is automatic. User inserted scripts and is
entity escaped, and will never execute in any browser.
5. See point 4.

Frode
Received on Tuesday, 17 June 2008 17:25:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:03 UTC