✏️ fix 2021 notes

tc39 · Oct 19, 2023 · e06bd16 · e06bd16
1 parent 18ba347
commit e06bd16
Show file tree

Hide file tree

Showing 24 changed files with 2,089 additions and 1,901 deletions.
diff --git a/.markdownlint-cli2.jsonc b/.markdownlint-cli2.jsonc
@@ -5,7 +5,7 @@
   "ignores": [
     "node_modules/**",
     "meetings/201*/*.md",
-    "meetings/202[0-1]*/*.md",
+    "meetings/2020*/*.md",
     "scripts/test-samples/*"
   ]
 }
diff --git a/meetings/2021-01/jan-25.md b/meetings/2021-01/jan-25.md
diff --git a/meetings/2021-01/jan-26.md b/meetings/2021-01/jan-26.md
diff --git a/meetings/2021-01/jan-27.md b/meetings/2021-01/jan-27.md
diff --git a/meetings/2021-01/jan-28.md b/meetings/2021-01/jan-28.md
diff --git a/meetings/2021-03/mar-10.md b/meetings/2021-03/mar-10.md
diff --git a/meetings/2021-03/mar-9.md b/meetings/2021-03/mar-9.md
diff --git a/meetings/2021-04/apr-19.md b/meetings/2021-04/apr-19.md
diff --git a/meetings/2021-04/apr-20.md b/meetings/2021-04/apr-20.md
diff --git a/meetings/2021-04/apr-21.md b/meetings/2021-04/apr-21.md
diff --git a/meetings/2021-05/may-25.md b/meetings/2021-05/may-25.md
diff --git a/meetings/2021-05/may-26.md b/meetings/2021-05/may-26.md
diff --git a/meetings/2021-07/july-13.md b/meetings/2021-07/july-13.md
diff --git a/meetings/2021-07/july-14.md b/meetings/2021-07/july-14.md
diff --git a/meetings/2021-07/july-15.md b/meetings/2021-07/july-15.md
diff --git a/meetings/2021-08/aug-31.md b/meetings/2021-08/aug-31.md
diff --git a/meetings/2021-08/sept-01.md b/meetings/2021-08/sept-01.md
diff --git a/meetings/2021-10/oct-25.md b/meetings/2021-10/oct-25.md
diff --git a/meetings/2021-10/oct-26.md b/meetings/2021-10/oct-26.md
diff --git a/meetings/2021-10/oct-27.md b/meetings/2021-10/oct-27.md
diff --git a/meetings/2021-10/oct-28.md b/meetings/2021-10/oct-28.md
diff --git a/meetings/2021-12/dec-14.md b/meetings/2021-12/dec-14.md
diff --git a/meetings/2021-12/dec-15.md b/meetings/2021-12/dec-15.md
diff --git a/meetings/2023-01/jan-30.md b/meetings/2023-01/jan-30.md
@@ -596,7 +596,7 @@ RPR: I think we can move on. The first question is from JHD.
 
 JHD: Yeah, I mean, all the examples in your slides if you opt into a secure mode, you have to know to do that - and if you know to do that, then you also salt your keys, or use `Object.create(null)` or `{ __proto__ null }`, or use a `Map` or something. Unless you turn on the mode by default, I don’t think it would really achieve any of the goals you want. node, for example, already has a flag that lets you remove the `__proto__` accessor and you can run it with that - but lots of arbitrary modules in the ecosystem rely on the functionality. I’m incredibly confident that trying to do this by default would break the web in sufficient quantities that it wouldn’t be viable. I don’t see a lot of value in if it’s required to be opt in, that said, obviously the exploration area is great. Even though the number of prototype pollution attacks that turn into real exploits is nonzero, I think it’s small, but still worth addressing.I feel like the biggest benefit would be removing a bunch of false positive CVEs from the ecosystem that cost a lot of developers’ time. But either way, I mean, I think it’s worth exploring - that’s a stage 1 concern - but I wanted to share my skepticism.
 
-SYG: Noted. I want to lean on SDZ to provide a more detailed answer here. But I want to respond first to this node flag thing. So our hunch is that we’re not saying we’re going to remove `__proto__` entirely. The idea is that this is a two-parted approach where we realize having .property access to **proto** to .prototype to constructor to keep it working. The way we propose that is with automatic rewriting so we don’t have to manually migrate the entire code base. The other thing about using none prototype objects I think that speaks to the at scale deployment thing. If you had the luxury of time and whatever to basically re rewrite your whole world, then yes you could just never use prototype inheritance at all. That seems a challenge in itself. But at the very least we want to use third party libraries, you can’t really do that. As an application you could opt in the mode. With the automatic rewriting you get the benefits for free. We share your concern. Without the automatic rewriting step that that pure opt in will be difficult to get deploying and working. SDZ, do you have anything to add here?
+SYG: Noted. I want to lean on SDZ to provide a more detailed answer here. But I want to respond first to this node flag thing. So our hunch is that we’re not saying we’re going to remove `__proto__` entirely. The idea is that this is a two-parted approach where we realize having .property access to `__proto__` to .prototype to constructor to keep it working. The way we propose that is with automatic rewriting so we don’t have to manually migrate the entire code base. The other thing about using none prototype objects I think that speaks to the at scale deployment thing. If you had the luxury of time and whatever to basically re rewrite your whole world, then yes you could just never use prototype inheritance at all. That seems a challenge in itself. But at the very least we want to use third party libraries, you can’t really do that. As an application you could opt in the mode. With the automatic rewriting you get the benefits for free. We share your concern. Without the automatic rewriting step that that pure opt in will be difficult to get deploying and working. SDZ, do you have anything to add here?
 
 SDZ: Yeah. I want to speak up about the idea of using create null or the literal prototype null as an integration for this. I think it’s important to understand why we think that doesn’t work. We did a few experiments with this. We found a few problems with it. So the first one is you might create an object (inaudible) that doesn’t have any prototype and you think that is secure until some function at to the object might be array or number or string or maybe another object and now that has a prototype prototype, right? What you’re doing is essentially moving the goalpost one level deeper, right? And you really don’t have a way of creating let’s say a string with no prototype or a number with no prototype or array with no prototype. All of which could be polluted if they went into a common practice function. This is code and only protecting one object apart from sort of the issues that you would have in deploying it that is sort of find everywhere where I have an object literal and replace it with this which is granted sort of something that you can do and with the person speaking and saying if you’re willing to do that you are willing to do (inaudible) but I think those would be the strongest reasons why that solution is not good enough.