| 00:45 | <ljharb> | right |
| 00:59 | <Mathieu Hofman> | Can we just fix the override mistake? If we introduce a "freeze mode" that doesn't trigger the override mistake for some intrinsics, I'd like this behavior to not be exotic, and be applicable to non intrinsics. One avenue I've been toying with is an options bag to Object.freeze that would allow setting such mode on the object and have the OrdinarySetWithOwnDescriptor check for that mode. I think changing 2.1 to something like this would be enough: If ownDesc.[[Writable]] is false and O.[[FrozenWithoutOverrideMistake]] is true, return false. |
| 01:02 | <Mathieu Hofman> | Then instead of ad-hoc patching some intrinsics so that they'd be exotic non-configurable, just ask that code opt-in to freezing all the intrinsics through the new "secure mode" |
| 01:03 | <bakkot> | Mm, I'm not sure how much appetite there would be for a new attribute on every object. That's a lot to ask of engines. |
| 01:03 | <bakkot> | maybe? |
| 01:03 | <Mathieu Hofman> | Doesn't have to be on every object, just the special frozen ones ;) |
| 01:05 | <Mathieu Hofman> | Implement it as another integrity level if you want, super-frozen. I actually would like if that same super-frozen mode didn't re-execute all the checks in isFrozen, and simply returned true if in that mode. It'd behave like a "cached-frozen" mode. |
| 01:05 | <bakkot> | though if you really want this patch to be non-exotic, you can do that without a new attribute by, instead of having a nonwritable field, instead having a frozen getter/setter pair where the setter silently does nothing |
| 01:06 | <bakkot> | I too like things being more frozen, but asking engines to mess about with the internal representations of things is, generally, going to need to clear a pretty high bar |
| 01:06 | <bakkot> | I would expect, anyway |
| 01:06 | <Mathieu Hofman> | Correct, and that's what the Hardened JS / SES repairs do to tame the override mistake (referring to installing a no-op setter) |
| 01:10 | <Mathieu Hofman> | However the experience in debuggers and other code that inspect objects is really sub-par with that kind of repair into accessors. |
| 01:13 | <bakkot> | Well, right, seems like it would be easier just to make it exotic |
| 01:14 | <bakkot> | I'm not opposed to having a new integrity mode if you can convince engines it's worth it, I just think that's a lot less likely to happen than making Array.prototype special |
| 01:15 | <Mathieu Hofman> | easier maybe, but given there were multiple agenda items that broached on the override mistake and in general allowing developers to opt-into a more secure environment, I would really prefer a holistic solution |
| 01:17 | <bakkot> | if you think you can convince engines it's worth it, go for it |
| 01:18 | <bakkot> | I'm not going to spend much effort on that myself |
| 01:18 | <bakkot> | I might at some point spend effort specifically on the Array.prototype case though, since it's particularly acute |
| 01:59 | <Justin Ridgewell> | It's still possible that we can do the obvious fix for the override mistake. |
| 01:59 | <Justin Ridgewell> | The attempt we made before was just a counter that an override took place, but not whether it caused any breakage. |
| 02:00 | <Justin Ridgewell> | Lodash triggered the counter, but the function continued to work correctly because of a fallback path. |