3 ms·

Just like every other language. You either - Expose the entire language and then there's not much you can do to prevent something harmful. - Expose a subset

Just like every other language. You either - Expose the entire language and then there's not much you can do to prevent something harmful. - Expose a subset of the language perhaps through parsing for harmful patterns or by somehow making potentially harmful functions unreachable. - Expose a more restricted language (scripting like c/lua) that you control and know its full capabilities. The only difference I can think of is that it's easier to write flexible and dynamically modifiable software in lisp than in most mainstream languages.

seiji 11y ago
The end result has been years of (practical) research going into an actually safe, actually sandboxed, actually secure cross-platform platform: https://developer.chrome.com/native-client https://developer.chrome.com/native-client
- brandmeyer 11y ago
  I raise my right eyebrow of incredulity at the "actually secure" claim, considering that even Chrome regularly falls in contests like Pwn2Own.
  - seiji 11y ago
    Well, native client isn't chrome itself. Chrome has to deal with dumb OS issues and platform interop. Native Client is more of a complete data/instruction sandbox: https://developer.chrome.com/native-client/faq#security-and-privacy https://developer.chrome.com/native-client/faq#security-and-... Plus, they are taking their time (years and years and years) to get it working properly before driving public adoption.
btilly 11y ago
Capability based systems offer better options. All access to anything important (network, files, other commands, etc) have to happen through opaque handles called capabilities. Think of them as objects that you can't look for. When you call code, you pass it a set of capabilities that are available. That is all it can ever access. But the whole language and environment needs to be defined from the bottom up to enable this.

seiji 11y ago

The end result has been years of (practical) research going into an actually safe, actually sandboxed, actually secure cross-platform platform: https://developer.chrome.com/native-client https://developer.chrome.com/native-client

brandmeyer 11y ago
I raise my right eyebrow of incredulity at the "actually secure" claim, considering that even Chrome regularly falls in contests like Pwn2Own.
- seiji 11y ago
  Well, native client isn't chrome itself. Chrome has to deal with dumb OS issues and platform interop. Native Client is more of a complete data/instruction sandbox: https://developer.chrome.com/native-client/faq#security-and-privacy https://developer.chrome.com/native-client/faq#security-and-... Plus, they are taking their time (years and years and years) to get it working properly before driving public adoption.

btilly 11y ago

Capability based systems offer better options. All access to anything important (network, files, other commands, etc) have to happen through opaque handles called capabilities. Think of them as objects that you can't look for. When you call code, you pass it a set of capabilities that are available. That is all it can ever access. But the whole language and environment needs to be defined from the bottom up to enable this.