Re: [heycam/webidl] Modernize invoking user code (#113)

> @@ -6368,6 +6390,17 @@ iframe.appendChild instanceof w.Function;  <span class='comment'>// Evaluates to
>                for Web pages.
>              </p>
>            </div>
> +
> +          <p>
> +            Although at the time of this writing the ECMAScript specification does not reflect this,
> +            every ECMAScript object must have an <dfn data-export=''
> +            id='dfn-associated-realm'>associated <a class='external'>Realm</a></dfn>. The mechanisms
> +            for associating objects with Realms are, for now, underspecified. However, we note that
> +            in the case of <a class='dfnref' href='#dfn-platform-object'>platform objects</a>, the
> +            associated Realm is equal to the object's <a class='external'>relevant Realm</a>, and
> +            for function objects the associated Realm is equal to the Realm returned by <a
> +            class='external'>GetFunctionRealm</a>.

I thought about pretty hard, and I am really not happy with the way this ends up working for proxies.

If the intent is to capture "the realm of the code that will actually run" then defining the realm in this way for a callable proxies is pretty suboptimal.  If you just get your hands on any callable from some realm, you can pretend like code from that realm will run while actually running code of your own choosing, by simply implementing the "apply" trap.

I would much rather we ended up handling a callable proxy the same way we handle a function that (possibly) ends up calling another callable inside of itself instead of trying to peek through it like this.

Changing GetFunctionRealm doesn't seem viable given its uses in ArraySpeciesCreate  and GetPrototypeFromConstructor.  But that means maybe we don't want GetFunctionRealm here.

Note that this is primarily a worry for me because I associate certain security guarantees with this stuff.  If none of the uses involve security checks, then it may not matter as much.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/113/files/6a54acae5c1ff4199b5bf85b61bc4681addbafb7#r63773408