2 ms·
A lot of the complaints here claim that this is bad because it’s insecure. However, allow me to posit a question: what if I made a function that just fetches th
by jchw 5y ago
A lot of the complaints here claim that this is bad because it’s insecure. However, allow me to posit a question: what if I made a function that just fetches the script and evals it? Node.JS already involves running unsandboxed, practically untrusted arbitrary code, that nobody audits. I’d have more sympathy if not for the fact that you can pretty much emulate this with the permission level that Node.JS code runs today.
Also, no… this is not like PHP. PHP include got lambasted because it compounded other PHP security issues. If you use ESM imports, the obvious way, there’s never going to be an accident where user input can control the URL, because the grammar makes it impossible. You can use the dynamic import statement, but at that point you’re off into the abyss.
- user-the-name 5y agoThere is value in making insecure things hard and awkward to do, rather than providing them as first-class constructs.
- jchw 5y agoWhile this is true, if this is going to be the future, it may as well be provided as a feature with the proper precautions. While this doesn’t fully sandbox code, it does at least seem to provide some decent baseline security features. If I needed to import code from a web address for some reason, this is certainly the way to go, and whether ideal or not, sometimes that is a need that crops up. That said, proper sandboxing and/or at least optional integrity checking would certainly be nice.