Formalize [[Realm]] internal slot of ordinary objects

[annevk]

Per @domenic all implementations already have this. The web platform uses this slot for certain security checks. whatwg/html#473 (comment) has a bunch of the details.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24652 is the issue for formalizing this in IDL, but since it appears that this is larger than platform objects this issue would logically supersede it.

(If we indeed add this, HTML will need to modify its structured clone algorithm as that assumes ordinary objects have two internal slots.)

[domenic]

So from my perspective the work here is:

• Confirm that what I've heard from several implementers is in fact universally true (that all objects have a [[Realm]] slot).
• Find every instance of object creation in the ES spec and set the Realm slot appropriately. (In general, it's probably something like "the current Realm at the time of object creation".) Validate this by either inspecting/consulting implementations, or by using some of the web platform mechanisms that allow you to detect an object's realm (by adding a handleEvent method to the object, and passing it to addEventListener, and then using something like postMessage to detect the entry global inside the event listener once the event is dispatched, since entry global is based on the realm of the object that has the event listener).
• Ensure that we take care of some special cases:
  • All functions should match GetFunctionRealm(), which notably "follows" proxy targets and bound function object targets
  • Probably in general the realm of a proxy should be the realm of its target, not the current realm at the time of proxy creation?

I am pretty sure this is all layering work, and not observable purely within ES. But it would be good to discuss such a project with the larger community.

[domenic]

We have had some internal discussions on this that I would like to start making public. I can't easily find all the relevant Chrome peoples' GitHub handles so I'll just send them a link. In the meantime, pinging @bzbarsky @bholley.

Background information: realm/settings object/global are 1:1:1. See the spec if you are interested in more background reading.

---

It is my understanding V8 and Blink would like to remove the [[Realm]] slot that all objects have (called "CreationContext" in V8), and leave it only with functions, and possibly platform objects. So the plan above, to formalize [[Realm]] for all objects, would be moving in the wrong direction.

Right now, as far as I know, [[Realm]] needs to exist on all objects in order to correctly set up the entry concept. The entry concept is used in many places in various web specs, but we would like to get rid of it in favor of current and relevant. Some examples of places it is currently used are:

• Disallowing programmatic clicking on <a download>
• Cross-origin checks for window.frameElement
• URL parsing and security checks in window.open()
• Plus many many more.

The reasoning why defining entry requires every JavaScript object to have a [[Realm]] is basically that when doing

const o = { handleEvent: f };
addEventListener("foo", o);

we want the entry realm to be that of o, not that of f. I think the reasoning was that we need to set up an entry realm while performing Get(o, "handleEvent") anyway. That is, we need to set up an entry realm while the potential getter is run, so o is the natural choice. Maybe @bzbarsky can give more info or correct me...

---

With this in mind I see two options for allowing the Chrome team to get rid of the per-object [[Realm]] pointer:

• Tweak the definition of entry to not require per-object realms. That might mean that the entry realm is "wrong" while running any handleEvent getters. I think that is probably OK? I am not sure my understanding is 100% though.
• Start the process of eliminating all usage of "entry" from web specs. This would mean writing up a bunch of tests to see what various browsers do in the various situations that currently use entry, and seeing if things are incompatible enough to change.

We could do both of these in parallel, of course.

[bzbarsky]

Maybe @bzbarsky can give more info or correct me

I think you got all the relevant bits.

To the extent that entry stuff is used for security checks of any sort, having it "wrong" is obviously bad. On the other hand, using entry in anything resembling security checks is a pretty suspect thing to do in general. For example, I think the frameElement definition is wrong and should use either incumbent or current settings (the differences between the two in this case are rather subtle if detectable at all; I'd have to think about whether they're detectable). I'm not sure why it uses entry....

That said, how would you tweak the definition to make handleEvent work? You need to set up some entry global; pretty much everything depends on there being at least something there. You need to do this before you do the [[Get]]. The simple (yeah, I know, bear with me) case you describe can be addressed by doing [[GetOwnProperty]] and checking the descriptor for an accessor and then using the accessor's global as the entry object. But if someone does:

addEventListener("foo", someProxy);

I think you're out of luck. Trying to get pretty much any sort of information out of someProxy will run page code and expect an entry global to exist.

You could try to change the entry global in this case to that of the EventTarget involved, but that's basically walking back on a pretty long-standing agreement about whether entry globals represent the thing being invoked or the thing doing the invoking. Maybe that's survivable, especially if the EventTarget is only used as entry global for the [[Get]]. We'd need to change all the places that use callback interfaces in specs to pass in this extra bit of information to use for the [[Get]] and [[Set]] of course.

Note that we would still need a Realm association on callable objects of all sorts, not just functions, for the main call itself.

[bzbarsky]

Note also that it would be really good to have someone from WebKit/JSC and Edge/Chakra involved in this conversation.

[littledan]

cc @verwaest @bterlson @msaboff

[annevk]

Let's dupe this into the more recent #1333.