Eventually drop eval?

[AlexErrant]

eval is used here, which unfortunately causes an error in sites which have a strict Content-Security-Policy. AFAIK the only way to get around this is to add unsafe-eval to the CSP, which, as the name suggests, is unsafe.

Is there any plan to move away from eval? Looking at the complexity of e.g. https://github.com/lxsmnsyc/seroval/blob/main/packages/seroval/src/core/context/serializer.ts I'm pretty sure the answer is "no", but thought I should ask anyway.

[lxsmnsyc]

if there's an alternative to eval, then yes that should be possible. Other than that, the answer would be "no".

The thing is, the data serialization format is in JS, so there's just no way we can evaluate those scripts without using eval, except of course if one would use the JSON format of seroval, in which case, deserialization would be slower by a lot.

[millette]

Closed because no eval alternatives were evaluated? (no pun intended).

[AlexErrant]

I'm assuming any direct workaround like Function() would be covered by unsafe-eval since it would be targeted by hackers.

Indirectly, perhaps Seroval could be loaded in a webworker/iframe on a different origin where unsafe-eval has not been set. Of course, now you need to figure out how to transfer the deserialized data to the original origin... some data is "transferrable", but not all. This would probably break streaming and other Seroval features.

There's a trusted-types-eval that's being proposed for Content Security Policy Level 3, but of course it's not out yet. And even when it lands, support won't be universal.

Finally, there's tRPC.

[lxsmnsyc]

Indirectly, perhaps Seroval could be loaded in a webworker/iframe on a different origin

You had me at "webworker". Seroval isn't just a server-client serialization library, it's a runtime-to-runtime serialization library.