Re: E4H and constructing DOMs

On Mon, Mar 11, 2013 at 1:16 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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
> consideration.
>
> 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
> E4H.
>
> 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"

That sounds like a reasonable approach.  We'll likely want to couple
that with good examples of using html`...` rather than string`...` to
get developers off on the right foot.

Is there a definition of the html quasis handler somewhere that I can study?

Thanks,
Adam

Received on Monday, 11 March 2013 17:23:20 UTC