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

Re: <iframe doc="">

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 24 Jan 2010 11:14:44 -0600
Message-ID: <dd0fbad1001240914p583b5f2aub3a7c8cf6dad1f89@mail.gmail.com>
To: Shelley Powers <shelley.just@gmail.com>
Cc: Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
On Sun, Jan 24, 2010 at 10:55 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> This is an old issue. We have had software to sanitize comments for a
> long time. It's built into most CMS tools. And for those who disregard
> the use of such tools, they're not going to use this, either.

Indeed, there are nearly as many html-sanitizers as there are CMSes.
And they're pretty uniformly bad.  Most of them are built on fragile
regexps, if you're lucky.  They might just be a handful of string
replaces that address whatever problems the CMS author could think of
at the time.  The best of them address *currently known attack
vectors* decently enough, but are usually weak to *new* attacks.

To do it properly you need a full HTML parser/tokenizer combined with
a whitelist-based sanitizer.  These are very rarely used in the wild,
and when they are used we can only hope they're not buggy relative to
browsers.  Only now, with HTML5, can we have a hope that independently
built HTML parsers will actually produce the same structure from a
particular piece of HTML, including in edge cases, so that attack
vectors can be spotted and headed off by anyone and the knowledge
spread to everyone.

On the other hand, @srcdoc makes this whole thing trivial, and allows
us to leverage the behavioral restraints of @sandbox as well.  It's a
win for everyone.  The only loss is if you were somehow silly enough
to write code with @srcdoc by hand, and I've already explained why
that's a silly thing to do.

> Rationales should always be provided, consensus should be sought with
> major changes. This a major change. The editor should not be making
> unilateral decisions -- and neither should the chairs.

Rationales were provided, both in the previous discussions around
iframe sandboxing, and the more recent one where Ian announced that he
wanted to add @doc.

> Decisions are made, true, but they should be made according to the
> strength of arguments provided, not the fact that Ian has edit control
> over the document.

Making decisions on the strength of arguments is not consensus.
That's technical merit, which is something entirely different, and is
in fact precisely how the working group works.  Ian decides what to
put in the spec by technical merit, and when the Decision Policy is
invoked, the Chairs decide what to do based on technical merit.

> I want to ask: which implementing company asked for this change?
> That's all it took for this to be incorporated, one implementor asked
> for it. I want to know which company/person specifically asked for
> this change?

How is that possibly relevant?  I thought you just said that decisions
should be made based on the strength of arguments.  I don't see how
the identity of the people proposing features affects the strength of
an argument.

~TJ
Received on Sunday, 24 January 2010 17:15:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT