<div dir="auto">Joe, I think eval has some way of handling these contexts from my reading of X_ITE, but I didn’t really understand.  In JavaScript, functions create new contexts.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 4:29 PM Joseph D Williams <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</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)"><div lang="EN-US" link="blue" vlink="#954F72"><div class="m_-2302142582586012074WordSection1"><ul style="margin-top:0in" type="disc"><li class="m_-2302142582586012074MsoListParagraph" style="margin-left:0in">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.<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The script is expected to  be active only it the context in which it is an instance. <u></u><u></u></p><p class="MsoNormal">A scene creates the main context, then, an inline or a proto instance must create a new child context then use organized import/export and is code to communicate with its parent scene context. <u></u><u></u></p><p class="MsoNormal">Why would I expect that a script in my scene or an inline or a proto I might use would be able to interact with a parent html context except using x3d SAI? That is like me thinking a script in any parent context could talk to my scene using anything else than x3d SAI. <u></u><u></u></p><p class="MsoNormal">With SAI, my scene knows how to handle its parent context and child contexts just fine.  <u></u><u></u></p><p class="MsoNormal">At least that’s the way I learned it. <u></u><u></u></p><p class="MsoNormal">Thanks,<u></u><u></u></p><p class="MsoNormal">Joe<u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="#954F72"><div class="m_-2302142582586012074WordSection1"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-style:solid none none;border-top-width:1pt;padding:3pt 0in 0in;border-top-color:rgb(225,225,225)"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:yottzumm@gmail.com" target="_blank">John Carlson</a><br><b>Sent: </b>Thursday, October 15, 2020 1:33 PM<br><b>To: </b><a href="mailto:andreasplesch@gmail.com" target="_blank">Andreas Plesch</a><br><b>Cc: </b><a href="mailto:x3d-public@web3d.org" target="_blank">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] script security</p></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">This may be worth looking at:</p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><a href="https://github.com/google/caja" target="_blank">https://github.com/google/caja</a></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Oct 15, 2020 at 3:07 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:</p></div></div></div><p class="MsoNormal" style="margin-left:4.8pt">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" 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" 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" 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/" 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/" 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" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></p><p class="MsoNormal"><u></u> <u></u></p></div></div></blockquote></div></div>