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

Re: <iframe doc="">

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 25 Jan 2010 09:54:14 -0600
Message-ID: <dd0fbad1001250754k48172f36l1c66958c4709a673@mail.gmail.com>
To: Shelley Powers <shelley.just@gmail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Lars Gunther <gunther@keryx.se>, "public-html@w3.org WG" <public-html@w3.org>
On Mon, Jan 25, 2010 at 9:28 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> When Ian proposed this change, he specifically focused it at weblog
> comments. I know comments, and the problems comment systems have. And in
> point of fact, there is nothing in Ian's example or discussion that relates
> to comment security.
> 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.
> 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. I'm hoping he (Adam) will link the relevant
> discussions from the WhatWG group here, so we can then look at Ian's
> solution in context of how it is to be used, it's customers, their
> expectations, and the technical challenges.

Adam stated that one major use-case of @sandbox was advertising.  Many
advertisements are served from completely untrusted and uncontrolled
sources, so @sandbox is useful to limit what it can possibly do.
Similarly, comments are generally untrusted, though the site owner
typically has control over them.  @sandbox is at thus at least
possibly relevant.

Not all issues relevant to comments will be addressed with @sandbox.
Some are small enough that leaving it to server-side filtering is
appropriate.  We want to focus mainly on things that server-side
filtering *cannot* replicate.  Right now, your choices are either let
comments have full scripting ability, or attempt to filter out scripts
entirely (and hope you got it right, and nobody's figured out a new
way to slip them past your filter).  The former is begging for XSS
attacks, and the latter is also vulnerable to them - it's a constant
arms race.  @sandbox lets you have much more fine-grained control over
scripting, and it's an absolute level of control - the browser knows
precisely when a script is attempting to run, precisely what the
origins are of the pages the script is trying to affect, etc.

You've brought up some things that an author might reasonably want to
prevent in a comment that aren't currently covered by @sandbox.  It's
possible that this might be a reasonable addition.  We can discuss
these specifically.  For example, <img> in comments, or <audio

Received on Monday, 25 January 2010 15:55:07 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:08 UTC