Re: <iframe doc="">

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

> On Mon, Jan 25, 2010 at 8:34 AM, Shelley Powers <shelley.just@gmail.com>
> wrote:
> > I'm glad you noted that this approach won't really be worthwhile, or
> stand
> > alone, for years because of existing browsers.
>
> That is most certainly not what Maciej said.
>
> > But let's go further on this. Since I found out that the primary use case
> > for this change, and in fact, this whole sandbox issue, is comments,
> let's
> > talk about comments.
>
> To shorten the following, I'll distill it into bullet points.
>
> • sql injection
> No, it won't protect against sql injection, as that's a server-side
> issue.  That has never had anything to do with the client-side, and
> until/unless we get a client-side sql database api, it will continue
> to not be a client-side issue.
>
> • spammers
> No, of course not.
>
> • blocking images
> Possibly.  At the moment <img>s are allowed in sandboxed content.  Is
> this something we need to address?
>
> • blocking SVG
> Possibly.  Is this something we need to address?
>
> • posts, rather than comments, needing control/protection
> If you are letting untrusted users post content on the site, and
> you're already using @sandbox'd iframes for comments, then yes, it's
> probably a good idea to do so for posts as well.
>
> • invalid unicode characters in XHTML
> I think many of the browser vendors would enjoy fixing this error in
> XHTML, but many in the XHTML community seem quite strongly opposed to
> it.  It's nothing to do with @sandbox, though - if you fix it in one
> place, it should be fixed everywhere.
>
> • browser vendors being less experienced than sanitizing-tools authors
> Perhaps.  But browsers also have very particular powers that
> sanitizers can not ever have, such as the ability to know precisely
> when something would run script, or attempt to change something
> outside of its origin.  They also have things like the parser they use
> to parse the page, which, as I stated before, means that they can
> potentially 'clean' HTML with no chance of anything slipping through
> due to a mismatch in parsing algorithms.  There are a number of things
> that we'd like to have control over that are literally impossible to
> control through sanitizing, but @sandbox helps us with that.
>
> I'll note, though, that your objections seem now to be completely
> about @sandbox instead of @srcdoc?  Is this correct?  As I said
> before, @srcdoc is merely a convenience attribute for making @sandbox
> easier to use.  You seem to be objecting to the concept of @sandbox
> itself.
>
> ~TJ
>

So, what you're saying is that this change really won't do much when it
comes to weblog comments?

No, I'm still talking about srcdoc, since that was the change that Ian
added, and the use case Ian provided was weblog comments. If the discussion
indirectly impacts on sandbox, and the only reason for the sandbox attribute
was weblog comments, then we can discuss that one, too.

Shelley