Distinguish between absent and inaccessible slots?

[ljharb]

Currently the proposal seems to simply say both cases throw a ReferenceError - however, there's nothing preventing an implementation from throwing a different message - ie, distinguishable error instances - in each case.

This seems like an important security consideration. Should the spec have normative text that requires implementations throw the a ReferenceError with the exact same observable characteristics?

(ping @erights)

[allenwb]

Note that the current document isn't a normative specification. It is simply a Stage 0 strawman proposal whose intent is to provide an informal description sufficient for advancing to Stage 1 which is thee point in the TC39 process where spec, level work would normally start.

ECMA-262 has never mandated such things about the message associated with an exception. I would be useful to get further feedback for security focused people on how making this distinction observable would be exploitable. (are there already existing points in ES6 where this is a problem?)

It isn't clear to me that, at least for the base cases of this proposal, there is anything useful that could be done with that knowledge that you couldn't accomplish without it. I'm less sure if that would be the case if we added the "friend" access; ideas.

[ljharb]

If I can distinguish between "absent" and "inaccessible" slots, then I can, knowing the implementation of a "class", develop a fingerprint of it, that I can use to change runtime behavior if it is refactored to remove any of the slots I'm previously aware of (without relying on a toString/toSource approach, of course).

This seems to me like the same class of security bug/information leak as a login system indicating that the password is wrong but that the email is correct - or as a website responding with a 403 rather than a 404, thus indicating that the account exists but the necessary permissions aren't there - or as a service listening on ports to close a connection rather than allowing it to time out when it's being port scanned.

[allenwb]

Yes, but does that level of concern really apply to the internals of a program? I skeptical but would like to hear Mark Millers thoughts.

[ljharb]

If not, then why the need for true privacy at all?

[zenparsing]

I don't understand the distinction between absent and inaccessible. A valid lexical declaration of a slot name implies access to the slot keyed on that name. If you have a slot key, then for a given object you can determine whether or not it has that slot.

[allenwb]

I think @zenparsing is right here. Knowing the name assigned to a private slot is not enough to probe for the existence of a slot The only way to probe for a specific private slot is using a method that is defined in the body of a class that has access to that slot. If you apply such a method to an object that has the slot, the access will succeed. If you apply it to an object that does not have the slot, the access will fail ("access to non-existent slot"). There is no way to get "the slot exists but you can't access it"