Re: Issue 100 Zero-Edits Counter Proposal

On 13.04.2010 02:13, Tab Atkins Jr. wrote:
> ...
> ### @srcdoc escaping requirements are difficult ###
>
> When used in an HTML page, the escaping requirements for @srcdoc are
> trivial.  You have to replace " with" and&  with&.  The
> latter has no security implications if it's forgotten; it's merely to
> prevent words following an&  from accidentally being interpreted as
> entity references.  The former is important for security, but it
> should also fail very quickly and very obviously if it is left out -
> the very first post containing an unescaped " (and thus truncating
> itself and dumping the rest of the contents into the element's tag
> directly) will make it painfully obvious both that there is a problem
> and how to solve it.
>
> When used in an XHTML page, the escaping requirements may be slightly
> more involved.  If so, then it is a weakness of XML, not of @srcdoc.
> In any case, Issue 103 apparently resolves the issue adequately, by
> specifying exactly what additional characters need to be escaped for
> @srcdoc to be safely used in XML.  (Note: I'm not sure how many, if
> any, of these additional characters are necessary to escape for
> security purposes, and how many just need to be escaped to ensure
> adequate display of the content.)

Does that mean that you support the general direction of the change 
proposal submitted for issue 103?

Anyway, what should be mentioned in this context is that putting markup 
into attribute values is maybe the #1 anti-pattern in vocabulary design. 
It should be avoided. Really. To add something like this for the first 
time in HTML history just to add a feature where there's not even 
agreement that the feature is useful is very very strange.

> ...
> ### There are existing alternatives to @srcdoc ###
>
> There were many alternatives proposed to @srcdoc in the discussion
> threads surrounding and preceding it.  The one that is most promising
> is to simply use a data: url in @src.  This has a few problems that
> make it inferior to @srcdoc:
>
> 1. data: urls have more complex escaping requirements than @srcdoc.
> All major web languages do provide an escaping function appropriate
> for urls, but it is easy to accidentally choose the wrong function.
> For example, in PHP the correct function to use is rawurlencode(), but
> the function urlencode() may be accidentally used instead.  In
 > ...

I think that's a very weak argument. I'm pretty sure that any feature we 
add can be used wrongly. What's much more important is that the 
languages allow to use it right, which appears to be the case. That 
being said, it even wouldn't be a problem if new libraries would be 
needed - after all we're talking about something which can be deployed 
only very slowly.

> addition, despite both of these functions existing in PHP, multiple
> homebrew url-escaping functions can be found across the web, which may
> not escape everything that is necessary to escape.  Some of these
> lapses may result in non-obvious security holes that can be exploited
> by attackers, allowing arbitrary code injection into a web page.
> ...

And these kind of security holes are impossible with @srcdoc?

> 2. In legacy browsers, data: urls will "fail open"; that is, they will
> display their contents even if the browser does not understand the
> sandbox security model, potentially exposing users to attack.  This
> can be mitigated by specifying a text/html-sandboxed mime type in the
> data: url, however.

So it's no problem, right?

> ...
> ### @srcdoc is unneeded by the blogging community ###
>
> The creator of Wordpress, Matt Mullenweg, was asked about the need for
> @srcdoc in the Wordpress software.  He responded that Wordpress
> maintains a sanitation library that appears to work adequately.
>
> This is, again, not an argument against @srcdoc, it is an argument
> against the sandbox security model.

Well, it is an argument against both.

As far as I can tell, the opposition to @srcdoc in specific is stronger 
than iframe sandboxing in general due to the VERY controversial syntax.

If we have indication that one of the important uses cases that were 
nominated won't be a use case in practice then we should think about 
both @srcdoc and the sandboxing feature, true. The outcome might be that 
we want to get rid of the questionable syntax, but keep sandboxing.

However, this issue is just about @srcdoc, so let's focus on this.

> ...
> Negative
> : As with all new elements and attributes, implementing this requires
> effort from implementors.
> ...

Lots of effort. Essentially it requires re-parsing attribute content 
with an HTML5 parser. This is an architectural problem; for instance, an 
application may be consuming SAX events from an HTML5 parser, but may 
not have direct access to the parser engine at all.

Best regards, Julian

Received on Tuesday, 13 April 2010 08:54:32 UTC