3 ms·

Interesting! But I have a hard time understanding the use case in the context of a web page. If you import malicious code in a web app, wouldn't it be able to w

• kragen 4y ago
  The objective of Jessie and the other capability-secure dialects of JS is precisely to allow you to import malicious code in a web app without allowing it to either wreak or wreck any havoc. You can imagine lots of ways this could be useful. One of the most boring but profitable was Crockford's original application for one such dialect at Yahoo — interactive banner ads: https://www.crockford.com/adsafe/ https://www.crockford.com/adsafe/ More generally, what if you want to drop a poll into a chat channel, upload a trading bot to a cryptocurrency exchange, run an image-filtering plugin for your paint program without giving its author access to your imagery, etc.? There are lots of scenarios where fine-grained security permits useful kinds of collaboration.
  • goto11 4y ago
    I guess I have a hard time seeing how Object.freeze() protects against malicious code, when any malicious script can still access the global object? I can understand something like the "Shadow realms" proposal, where a modules access to global objects can be constrained.
    • kragen 4y ago
      In things like Jessie or ADsafe, confined scripts are screened to ensure that they do not access the global object.
      • goto11 4y ago
        So am I correct in the understanding that Object.freeze in JavaScript does not provide any useful protection against malicious code? But in a different language, or a hypothetical future version of JavaScript, it might play a role in such a protection?
        • kragen 4y ago
          I think it provides, at best, very limited useful protection against malicious code that has access to the whole JS language, but it means that Jessie can include enormously more of JS than ADsafe did.
      • cztomsik 4y ago
        ShadowRealm + Object.freeze() could be enough to create safe env for untrusted code.