Polyfilling HostEnsureCanCompileStrings about trusted-types HOT 7 CLOSED

I moved the spec-centric issues to #207. I propose we postpone the polyfilling until after the spec issues are resolved. We won't be able to polyfill everything, so I'm thinking on whether we should attempt to in the TT polyfill, given that we'd likely run into performance, or some stack trace introspection issues. To demonstrate feasibility, we can probably create a Babel plugin. WDYT, @mikesamuel ?

from trusted-types.

I like the Function constructor polyfill. Can we check if this doesn't break existing code?

As for 'eval', I'm afraid that polyfilling it will introduce tricky functional bugs in the applications using the polyfill. I'm not yet convinced this is the right way to go; it might be more fitting to just mention that this is a known gap for the polyfill, and assume that eval is otherwise sparsely used and easy to find with other means.

from trusted-types.

@koto

Can we check if this doesn't break existing code?

Do you want to try out a canary project with the patch?
Or do you want a PR that adds it and some tests.

As for 'eval',

To make sure I understand, Function can be called implicitly as via ({})['constructor']['constructor'](code)(), but eval requires the use of the eval (unreserved) keyword.

So our polyfill security caveats could recommend banning eval via linter since the polyfill handles the one that is easy to overlook.

from trusted-types.

I have tried proxying Function before so have some indication that legacy code doesn't just go up in flames.

I use a Function proxy to restrict dynamic code loading to certain modules in Node.js.

That works with a bunch of legacy Node.js code.

from trusted-types.

OK, that works for Function(). To make sure I understand the eval concern: we can effectively polyfill window.eval, but not the operator (because of the scoping difference), but that's a problem, because most of the time the platform will choose the operator in place of the function. I think this may cause the polyfill to introduce functional bugs that are tricky to debug.

That's an implementation concern and I'm OK for the polyfill to cover less sinks than the native implementation if the alternative is to break applications in confusing ways. That said, for now I think we have to pause this anyway - as the Chrome implementation doesn't yet cover Function() nor [window.]eval(), let's resolve this first.

from trusted-types.

https://mikesamuel.github.io/proposal-hostensurecancompilestrings-passthru/ aims to address the lack of context in the host.

from trusted-types.

@koto, +1

from trusted-types.