built-ins that make virtual calls

[michaelficarra]

There are some built-ins that make virtual calls, meaning invoking that built-in on objects that are completely under your control could still invoke user code (other than through the usual toString/valueOf). Is this surprising to language users? Are there scenarios where this would lead to a programming trap with security consequences? An example is Array.prototype.toString making a virtual call to Array.prototype.join.

edit: I open this because we were discussing whether we should encourage this pattern to better support the subclassing of built-ins, and @syg suggested there might be security reasons why we would want to avoid it.

[syg]

Clarifying, I think virtual calls have the same shape of security risk as adding extra hook points, which as a general category has been responsible for security bugs often due optimizing JITs making incorrect assumptions. It'd be interesting to discuss if virtual calls like this are any better or worse than other kinds of hook points.

[ljharb]

https://tc39.es/ecma262/#sec-array.prototype.tostring

I don’t think it’d be surprising to users, because virtually nobody ever subclasses Array at all, let alone does that and overrides .join and doesn't override toString.

It seems very important to me to minimize observable lookups like this; if we wanted “joinable” to be a protocol then we should make it one, but we don’t. It’s the same problem with Map/Set calling set/add, and regexes calling .exec.

I would be interested to determine if it was web compatible to change this observable call to call the join intrinsic instead (especially given that the intrinsic, like toString, works on any array like).

[bakkot]

For hook points: another example here is something like Set.prototype.difference, where you might want to access methods like has on an argument rather than (or in addition to) on this. Do these have the same sort of security implications as hook points on this?

[ljharb]

When possible, I’d hope arguments could be converted to builtins, and then the intrinsics on those builtins used. In the case of set methods, where presumably we want them to take iterables, they wouldn’t necessarily have such a method - but if added to a new Set, then the intrinsic could be used there.

[bakkot]

If the argument already has a has method, it seems like it would be pretty weird to iterate over all of its contents rather than just invoking its has directly.

[ljharb]

I think it’d be weirder to create a brand new “has-able” protocol just because that’s the functionality we happen to need.

[bakkot]

I don't think that treating the argument to Set.prototype.difference like it's a Set really amounts to creating a protocol. And I would be pretty opposed to the idea of making these operations big-O slower just because we don't like reading named properties from arguments rather than just from this.

[caridy]

cc @erights since we have discuss some topics related to this in the past, specifically, the difference between using internal slots vs generic operations (virtual calls) that can be seen like protocols for interacting with objects.

[caridy]

As for membranes, and proxies in general, virtual calls (or generic operations as we call it in SES meetings), they are great because you can throw a proxy on top of an array, and it still works the same way.

[ljharb]

In the toString/join case tho, it'd continue to work the same way even if it was the intrinsic join, no?