├── LICENSE ├── README.md ├── src └── return-override-weakmap.js └── stabilize-talks ├── images ├── 1-current-levels-def.png ├── 2-current-levels-traps.png ├── 3-structs-cant-freeze.png ├── 4-fully-unbundled.png ├── 5-trap-params.png ├── 6-fully-bundled.png └── repo-cover.jpg ├── stabilize-stage1-as-presented-at-structs-group.key ├── stabilize-stage1-as-presented-at-structs-group.pdf ├── stabilize-stage1-as-recorded-at-structs-group.key ├── stabilize-stage1-as-recorded-at-tg3.key ├── stabilize-stage1-status-update-as-recorded.key ├── stabilize-stage1-status-update-as-recorded.pdf ├── stabilize-stage1-status-update.key ├── stabilize-stage1-status-update.pdf ├── stabilize-stage1.key ├── stabilize-stage1.pdf └── title-s1-status-update.jpg /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Stabilize, and other integrity traits 2 | 3 | Better support for high integrity programming by extending the existing system of integrity "levels". 4 | 5 | Proposal for TC39 of new integrity "traits" for mitigating 6 | - The assignment-override-mistake 7 | - The return-override-mistake 8 | - Proxy reentrancy hazards 9 | 10 | 11 | ## Status 12 | 13 | [The TC39 Process](https://tc39.es/process-document/) 14 | 15 | **Stage**: 1 16 | 17 | **Champions**: 18 | - Mark S. Miller (@erights) 19 | - Chip Morningstar (@fudco) 20 | - Richard Gibson (@gibson042) 21 | - Mathieu Hofman (@mhofman) 22 | 23 | ## Presentation history 24 | 25 | - ***for stage 1*** - November 2024 structs working group ([slides.key](./stabilize-talks/stabilize-stage1-as-recorded-at-structs-group.key), [slides.pdf](./stabilize-talks/stabilize-stage1-as-presented-at-structs-group.pdf), [video](https://www.youtube.com/watch?v=VHr4Jvvt0vc)) 26 | - ***for stage 1*** - December 2024 TC39 plenary ([slides.key](./stabilize-talks/stabilize-stage1.key), [slides.pdf](./stabilize-talks/stabilize-stage1.pdf), [docs slides](https://docs.google.com/presentation/d/1474EreKln5bErl-pMUUq2PnX5LRo2Z93jxxGBNbZmco/edit?usp=sharing), [video](https://youtu.be/UX8qLMlO2JY)) 27 | - ***Stage 1 Status Update: Hopes and Dreams*** - February 2025 TC39 Plenary ([slides.key](./stabilize-talks/stabilize-stage1-status-update.key), [slides.pdf](./stabilize-talks/stabilize-stage1-status-update.pdf), [video](https://www.youtube.com/watch?v=oMPeo4faynY&list=PLzDw4TTug5O3vIAd4IR1Gp5t_46co_dv9)) 28 | 29 | ## Background 30 | 31 | JavaScript currently has three integrity levels, *frozen*, *sealed*. and *non-extensible*. These are "levels" because they are currently in a fully-ordered hierarchy: All frozen objects are sealed, and all sealed objects are non-extensible. These are "integrity" levels because they support high integrity programming. 32 | 33 | For example, [Hardened JS](https://hardenedjs.org/) and several other systems `freeze` the *primordial objects*, i.e., those built-in intrinsic objects that exist before code starts running. This supports higher integrity programming by, for example, preventing prototype poisoning, a major source of supply-chain vulnerability. 34 | 35 | However, even for frozen objects, standard JavaScript has the following three unpleasant issues that we'd like to mitigate by introducing new integrity distinctions. These integrity distinctions would be in a partial order rather than a full order, so we shift our terminology to refer to all integrity distinctions as *integrity traits*. (The term is borrowed from a kind of multiple inheritance system, but here it applies to the spec-internal behavior definitions rather than user-level abstraction mechanisms.) 36 | 37 | ### The assignment-override-mistake. 38 | 39 | ```js 40 | Object.freeze(Object.prototype); 41 | 42 | function Point(x, y) { 43 | this.x = y; this.y = y; 44 | } 45 | 46 | Point.prototype.toString = 47 | function () { 48 | return `<${this.x},${this.y}>`; 49 | }; 50 | ``` 51 | 52 | Leaving aside the `Object.freeze` on the first statement, there is a tremendous amount of legacy code on the web resembling the second two statements, where `Point` is a class-like constructor `function` whose instances inherit a `toString` method from `Point.prototype`. In this common legacy pattern, this `toString` method is defined by ***assignment*** to `Point.prototype`, to ***override*** the `Object.prototype.toString`, which the instances would otherwise have inherited. 53 | 54 | However, in an environment in which `Object.prototype` is naive frozen, as in the first statement above, due to the assignment-override-mistake, the assignment in the third statement fails. In strict code it fails with a thrown exception. Even worse, in sloppy code, it fails silently, with the code then proceeding to misbehave. The assignment-override-mistake is that an inherited non-writable data property, such as the `Object.prototype.toString` property after the `freeze` cannot be overriden by assignment to an inheriting object, such as `Point.prototype`. 55 | 56 | The ses-shim implementation of Hardened JS works around this problem for a limited set of primordial properties by first turning them into accessor properties whose setter emulates what the behavior of such an assignment would be had TC39 not made the assignment-override-mistake. However, we only do this for limited set because this technique is expensive, awkward, and non-transparent. 57 | 58 | With this limited workaround, a tremendous amount of existing JavaScript code written with no awareness of Hardened JS nevertheless runs under Hardened JS compatibly. However, the vast majority of existing code that fails to run under Hardened JS fails because of the override mistake. Other systems that freeze the primordials report similar incompatibility. Some systems have given up on freezing primordials, and the resulting integrity benefits, due to these compatibility costs. Indeed, we find that ***the assignment override mistake is the greatest deterrence to higher integrity programming in JavaScript***. 59 | 60 | After extensive investigation, we do not know of ***any*** non-test production code that intentionally makes use of the assignment-override-mistake. Thus, we still hope that it could simply be fixed language-wide without breaking the web. If this turns out to be possible, we would vastly prefer that over this proposal's approach to locally mitigate it, explained below. However, experiments to date did run into an accidental dependency, that still makes web breakage hard to evaluate (TODO links needed). This caused TC39 to back out of an earlier attempt to fix it language-wide. Hence the inclusion within this proposal. 61 | 62 | ### The return-override-mistake 63 | 64 | ```js 65 | class Trojan { 66 | constructor(key) { return key; } 67 | } 68 | 69 | class PrivateTagger extends Trojan { 70 | #value 71 | constructor(key, value) { 72 | super(key); 73 | this.#value = value; 74 | } 75 | } 76 | 77 | new PrivateTagger(freeze(Object.prototype), ''); // adds private field to %Object.prototype% 78 | ``` 79 | 80 | The `Trojan` constructor above ends with an explict `return` of its `key` argument. This has the peculiar effect that calling it as `super(key)` in the `PrivateTagger` constructor treats an explicitly returned `key` object as if it were an instance of `PrivateTagger`, binding it to `this` and initializing it with a private field `#value`. This happens even if the `key` is a preexisting frozen object. The JavaScript spec explains this semantics as-if there is a hidden `WeakMap` within each such class definition. Indeed, [return-override-weakmap.js](./src/return-override-weakmap.js) uses this technique to implement a `WeakMap`-like abstraction. This has several unpleasant consequences. 81 | 82 | ```js 83 | new PrivateTagger(struct, 'a'); // unpleasant shape change 84 | ``` 85 | 86 | All browser JavaScript implementations that we know of implement the addition of such internal fields by shape change of the object, much like their implementation of adding public properties. In V8, for example, both involve changing the object's so-called *hidden class*, which is used for internal bookkeeping of objects with common shapes. 87 | 88 | An engineering goals of [structs and shared structs](https://tc39.es/proposal-structs/) is that all instances of the same (class-like) struct definition have the same statically-knowable shape, enabling compilation of struct methods into higher speed code. However, this would conflict with uses of return override as above, with a struct as key, since the addition of the private field would cause a shape change. In theory this could be fixed in such engines at a cost in additional implementation complexity. This is a cost no one wants to pay to support a "feature" that is widely disparaged anyway. 89 | 90 | ```js 91 | new PrivateTagger(representative, 'a'); // makes gc of virtual objects observable 92 | ``` 93 | 94 | The Agoric platform provides the abstraction mechanisms for defining virtual objects, a kind of virtual memory for objects, where the number of such objects can vastly exceed what can pratically be stored in the JavaScript engine's in-memory heap. Like pages in a virtual memory system, such objects are primarily represented in longer term external storage and "paged in" on demand. In the analogy, the equivalent of a paged-in physical page is a *representative* -- a regular JavaScript object that represents the virtual object, and continues to represent it as long as it is not collected by the language engine's garbage collector. When such a representative is collected, the virtual object still exists in external storage, to be paged back in on demand. 95 | 96 | To maintain the illusion that all these objects are as-if in the language's heap, we need to be careful about object identity, as tested for example by `===`. For `===` specifically, it suffices to ensure that a virtual object never has more that one representative alive at a time. Although each representative has a unique identity at the JavaScript implementation level, `===` can never compare two representatives of the same virtual object because it can only compare objects it retains simultaneously during the comparison. Likewise for object identity comparisons by `Object.is`, `Map`, and `Set`. In particular, a `Map` retains its keys, so a representative used as a key in a `Map` will not be collected. 97 | 98 | The problem arises when a representative is weakly held. There are three mechanisms in JavaScript by which objects can be weakly held: 99 | - `WeakRef` and `FinalizationRegistry`. Our virtual object system reserves these to itself, and does not provide even a virtualization of these to programs running within the virtual object system. 100 | - `WeakMap` and `WeakSet`. If the real `WeakMap` constructor was available to programs running in the virtual object system, a representative as a key could be collected, dropping the association to some value. If the virtual object gets paged back in, the new representative will not be found in that WeakMap, breaking the illusion. 101 | 102 | To uphold the illusion, on initialization, our virtual object system reserves the real `WeakMap` and `WeakSet` constructors to itself, but provide substitute *virtualization-aware* `WeakMap` and `WeakSet` constructors. For non-representative keys, these pass through to the hidden real `WeakMap` and `WeakSet`. For representatives, it collaborates with the virtual object storage system to act as if the virtual object is the key, preserving the association past the lifetime of any one representative. 103 | 104 | - The return-override-mistake makes weakmap-like functionality ***reachable by syntax***, and therefore not pratically virtualizable. If return-override is used with a virtual-object representative as key, the installed private field will observably disappear whenever the representative happens to be collected, to be succeeded by a new representative. Virtualizing this hidden weakmap-like functionality would instead necessitate a painful rewrite to remove all class private fields from the target language. This is too costly to be practical. 105 | 106 | ```js 107 | new PrivateTagger(window, 'a'); // fails only on browser global WindowProxy object 108 | ``` 109 | 110 | Due to the way browsers implement the browser global [WindowProxy](https://developer.mozilla.org/en-US/docs/Glossary/WindowProxy) object, it would be painful for them to support the addition of private fields demanded by the return-override-mistake. Instead, as a special dispensation, browser global WindowProxy objects specifically are exempt from this requirement. 111 | 112 | Such a special exemption is an awkward complexity for a language spec, violates the principle of least surpise, and makes it impractical to perfectly emulate a browser global WindowProxy object using any other object, including the global object of a constructed realm or compartment. 113 | 114 | ### Proxy Reentrancy Hazards 115 | 116 | ```js 117 | function foo(suspect) { 118 | if (!isRecord(freeze(suspect))) { 119 | throw Error(...); 120 | } 121 | // ... suspend invariant ... 122 | ... suspect.bar ... 123 | // ... restore invariant ... 124 | } 125 | 126 | foo(new Proxy({ bar: 3 }), { 127 | get() { foo({}); } 128 | }); 129 | ``` 130 | 131 | For defensive programming we often write functions like `foo` above that check arguments, and then proceed with the body of the function once all arguments have been validated to meet expectations. During the body of the function, there are often sections where some invariant is temporarily suspended, to be restored soon afterwards. For example, a function that splices a doubly linked list must go through a moment where the doubly linked list is malformed. This interval when invariants are suspended is very delicate, and the author should ensure that they only do things they are confident is safe to do during this interval. 132 | 133 | In the example, the author of `foo` first attempts to validate that `suspect` is a record-like frozen plain data object. Had the [records and tuple proposal](https://github.com/tc39/proposal-record-tuple) happened, we could imagine the `recordLike` predicate would simply check `typeof suspect === 'record'`, in which case we would know that `suspect` was primitive data, as safe to access as any other JavaScript primitive data. We could be confident that the `suspect.bar` expression was safe to evaluate even while `foo`'s invariants are suspended, because we'd know that it could not cause the interleaving of other code carried along by `suspect`. 134 | 135 | Inspired by the [records and tuple proposal](https://github.com/tc39/proposal-record-tuple), Endo provides an [`isRecord`](https://github.com/endojs/endo/blob/master/packages/pass-style/src/typeGuards.js#L23) predicate that does as much record-like safety validation as it can in standard JavaScript today. It checks that the object is frozen, inherits directly from `Object.prototype`, and has only string-named own enumerable data properties. Ideally, all this validation would assure `foo`'s author that the expression `suspect.bar` is similarly safe. 136 | 137 | Unfortunately, within standard JavaScript, we have no way to validate that `suspect` is not a proxy, or to ensure that it is not. If it is a proxy, it would still be constrained by the [object invariants](https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-invariants-of-the-essential-internal-methods) to act like a frozen object. The object invariants together with the `recordLike` predicate would guarantee that every time `suspect.bar` is evaluated successfully, it evaluates to the same value. But if `suspect` is a proxy, during that property access it could still execute other code, including code that reenters `foo` while `foo` is unprepared to be reentered. 138 | 139 | Within standard JavaScript today, the only way the author of `foo` can protect against this is either to require that the argument is primitive data (such as a string), or to do a defensive copy up front, before suspending invariants, creating new objects that are known *by construction* to be safe plain data objects. Such defensive copying is expensive. Pervasively defensive programming would require pervasive defensive copying, which is exhorbitantly expensive. 140 | 141 | ## New Integrity Traits 142 | 143 | ![Current integrity traits](./stabilize-talks/images/1-current-levels-def.png) 144 | 145 | We wish to mitigate the three problems above by introducing new integrity traits. But what makes a proposed new feature to be an integrity trait? We propose the following requirements, already followed by the existing integrity traits: 146 | - Monotonic one-way switch. For example, once an object is frozen, it is forever frozen. 147 | - Stronger object invariants, better support for higher integrity programming. For example, we know that the value of an own data property of a frozen object cannot change, even if that object is a proxy or any other exotic object. 148 | - A proxy has a given integrity trait *if and only if* its target has that same integrity trait. For example, a proxy is frozen if and only if its target is frozen. This preserves the feature that *all* the bookkeeping for a proxy's integrity traits are only whether the target has those traits. 149 | 150 | ![Explicit vs Emergent integrity traits](./stabilize-talks/images/2-current-levels-traps.png) 151 | 152 | ```js 153 | > const obj = { x: 8 }; 154 | > !Object.isExtensible(obj); // false 155 | > Object.isSealed(obj); // false 156 | 157 | > Object.preventExtensions(obj); 158 | > !Object.isExtensible(obj); // true 159 | > Object.isSealed(obj); // false 160 | 161 | > delete obj.x; 162 | > !Object.isExtensible(obj); // true 163 | > Object.isSealed(obj); // true 164 | ``` 165 | 166 | Again generalizing from the existing integrity traits, we can divide integrity traits into 167 | - ***Explicit***, such as non-extensible, where the flag of whether a given object is non-extensible is fundamental semantic state that any implementation must explicitly represent. An object only becomes non-extensible if it is explicitly made non-extensible by applying an operation that causes it to become non-extensible. 168 | - ***Emergent***, such as sealed or frozen, where an object has that integrity trait only if a conjunction of other monotonic conditions holds, irrespective of how that conjunction became true. In the example above, `obj` becomes sealed when its own configurable data property is deleted. 169 | 170 | Proxies only need traps for the explicit integrity levels. Indeed, proxies have traps for `preventExtensions` and `isExtensible`, but have no traps for sealed or frozen. 171 | 172 | ### An explicit *Stablize* would mitigate all three problems 173 | 174 | ![First try. But structs cannot be frozen](./stabilize-talks/images/3-structs-cant-freeze.png) 175 | 176 | We first thought to introduce just one new explicit integrity trait, *stable*, to mitigate all three problems, where all stable objects were frozen. However, this would fail to enable [structs and shared structs](https://tc39.es/proposal-structs/) to have efficient fixed-shape implementations. Structs and shared structs are born sealed, but they are not born frozen. But they could only have a fixed shape implementation if they are also born exempt from the return-override mistake. 177 | 178 | We would also be unable to retroactively rationalize the browser global WindowProxy objects exemption from the return-override-mistake, nor enable faithful emulations using other objects, since none of these objects would normally even be non-extensible. 179 | 180 | ![Fully unbundled integrity traits](./stabilize-talks/images/4-fully-unbundled.png) 181 | 182 | Going to the other extreme, let's consider a full unbundling of integrity trait features into separate traits. In this diagram, the underlined bold italic labels are the explicit integrity traits, the other labels are emergent integrity traits, and the arrows between them indicate implication. In this fully unbundled picture, each explicit trait only does one job, and they are more orthogonal to each other. 183 | - ***fixed*** - A fixed object would be exempt from the return-override mistake. The new behavior would follow the existing precedent of the browser global WindowProxy object, so that we could retroactively rationalize it as carrying the fixed trait, and emulations could also be fixed to behave similarly. Structs would be born both sealed and fixed, but not frozen. There is no technical reason for fixed to imply any other integrity trait, though there may be adequate esthetic arguments. 184 | - ***overridable*** - An overridable object would be exempt from the assignment override mistake. This is easiest to specify if overridable implies frozen. We'd simply say that any data property inherited from an overridable object can be overridden by assignment. If overridable does not imply frozen, then it would only change the behavior of either non-writable data properties, or only non-writable non-configurable data properties. This would enable overridable to work for objects in which only some properties were non-writable. 185 | - ***non-trapping*** - Non-trapping is *much* easier to specify (and likely implement) if non-trapping implies frozen, which we will assume here. In that case, a non-trapping object used as a proxy target would cause that proxy never to trap to its handler. Recall that if the target is frozen, the handler traps already cannot change the contents of a successful result. All they can do is interleave other code during the trap, raising reentrancy hazards, or throw, preventing a successful result from being reported. If the target is additionally non-trapping, then the proxy would act as if the handler had no traps, forwarding all operations onto the target. In other words, such a proxy would act exactly like its target in all ways except that it would have a distinct object identity. Following our earlier principles, such a proxy would itself be non-trapping. 186 | 187 | ```js 188 | function foo(suspect) { 189 | if (!isRecord(beNonTrapping(suspect))) { 190 | throw Error(...); 191 | } 192 | // ... suspend invariant ... 193 | ... suspect.bar ... 194 | // ... restore invariant ... 195 | } 196 | 197 | foo(new Proxy({ bar: 3 }), { 198 | get() { foo({}); } 199 | }); 200 | ``` 201 | 202 | An object that is non-trapping might still raise reentrancy hazards if it has accessor properties, or if it inherits from an object that itself raises reentrancy hazards. But if `recordLike` first checked that its argument is non-trapping, in addition to all its other checks, then it would indeed guarantee that a passing object is a record-like plain data object that cannot interleave any foreign code during property access, and thereby cannot raise reentrancy hazards. 203 | 204 | Like proxies, exotic objects are allowed to observably interleave user code or visible effects during access to alleged data properties. Indeed, the module namespace object of the [import defer proposal](https://docs.google.com/presentation/d/1yFbqn6px5rIwAVjBbXgrYgql1L90tKPTWZq2A5D6f5Q/edit#slide=id.p) would do so. An exotic object, like a proxy, can also refuse an attempt to impose a new explict integrity trait on it (for example, a growable array-buffer refuses to be made non-extensible). An exotic object that wishes to preserve this observable interleaving of user code or visible effects during property access must therefore refuse to be made non-trapping. 205 | 206 | This successfully mitigates the proxy reentrancy hazards without introducing a predicate to tell whether an object is a proxy, which would threaten practical membrane transparency. Rather, `recordLike` only needs a predicate to detect whether an object is non-trapping. As with any other integrity trait, this would be transparently reflected from targets to their proxies. 207 | 208 | ### Unbunding non-extensible 209 | 210 | As long as we're considering an extreme unbundling of integrity traits, we could also consider unbundling non-extensible into the explicit orthogonal traits of 211 | - ***permanent-inheritance*** - only provides the feature on non-extensible of locking in what an object inherits from. The benefit is again retroactive rationalization and ability to virtualize: 212 | 213 | - `Object.prototype` is born extensible and inheriting from `null`. By special dispensation, despite that extensibility, its inheritance cannot be changed. 214 | - Likewise, by special dispensation, it is impossible to change inheritance of an extensible browser global [WindowProxy](https://developer.mozilla.org/en-US/docs/Glossary/WindowProxy) object. Because this ability is unavailable to non-proxy objects, they cannot be used to faithfully emulate a browser global WindowProxy. 215 | 216 | By unbundling this feature of non-extensible into a separate explict integrity trait, we could retroactively rationalize both of these, and enable more faithful emulation of the browser global WindowProxy object. 217 | 218 | - ***no-new-props*** - just completes the unbundling, by extracting the remaining feature of non-extensible into a sparate explicit trait. A no-new-props object would be one that cannot grow any new own properties, even though we might still be able to change what object it inherits from. 219 | 220 | ![parameterized proxy protection traps](./stabilize-talks/images/5-trap-params.png) 221 | 222 | With five new explicit integrity traits, it seems we'd need ten new proxy traps. One each to request the integrity trait, and one each to test the integrity trait. This seems too much. Instead, we could introduce just two new parameterized proxy traps, `protect(traitName)` and `isProtected(traitName)`, where the names range only over the explict integrity trait names. 223 | 224 | If we unbundle non-extensible in this way, then non-extensible itself becomes an emergent integrity trait. This raises the compatibility conundrum of what how the existing `preventExtensions` and `isExtensible` proxy traps relate to the new ones. Under what circumstances for an operation on the proxy trap to which handler? We leave this question open for now. 225 | 226 | ### Unbundling and rebunding stable 227 | 228 | In this fully unbundled picture, stable would be emergent, but would still be strongest. Stable would still imply all the other integrity traits. [Hardened JS](https://hardenedjs.org/) would still shift to stabilizing all the primordials, rendering them frozen, exempt from the return-override-mistake, the assignment-override-mistake, and proxy reentrancy hazards. Each trait helps support high integrity programs, by preventing rude non-local surprises. 229 | 230 | However, it makes less sense to keep non-trapping below stable. We initially thought to make non-trapping imply frozen, because once a proxy's target is frozen, the handler no longer has much utility. But if there are integrity levels not implied by non-trapping, then once an object is non-trapping it would no longer be able to intercept an attempt to make it, for example, fixed or overridable, or to test whether it is fixed or overridable. It seems that stable and non-trapping must each imply the other, suggesting that non-trapping should be bundled back into stable, and that stable thereby becomes explicit. 231 | 232 | Although orthogonality is nice, many uses of these integrity traits will only want to use pleasant bundles. If we rebundle as much as possible, while still meeting our compelling use cases, we lose orthogonality, but we potentially have a system that is easier to understand and to implement. What is this minimal picture? 233 | 234 | ![Minimal proposed integry traits](./stabilize-talks/images/6-fully-bundled.png) 235 | 236 | This resembles our first try, with the one difference that the fixed trait, for mitigating the return-override-mistake, is separated from stable. Stable would still imply fixed, but an object could be made fixed without application of any other integrity traits. This picture also omits the unbundling of non-extensible, because the need does not currently seem sufficiently compelling to be worth its cost. The main benefit would be retroactive rationalization of the permanent-inheritance behavior of `Object.prototype` and the browser global WindowProxy objects, as well as enabling a more faithful emulation of WindowProxy without using a JavaScript proxy. 237 | 238 | The most plausible re-unbundling from here would be to again break out overridable and not make it imply frozen. This would mitigate the assignment-override-mistake for non-writable properties inherited from non-frozen objects. This is certainly coherent and simple to understand. This seems like a good question to investigate in Stage 1. 239 | 240 | ## See Also 241 | 242 | [Propose to tc39 without override mistake #105](https://github.com/endojs/endo/issues/105) 243 | 244 | [harden as a new integrity level #1912](https://github.com/endojs/endo/issues/1912) 245 | 246 | [Normative: Make non-writable prototype properties not prevent assigning to instance #1320](https://github.com/tc39/ecma262/pull/1320) 247 | -------------------------------------------------------------------------------- /src/return-override-weakmap.js: -------------------------------------------------------------------------------- 1 | class Trojan { 2 | constructor(key) { 3 | return key; 4 | } 5 | } 6 | 7 | const makePrivateTagger = () => { 8 | const tombstone = Symbol('deleted'); 9 | return class PrivateTagger extends Trojan { 10 | #value 11 | constructor(key, value) { 12 | super(key); 13 | this.#value = value; 14 | } 15 | /** 16 | * @param {any} key 17 | * @returns {boolean} 18 | */ 19 | static has(key) { 20 | try { 21 | return key.#value !== tombstone; 22 | } catch { 23 | return false; 24 | } 25 | } 26 | /** 27 | * @param {PrivateTagger} key 28 | */ 29 | static get(key) { 30 | try { 31 | const value = key.#value; 32 | return value === tombstone ? undefined : value; 33 | } catch { 34 | return undefined; 35 | } 36 | } 37 | /** 38 | * @param {PrivateTagger} key 39 | * @param {any} value 40 | */ 41 | static set(key, value) { 42 | new PrivateTagger(key, value); 43 | } 44 | /** 45 | * @param {PrivateTagger} key 46 | */ 47 | static delete(key) { 48 | try { 49 | key.#value = tombstone; 50 | } catch {} 51 | } 52 | }; 53 | } 54 | 55 | /** 56 | * A `WeakMap`-like abstraction built using the `class` syntax and its support 57 | * for the return-override-mistake. 58 | * 59 | * Because the browser global WindowProxy object is exempt from the 60 | * return-override-mistake by special dispensation, currently, that object 61 | * alone cannot be used as a key in a `WeakishMap`. 62 | * 63 | * @template {object} K 64 | * @template {object} V 65 | */ 66 | export class WeakishMap { 67 | #tagger 68 | constructor() { 69 | this.#tagger = makePrivateTagger(); 70 | } 71 | /** 72 | * @param {any} key 73 | * @returns {boolean} 74 | */ 75 | has(key) { 76 | return this.#tagger.has(key); 77 | } 78 | /** 79 | * @param {K} key 80 | * @returns {V} 81 | */ 82 | get(key) { 83 | return this.#tagger.get(key); 84 | } 85 | /** 86 | * @param {K} key 87 | * @param {V} value 88 | */ 89 | set(key, value) { 90 | this.#tagger.set(key, value); 91 | } 92 | /** 93 | * @param {K} key 94 | */ 95 | delete(key) { 96 | return this.#tagger.delete(key); 97 | } 98 | } 99 | 100 | Object.freeze(Object.prototype); 101 | 102 | function Point(x, y) { 103 | this.x = y; this.y = y; 104 | } 105 | 106 | Point.prototype.toString = 107 | function () { 108 | return `<${this.x},${this.y}`; 109 | }; 110 | -------------------------------------------------------------------------------- /stabilize-talks/images/1-current-levels-def.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/images/1-current-levels-def.png -------------------------------------------------------------------------------- /stabilize-talks/images/2-current-levels-traps.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/images/2-current-levels-traps.png -------------------------------------------------------------------------------- /stabilize-talks/images/3-structs-cant-freeze.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/images/3-structs-cant-freeze.png -------------------------------------------------------------------------------- /stabilize-talks/images/4-fully-unbundled.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/images/4-fully-unbundled.png -------------------------------------------------------------------------------- /stabilize-talks/images/5-trap-params.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/images/5-trap-params.png -------------------------------------------------------------------------------- /stabilize-talks/images/6-fully-bundled.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/images/6-fully-bundled.png -------------------------------------------------------------------------------- /stabilize-talks/images/repo-cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/images/repo-cover.jpg -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-as-presented-at-structs-group.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-as-presented-at-structs-group.key -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-as-presented-at-structs-group.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-as-presented-at-structs-group.pdf -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-as-recorded-at-structs-group.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-as-recorded-at-structs-group.key -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-as-recorded-at-tg3.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-as-recorded-at-tg3.key -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-status-update-as-recorded.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-status-update-as-recorded.key -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-status-update-as-recorded.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-status-update-as-recorded.pdf -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-status-update.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-status-update.key -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1-status-update.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1-status-update.pdf -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1.key -------------------------------------------------------------------------------- /stabilize-talks/stabilize-stage1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/stabilize-stage1.pdf -------------------------------------------------------------------------------- /stabilize-talks/title-s1-status-update.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tc39/proposal-stabilize/1c31f5238372bff38d0e6dc7e1bfbcede632fadd/stabilize-talks/title-s1-status-update.jpg --------------------------------------------------------------------------------