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:05:18 -0700
Message-ID: <CA+c2ei-nAX4Qt0z7H9KBE2pwg7VfA+4TBZeq+KD+KM250QHB9w@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 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.

/ Jonas
Received on Monday, 11 March 2013 08:06:16 UTC

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