It’s not the job of a language to solve everything. Sometimes the solution belongs in sandboxing and virtual machines. You should be isolating untrusted code anyway.
SafeScript was just inspired by Google’s CaJa project from 10 years ago. My Qbix Webserver started rewriting PHP before loading it, and I wondered what if I could start over and just reduce the language the way JSON reduced it to just data, and was wildly successful. I chose JS as the base because it’s everywhere. I then made it also execute inside PHP. I made it auto-await every promise so it could work in non-evented environments like vanilla PHP.
This could be the next Lua, for instance, but for the modern era and far safer.
Having said that… there may be some static analysis you could do, to conservatively overestimate how much memory any given program could waste, and reject those that COULD waste it. The nice thing about static analysis is you only have to run it once per particular script.
What you are saying here is completely different to what your GitHub readme says. You say it protects the host's environment there but here you say it actually doesn't so use a real sandbox.
> This could be the next Lua, for instance, but for the modern era and far safer.
It isn't the default but you can sandbox all of this with Lua already. Including limiting CPU and memory use.
Good question! Nothing in SafeScript itself prevents it. Instrumenting the code to prevent this would be too costly. A script can do
var a = [];
for (var i = 0; i < 10000000; i++)
{ a.push({x: i}); }
But that’s because it’s up to the host to sandbox the script, eg in WebWorkers or Node VM Isolates, using Q.Sandbox and use Q.Proxy to transparently pass in the Facades.
In PHP the situation is excellent. That’s language has support for checking how much memory was used, so our injected checks already works there:
For native embedded applications, where SafeScript is positioned to replace Lua, the situation is quite good. QuickJS already has JS_SetMemoryLimit() - a hard byte ceiling, which throws when hit. In fact the https://github.com/SafeScript/safescript-quickjs repo already uses this.
You can think of this as the “belt-and-suspenders” approach. Perhaps a future version of SafeScript would instrument the actual imperative code to catch these, same as it catches a script that tries to peg the CPU. But so far, I haven’t found a good way, without totally overriding most Javascript primitives, objects and operations. Any suggestions?
What's stopping malicious scripts from sucking up the host's memory?
I think they're using a slightly different definition of "safe" than you are
It’s not the job of a language to solve everything. Sometimes the solution belongs in sandboxing and virtual machines. You should be isolating untrusted code anyway.
SafeScript was just inspired by Google’s CaJa project from 10 years ago. My Qbix Webserver started rewriting PHP before loading it, and I wondered what if I could start over and just reduce the language the way JSON reduced it to just data, and was wildly successful. I chose JS as the base because it’s everywhere. I then made it also execute inside PHP. I made it auto-await every promise so it could work in non-evented environments like vanilla PHP.
This could be the next Lua, for instance, but for the modern era and far safer.
Having said that… there may be some static analysis you could do, to conservatively overestimate how much memory any given program could waste, and reject those that COULD waste it. The nice thing about static analysis is you only have to run it once per particular script.
Why are you trying so hard to defend programs that can crash by blaming it on their runtime environment?
What?
I like the erlang philosophy of letting programs die if they crash.
The runtime environment handles those errors, not the code.
What you are saying here is completely different to what your GitHub readme says. You say it protects the host's environment there but here you say it actually doesn't so use a real sandbox.
> This could be the next Lua, for instance, but for the modern era and far safer.
It isn't the default but you can sandbox all of this with Lua already. Including limiting CPU and memory use.
I’m sure you can. This is much more of a modern solution than Lua was in the 90s.
Good question! Nothing in SafeScript itself prevents it. Instrumenting the code to prevent this would be too costly. A script can do
But that’s because it’s up to the host to sandbox the script, eg in WebWorkers or Node VM Isolates, using Q.Sandbox and use Q.Proxy to transparently pass in the Facades.
In PHP the situation is excellent. That’s language has support for checking how much memory was used, so our injected checks already works there:
https://github.com/SafeScript/safescript-php
For native embedded applications, where SafeScript is positioned to replace Lua, the situation is quite good. QuickJS already has JS_SetMemoryLimit() - a hard byte ceiling, which throws when hit. In fact the https://github.com/SafeScript/safescript-quickjs repo already uses this.
You can think of this as the “belt-and-suspenders” approach. Perhaps a future version of SafeScript would instrument the actual imperative code to catch these, same as it catches a script that tries to peg the CPU. But so far, I haven’t found a good way, without totally overriding most Javascript primitives, objects and operations. Any suggestions?
Does the system do its own allocations with a memory block or does it basically depend on the host to malloc?
The system is basically JS, you can run it however you like!
SafeScript actually compiles to plain JavaScript, just like Typescript does
In PHP, it compiles to plain PHP :)
Maybe you could rethink the SS logo?
I was asking Claude the same thing. At least this isn’t two lightning bolts like Gene Simmons’ band KiSS…
This is literally the Javascript logo but with the J turned into an S. I’d rather reclaim “SS” for something positive…