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

Re: E4H and constructing DOMs

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 11 Mar 2013 01:16:32 -0700
Message-ID: <CA+c2ei_JYPex3Zd+5omFX3-U+M-QicdVMZidAVSMr-efAEyrWg@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Anne van Kesteren <annevk@annevk.nl>, Rick Waldron <waldron.rick@gmail.com>, Adam Klein <adamk@chromium.org>, Ojan Vafai <ojan@chromium.org>, Brendan Eich <brendan@secure.meer.net>, Ian Hickson <ian@hixie.ch>, "rafaelw@chromium.org" <rafaelw@chromium.org>, Alex Russell <slightlyoff@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>
On Mon, Mar 11, 2013 at 1:05 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Fri, Mar 8, 2013 at 5:53 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Fri, Mar 8, 2013 at 1:15 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>> Right, that's why the example in my first email is XSS:
>>>> ---8<---
>>>> var firstName = [...];
>>>> var lastName = [...];
>>>> header.innerHTML = `<h1>Welcome ${ firstName } ${ lastName }!</h1>`;
>>>> --->8---
>>> It's hard to say if the blame for this is with quasis or with
>>> .innerHTML though. I.e. would not having quasis cause people to use
>>> your AST based template system, or would they just use string
>>> concatenation?
>> I don't think it's that important to assign blame.  There's plenty of
>> evidence that developers are very happy with AST-based solutions when
>> done well.  For example, many, many developers use prepared statements
>> for SQL and Haml for HTML.
> Without knowing where the problem lies, it's hard to say that the
> proposed solutions are going to be effective.
>>> Indeed, since string templates don't even need to return strings, you could do
>>>     header.appendChild(htmlel`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>>> where `htmlel` just returns an HTML element constructed using that same algorithm (instead of the `outerHTML` of that element).
>>> At this point it seems like you are bikeshedding over `@` vs. `htmlel` or `{}` vs. `${}`, which leads me to believe I must be missing your argument, especially since you emphasize you're not wedded to ES4H and thus presumably not wedded to `@` or `{}`.
>> I don't care at all about the syntax.  If you want to keep backtick as
>> the operator, that's fine.  What's important to me are the following:
>> 1) The template system parses the trusted template content separately
>> from the untrusted input data.  In particular, it should fill the
>> untrusted data into the leaves of AST produced by parsing the template
>> rather than parsing the untrusted data.
>> 2) The template system does the above by default.
>> Specifically, I would be perfectly happy with the following syntax:
>> header.appendChild(`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>> as long as this "hello, world" template is not XSS.
> Note that quasis would fulfill that requirement as long as there is no
> default quasi. I.e. as long as:
> `foo ${ x }`
> is a syntax error but
> html`foo ${ x }`
> is not.
> But it's unclear to me if you'll be able to convince people that
> string templates are evil in enough contexts that they should be
> abandoned.

I see that I'm late to the party and that this proposal has already
been debated. I'm happy to see that it is receiving serious

But yes, I was always assuming that the html`...` would return a DOM
tree. As long as the html quasi handler treats all inserted data as
not-parsed-as-markup by default (see my earlier examples for opting in
to more unsafe parsing), and as long as there exists no default quasi
handler, I think we should be in a pretty good state even compared to

There is still the risk that people do "elem.innerHTML = string`...`"
where "string" is either a built-in quasi handler, or one that's
supplied by the author. But I'm not sure that the risk is that much
bigger than people doing "elem.innerHTML = '...' + x"

/ Jonas
Received on Monday, 11 March 2013 08:17:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC