Membranes, unmediated access to objects through Object.getPrototypeOf

Brandon Benvie brandon at brandonbenvie.com
Mon Oct 8 03:06:55 PDT 2012


Another issue with membranes and incomplete trap coverage is mutations to
[[proto]]. An implementation of this would be to  automatically wrapIfDry
whatever the result of getPrototype is which isn't possible under the
current rules without using a dummy target.

On Mon, Oct 8, 2012 at 5:42 AM, David Bruant <bruant.d at gmail.com> wrote:

> Hi,
>
> Proxies enable the implementation of membranes [1]. It's one motivating
> use case of proxies. Useful membranes mediate access to every object which
> was reach from another object in the membrane.
> I realize now that Object.getPrototypeOf violate this principle in harmful
> ways:
>
>     function C(){}
>     var wrappedC = wrap(C);
>
>     // Thanks to the wrapping get trap, we have:
>     wrappedC.prototype !== C.prototype
>
>     // Now, consider:
>     var wrappedCInstance = new wrappedC(); // created a cInstance as target
>
>     // Because of the getPrototypeOf invariant, we have:
>     Object.getPrototypeOf(wrappedCInstance) ===
> Object.getPrototypeOf(cInstance)
>
>     // worse:
>     Object.getPrototypeOf(wrappedCInstance).constructor === C // and not
> wrappedC !!
>     // It's still possible to delete C.prototype.constructor for this
> case, but
>     // the least undeleted .constructor can yield unsecure code...
>
> Basically, the getPrototypeOf invariant provides unmediated access to
> prototype objects which sounds like an abusive amount of authority.
>
> I suggest to revise the getPrototypeOf invariant from
>     "the trap result must me target.[[Prototype]]"
> to:
>     "the trap result must be either target.[[Prototype]] or a proxy which
> has target.[[Prototype]] in its target chain"
>
> For the definition of "target chain" (or "proxy chain"):
> https://mail.mozilla.org/pipermail/es-discuss/2012-September/025135.html
>
> This new definition would enable wrapping Object.getPrototypeOf calls and
> allow preserving the following equality:
>
>     Object.getPrototypeOf(new wrappedC()) === wrappedC.prototype
>
> because as the proxy proposal is, this equality cannot be true any longer.
>
>
> This flaw was here since the original proxy design in which
> Object.getPrototypeof was untrapped and I think justifies in itself the
> addition of the getPrototypeOf trap regardless of the whole __proto__ story.
>
> This flaw gives me an impression of "elephant in the room" that we've
> missed.
> Over time, I've gained a certain level of intimacy with the proxy spec and
> I can't help having this feeling of "what else are we missing?". I don't
> have the answer, i'm still searching, but if we've missed this elephant the
> whole time, I can't help thinking that the proxy spec needs more attention.
>
> David
>
> [1] http://soft.vub.ac.be/~tvcutsem/invokedynamic/js-membranes
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121008/3b0145a4/attachment.html>


More information about the es-discuss mailing list