Krzysztof Kotowicz

Actually, @arturjanc reminds that 'unsafe-eval' only kicks in for strings (at least in Chrome): https://jsbin.com/qehejuvido/edit?html,output which would elegantly allow us to enable eval(TrustedScript) without needing `unsafe-eval`. However, Chrome's behavior does...

https://github.com/w3c/webappsec-csp/issues/201

Heh, I just found https://github.com/tc39/ecma262/issues/1495 which describes this neatly :)

`eval` is still used quite often actually. Some frameworks use it to back a expression parser in their template systems e.g. [VueJS](https://vuejs.org/v2/guide/syntax.html#Using-JavaScript-Expressions). Allowing eval selectively (e.g. only in trusted components...

Not quite. Developing a non-eval based solution is sometimes quite complex, and the only real gain is being "CSP with no unsafe-eval" compliance. What we're seeing is that this gain...

That would be https://github.com/w3c/webappsec-csp/. @mikewest is the editor.

I think we should prioritize upstreaming all the integrations, as monkeypatching just isn't easy to work with. That includes DOM, DOM Parsing, HTML and WebIDL at the least.

We tried that approach with libraries on top of TT, but it just doesn't work, as one would have to wrap all the sinks. From what I remember the issue...

``` const delayedWriteToSink = (el) => setTimeout(() => el.innerHTML = 'bar'); policy.run(() => { delayedWriteToSink(el); }) ``` Elements inside the `.run` would have to be different than regular elements. The...

Ww always used a policy name, but they are indeed optional (and only relevant if one guards policy creation by name with `trusted-types` directive). @otherdaniel, can we add a use...