Re: <iframe doc="">

On Mon, Jan 25, 2010 at 9:54 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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
> autoplay>.
>
> ~TJ
>

What I brought up is all of the factors that go into play when it comes to
comments and security, and did so to demonstrate that the srcdoc, and
evidently sandbox, change will have little impact. More importantly to show
that input scrubbers are used not just with comments, but also with posts
and articles--potentially we could have nothing but pages of content that
are iframe elements with escaped markup in text. Which won't be very useful
for friendly web bots.

But if the real purpose of the attributes, and the concept, is for ads,
that's a different story. That should have been the customer, and the use
case given, and should include an example of how this functionality would be
used with the primary use case.

In fact, by promoting sandboxing as security for comments, we may actually
be doing people a disservice, because existing comment safety is a superior
option.

Can one of you provide an example of how this work with ads, and the third
party ad sellers?

Shelley