-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative "Delete the __proto__ and * keys" non-viable #4
Comments
We agree disabling static property access like |
I wouldn't call it intuition given multiple CI attempts failing at this area. I think various tooling like closure compiler forcing computed property access to prevent mangling would make this unlikely in a different area if that is your question. I think any time |
Ah okay. Whenever you get a chance, an instance of a CI failure would be interesting to look at. |
@syg we don't keep them for multiple years but you can see some stuff at a glance from nodejs/node#39824 (comment) |
Hey Bradley, sorry for the late reply. I took a closer look at toolchains that produce code that is not directly compatible with this proposal and have updated the proposal to reflect what I've found. Please take a look at the updated content. In general, it seems that the majority of public websites on the Internet would be compatible with this out of the box, but there is a non-negligible portion that would need to be refactored. That is a deal breaker for enabling secure mode by default, since it isn't backward compatible. The salient point here is that applications that are not compatible are more prone to being vulnerable, so by refactoring an application into compatibility, developers are reducing the places where computed properties have unintentional effects. On the one hand, public crawl data indicates that many toolchains are compatible by default and on the other it points at the fact that there are well-lit paths to refactor incompatible toolchains into compatibility. For example, instead of producing What seems more worrying to me is the point that external specifications have references to constructors embedded in them. I have been able to find 2 types of references: 1) where a spec asks 'what is the constructor of x' and 2) where a spec asks 'is this object a constructor'. I believe the second type will be incompatible with secure mode. It would be very useful to hear feedback, especially on this last point, since I'm not sure that I understand all of its implications. |
Global disabling of
.prototype
and.constructor
keys is unlikely to be viable. Node does have--disable-proto
that it wished to turn on by default and even then the ecosystem has struggled to make it work (last run of our ecosystems tests still had it failing). I think deleting of__proto__
is possible but harder than framed given attempt to do so already.Unfortunately due to some specifications like web components properties on these are intended to be accessed and would require major shifts to make them change not just in specifications but also in polyfills etc. See https://html.spec.whatwg.org/multipage/custom-elements.html#element-definition
The text was updated successfully, but these errors were encountered: