6 ms·

I'm unclear about what kind of threat "freeze" protects against. Is it just protecting against your own mistakes, or against malicious code somehow running in t

• etc_passwd 4y ago
  the ability to create and send an object that cannot be modified
• beebeepka 4y ago
  I think Object.freeze is insufficient but there is value in immutable properties of objects. I wish TS understood this
• kragen 4y ago
  Malicious code running in the same JS process, specifically malicious code that modifies an object you give it (that you retain references to) or that gives you an object and then changes it later. Running multiple mutually untrusting pieces of code in the same process was the main point of E, and that's what the modifications to JS being discussed here are aimed at. The reason for such "frozen" objects is explained in http://www.erights.org/elang/kernel/auditors/index.html http://www.erights.org/elang/kernel/auditors/index.html.
  • goto11 4y ago
    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 wreck all kinds of havoc anyway?
    • 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.
• vanderZwan 4y ago
  So first of all the article is a bit confusing: Object.freeze does make an object immutable: const t = Object.freeze({foo: "bar"}); // throws an error in strict mode, // silently does nothing otherwise t.foo = "baz"; // prints "bar" console.log(t.foo); The tricky part is that it does not do so recursively: const t2 = Object.freeze({foo: {bar: "baz"}}); // bar is still mutable t2.foo.bar = "oh no!"; // prints "oh no!" console.log(t2.foo.bar); Still, one can easily write a function to recursively do a depth-first walk on an object and make everything immutable, so this is not really a concern in practice (if anything it gives you more flexibility). Anyway, what I think Miller meant is that immutability is not the main reason why they introduced Object.freeze. If I understand correctly, the main idea is to prevent people from inserting malicious code in the prototype chain (or anywhere else they might be able to). Because JavaScript is prototype based I could in theory create a new Array class that uses the original Array class as its own prototype, then replace the Array class with itself. If you then create a new array it would still work like a regular one - it just goes up the prototype chain after all. The malicious part is that this custom array class could then also override all Array methods to secretly watch your data and send stuff to the web without you noticing, or do anything else really. Because, again, it can just call the original method of its prototype to also behave as normal without anyone noticing. Object.freeze would let you make sure none of the fundamental JavaScript objects can be tampered with. The other thing is that you can ensure that any the library you create cannot be tampered with by third-party libraries.
  • bluetech 4y ago
    > Object.freeze does make an object immutable If you look at the Hardened Javascript example: const makeCounter = () => { let count = 0; return harden({ incr: () => (count += 1), decr: () => (count -= 1), }); }; The "counter object" here is mutable. I think that's what they mean.
    • afiori 4y ago
      There are two types of immutability in JS: one is rebinding a variable (forbidden by the const keyword) and the other is modifying an object (forbidden by freeze) In javascript these are similar as environment closures behave sort of similar to prototype chains.