Re: <iframe doc="">

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
srcdoc<http://dev.w3.org/html5/spec/Overview.html#attr-iframe-srcdoc>
attribute
in conjunction with the
sandbox<http://dev.w3.org/html5/spec/Overview.html#attr-iframe-sandbox>
 and seamless<http://dev.w3.org/html5/spec/Overview.html#attr-iframe-seamless>
attributes
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
comments:

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.

Shelley




> > 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
>