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

Re: <iframe doc="">

From: Shelley Powers <shelley.just@gmail.com>
Date: Mon, 25 Jan 2010 10:23:29 -0600
Message-ID: <643cc0271001250823q27be0da9qede2ac638890b23b@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@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 10:06 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Mon, Jan 25, 2010 at 10:00 AM, Shelley Powers <shelley.just@gmail.com>
> wrote:
> > 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.
> I do not believe you demonstrated that @sandbox will have little
> impact.  You ignored all the security issues that @sandbox currently
> addresses and then implied your list was exhaustive.  You also brought
> up several issues that are entirely irrelevant for @sandbox, as they
> dealt with things that are not related to displaying untrusted
> content.  @sandbox isn't magical; it addresses particular concerns
> that are difficult/impossible to address with current technologies.
I went to the spec, and copied the following:

Here a blog uses the
in conjunction with the
 and seamless<http://dev.w3.org/html5/spec/Overview.html#attr-iframe-seamless>
described below to provide users of user agents that support this feature
with an extra layer of protection from script injection in the blog post

Seemingly the purpose of srcdoc (in conjunction with sandbox) is so that
comments are protected against script injection. But I covered script
injection in my earlier discussion of browser comments, and the tools that
protect comments. How is that not relevant?

I have demonstrated that this is a solution for something that is not a
problem. And in fact, another thread has evolved that is focused on what
elements should be scrubbed and what should not -- something that can be
easily defined using the existing tools. Controlled and modified according
to the trust level associated with the user, which is a superior option that
I'm seeing for what we're including in HTML5.


> > 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.
> Spiders will read @srcdoc as well.  It won't be a big deal to have
> them treat it as part of the page, as it's intended.
> > 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.
> That was one of the concepts for @sandbox, and it was given.  We're
> discussing @srcdoc, though, which is irrelevant for the ad-serving 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?
> <iframe sandbox seamless src="http://ads.example.com/?ref=foobar
> "></iframe>
> Because, as stated, @sandbox is useful for ads, but not @srcdoc.
> ~TJ
Received on Monday, 25 January 2010 16:23:58 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC