proposal-class-fields icon indicating copy to clipboard operation
proposal-class-fields copied to clipboard

Clarify that private fields can be accessed from within eval

Open littledan opened this issue 7 years ago • 6 comments

@caitp ran into some ambiguity in the way the specification is worded here. I'm not sure whether we need a fix per se (e.g., #40), or whether we just need to add more notes to make it more clear.

littledan avatar Apr 30 '18 22:04 littledan

I don’t think it’s worded ambiguously, I had just assumed that the algorithm was consistent between the 2 versions of eval where it comes up, and only really looked carefully at one instance (CreateDynamicFunction).

I still maintain that exposing private fields to eval() is a bad idea.

caitp avatar Apr 30 '18 22:04 caitp

We discussed whether private fields should be available in eval in the November 2016 TC39 meeting. Unfortunately, the notes are rather sparse; my recollection is that, after I tried to argue that private fields should not be available in eval, @ajklein made the argument that it would be surprising if we didn't permit them, given that other new features like let-scoped variables are available in eval.

littledan avatar Jun 09 '18 23:06 littledan

I would argue that you should be able to access private fields from eval for the same reason that you can access them from arrow functions in methods. You cannot call an arrow function with a different this value, and an eval has access to the same this context as an arrow function.

puppy0cam avatar Sep 14 '19 00:09 puppy0cam

I would argue that you should be able to access private fields from eval for the same reason that you can access them from arrow functions in methods.

that might be something you'd want to explicitly allow with a CSP relaxer option, rather than a default --- even if you explicitly allow evaluating strings, you might not want them to access private stuff.

I don't feel strongly about this, just throwing that out there

caitp avatar Sep 14 '19 00:09 caitp

if you explicitly allow evaluating strings, you might not want them to access private stuff.

Developers have been taught to treat eval as if it were run with the same privileges as the caller. I think it should stay consistent with current standards, and eval should only gain access to private fields when it would also gain access to local variables.

puppy0cam avatar Sep 14 '19 01:09 puppy0cam

To clarify, the current specification does allow private fields and methods to be accessed from inside eval. This issue tracks making the specification editorially more clear on that point.

littledan avatar Sep 14 '19 08:09 littledan