W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: E4H and constructing DOMs

From: Mike Samuel <mikesamuel@gmail.com>
Date: Mon, 11 Mar 2013 20:00:29 -0400
Message-ID: <CACod6GtxgJiYHn4Y-rE5YU1cPDeDdsMy+x++m2NbUHV7ezbJhA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
2013/3/11 Ian Hickson <ian@hixie.ch>:
> On Mon, 11 Mar 2013, Mike Samuel wrote:
>>
>> Ok.  So it's not a goal of E4H to be safe against XSS by default then.
>
> Autoescaping isn't safe by default either, by that definition.

URLs are kind of a large hole, and, yes, contextual auto=escaping is
safe by that definition.

E4H partially satisfies the structure preservation property, but fails
to address any of the other properties I outline at
https://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/safetemplate.html#security_under_maintenance

What do you and Adam mean by "safe" when you say "safe by default"?

> E4H's design goals were:
>
>  - to provide compile-time syntax checking for in-script DOM tree creation

A laudable goal.
Contextual auto-escapers provide some level of this.

>  - to provide in-script DOM tree creation in a terse and intuitive fashion

Also a laudable goal.  The string template provides this and can
produce output types other than DOM trees.

>  - to provide syntactic sugar for the most common use cases for in-script
>    DOM tree creation, specifically:
>     * inserting strings into attribute values
>     * inserting strings into element contents
>     * setting HTML boolean attributes conditionally based on an expression

Wonderful goals, especially proper handling of boolean attributes.

>  - to have good performance characteristics:
>     * only parse things once
>     * minimise string copying
>     * avoid using the HTML parser

I understand the first two goals.  The last seems to be confusing a
design choice with a design goal since not using an available tool is
rarely something of direct benefit to the end user.

>  - to have good security characteristics:
>     * provide a model that is conceptually simple
>     * allow arbitrary strings to be embedded in DOM trees in a way that
>       does not allow arbitrary elements or attributes to be created

If even
    <a href="{{...}}">
is a foot gun then I think it fails at this goal.

> I believe it succeeds at all of these, though I am happy to hear
> suggestions for how to better address them or how to address other goals
> if those can be met without compromising on the above.
Received on Tuesday, 12 March 2013 00:00:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC