Re: <iframe doc="">

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

Received on Monday, 25 January 2010 15:10:26 UTC