Issue 100 Zero-Edits Counter Proposal

This proposal is also available in HTML format for easier reading at <
http://www.xanthir.com/:4ku >.

Issue 100 Counter-Proposal
==========================

Summary
-------

There is no problem, and no change should be made to the spec.

Rationale
---------

Several rationales are given in the Issue 100 Change Proposal for
removing @srcdoc:

1. @srcdoc doesn't provide adequate protection

2. @srcdoc escaping requirements are difficult

3. @srcdoc has bad fallback

4. There are existing alternatives to @srcdoc

5. @srcdoc is unneeded by the blogging community

### @srcdoc doesn't provide adequate protection ###

This objection is irrelevant for multiple reasons.

First, this is not an objection against @srcdoc.  @srcdoc is a
convenient way to get content to interact with the sandbox security
model, nothing more.  If the sandbox security model doesn't provide
adequate protection, failures should be raised as bugs against it
specifically.  Changing or removing @srcdoc will have no effect on the
reliability of the sandbox security model.

Second, the types of things that were listed as not being protected
against, such as SQL injection, are entirely outside the scope of
HTML.  **No technology within HTML can possibly address them.**
Preventing an injection attack against your database, for example, is
the responsibility of the database itself, or of the language
interfacing with that database.

### @srcdoc escaping requirements are difficult ###

When used in an HTML page, the escaping requirements for @srcdoc are
trivial.  You have to replace " with &quot; and & with &amp;.  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.)

### @srcdoc has bad fallback ###

This objection has multiple levels.

First, in a browser which doesn't understand @srcdoc at all, the
<iframe>'s @src attribute is instead used to obtain the contents for
the frame.  This is, in general, good fallback behavior - @srcdoc is
intended to be identical to using @src, just without the additional
network request.

The second level, again, has to do with the sandbox security model
itself, and thus has nothing to do with @srcdoc itself.  In browsers
which also don't understand @sandbox, the @src fallback will execute
in an un-sandboxed environment.  As well, the entire sandbox security
model can be bypassed if the attacker can have the user visit the
content's URL directly.  This is valid.  There are two possible ways
around it:

1. Don't fallback at all - have the document pointed to by @src be an
author-generated message that the browser the user is using doesn't
support secure content.

2. Use the text/html-sandboxed mime type to serve the document pointed
to by @src.  This will fail in the proper way (the page will not be
displayed at all) in legacy browsers that don't understand @sandbox.
In newer browsers that understand @sandbox but not @srcdoc, or when
the user visits the url of the content directly in a browsers that
understand @sandbox, the page will be displayed with the sandbox
security model in place.

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

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.

3. As the data: url would be used in @src, there is no capability to
fall back to another message if the browser does not understand the
sandbox security model.

4. data: urls are usually interpreted to be a unique origin by
default, for security.  It is possible that the `allow-same-origin`
flag in @sandbox could be used to indicate that the data: url should
be given the same origin as the outer page, but this would further
complicate the already-confusing rules about when a data: url is
same-origin and when it is unique-origin.

### @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.

### Summary ###

Most of the objections listed in the Change Proposal were completely
irrelevant to the actual issue.  They are concerns with the sandbox
security model itself.  @srcdoc is merely a convenient way to opt-in
to the sandbox security model without incurring a network request each
time.

The objection concerning escaping requirements appears to be answered
adequately by the Issue 103 change proposal.

The objection concerning fallback is invalid, given the addition of
the text/html-sandboxed MIME type.

The objection concerning alternate solutions has been shown to be
incorrect, as the best alternative solution, data: urls in @src, is
still inferior to @srcdoc on several points.

Details
-------

No change is made to the spec.

Impact
------

Positive
: Authors get to use @srcdoc to easily make content adhere to the
sandbox security model.

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

Received on Tuesday, 13 April 2010 00:22:36 UTC