Re: [heycam/webidl] Added a definition of {{StringContext}} extended attribute. (#841)

> OK, that makes things much clearer.

Yes, sorry about not being explicit about that early on. I don't think we have a precedent for such behavior in the web platform. It's familiar and intuitive to our team, as we're working on the thing, but understandably, it's a bit of a surprising twist.

> 
> So the key is that there is still a concept of "already validated" on the caller side (which was not clear to me from the above) and that we want to only do validation if the thing we have is not already validated. OK, that makes things much clearer.
> 
> > The logic for the sanitization of values is roughly
> 
> OK, I see. One thing that's not entirely clear to me is whether the default policy case should be passed the initial value, or a stringification of the original value, or a stringification with the USVString fixups applied, or whether it doesn't matter much. 

It would be preferable if we could get the initial value in the default policy. The current spec draft is worded differently, but we're thinking of changing that, as that allows the authors to allow a selection of "their" types to pass through. It's not a strong requirement though, just a recent idea we had. 

> > In other words, Trusted Type try to prevent the JS code from interacting with risky APIs, not the browser algorithms
> 
> OK. That's a reasonable tradeoff, as long as you make sure that all the relevant boundary bits are annotated.

👍
 
> > Option 2 actually looks OK too. What is exactly the author-observable difference to option 1 + before?
> 
> I had been thinking of option 2 as a post-conversion step, so coming at a later point than "option 1 + before". It looks like you're asking about doing it as a pre-conversion step.
> 
> The main observable difference, I guess, is what happens with a union type. "Option 2" would invoke the sanitization stuff no matter what the value is, and while "option 1 + before" will only invoke it if we determine that we're taking the DOMString branch of the union, right? Presumably we want the latter behavior, in general?

Yes, the latter would be preferable.

> the main complexity is threading through the information about what operation/setter is involved to the conversion site

What we'd be using in the sanitizing callout is:
 - the [relevant global object](https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global) realm of `this` (to check the CSP list),
 - the IDL identifier name of the attribute / operation (string of it would be enough) - this is to put details into a CSP violation object,
 - some identifier of the type to convert to (a string is fine),


> But if we want to have the semantics that `void foo(([StringContext=html] DOMString or Node)` arg); only invokes sanitization for non-Nodes

If that helps, I only see a single case for us where that would be relevant: https://w3c.github.io/webappsec-trusted-types/dist/spec/#enforcement-in-timer-functions, but we can special case it in HTML I think. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/841#issuecomment-586445273