<div dir="auto">That was one reason why I choose new Function() over eval, but I don’t know jack sh*t and rely on others to read documentation and standards...I have a short attention span.   I am not really sure what causes it, but I’ve had it for 30 years.</div><div dir="auto"><br></div><div dir="auto">I don’t mind using an alternative script engine, but it would seem like 1) you’re increasing the attack surface. 2) you could achieve some something similar with existing browser technology and the people writing the browser script engine likely have the most experience.</div><div dir="auto"><br></div><div dir="auto">Note that last I checked, X_ITE uses eval.   How it uses eval may be interesting.</div><div dir="auto"><br></div><div dir="auto">Note that X3DJSONLD use eval.   That was because I split the script code into 3 pieces.</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 3:07 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Since scripts run arbitrary javascript code and javascript has access<br>
to everything in a browser sandbox, or, outside the context of a web<br>
browser, potentially to the operating system, there are security<br>
implications to the x3d script node.<br>
<br>
It is easy for a bad actor to construct a x3d scene which has<br>
disruptive code. Here is an example with x_ite:<br>
<br>
xml: <a href="https://gist.github.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d" rel="noreferrer" target="_blank">https://gist.github.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d</a><br>
<br>
live:<br>
regular script:<br>
<a href="https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/safe.html" rel="noreferrer" target="_blank">https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/safe.html</a><br>
<br>
unsafe script:<br>
<a href="https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/unsafe.html" rel="noreferrer" target="_blank">https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/unsafe.html</a><br>
<br>
Of course, this concern exists for any html page loaded into a<br>
browser. The difference with x3d is that the code is more hidden,<br>
perhaps in an inline, and not expected to do anything outside the x3d<br>
scene.<br>
<br>
Here is an interesting read:<br>
<a href="https://www.figma.com/blog/how-we-built-the-figma-plugin-system/" rel="noreferrer" target="_blank">https://www.figma.com/blog/how-we-built-the-figma-plugin-system/</a><br>
<br>
Their solution in the end was:<br>
<a href="https://www.figma.com/blog/an-update-on-plugin-security/" rel="noreferrer" target="_blank">https://www.figma.com/blog/an-update-on-plugin-security/</a><br>
<br>
They decided to run a whole new javascript engine (quickjs) compiled<br>
to wasm inside the browser. This is similar to how standalone x3d<br>
browsers embed js engines like duktape. Such browsers then need to<br>
rely on the security of the embedded engines.<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>