On __proto__ as a magical data property

Andreas Rossberg rossberg at google.com
Wed Jul 18 02:35:39 PDT 2012

On 18 July 2012 09:59, David Bruant <bruant.d at gmail.com> wrote:

> Im my humble opinion, making Object.prototype.__proto__ configurable (and
> actually deletable) [1] should be a much highier priority than choosing
> from data to accessor property.
> As long as Object.prototype.__proto__ is not deletable, a data or accessor
> property does not matter from a security perspective, it's equally terrible.
> From the security perspective, it all boils down to whoever runs first. If
> the attacker runs first, it makes Object.prototype.__proto__
> non-configurable and the defender is likely screwed. If the defender runs
> first, it can "delete Object.prototype.__proto__" and the attacker cannot
> use __proto__ in a nocive manner any longer.
> If Object.prototype.__proto__ is effectively deletable, data or accessor,
> the difference is that if you run first and __proto__ is an accessor, you
> can decide to extract the setter and use it for your own good if you have
> legitimate use cases. Never sharing this capability will keep you safe.

I agree with that. I'm not quite convinced that there are relevant security
implication with an accessor semantics either.

I also don't think that array length counts as proper precedence. Array
length is a magic property _on the instance_, whose magic is limited to
that specific instance, whereas __proto__ would be a magic property _on the
prototype_, thereby introducing _cross-object_ magic. I'd argue that's
quite a different quality. Do we have any precedence for that?

It simply seems entirely incoherent to me that a single _data_ property
should exhibit different values when accessed through different receivers.
>From my perspective, that's a significantly more fundamental violation of
the JS object model than the magic that comes with array length.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120718/705e5b31/attachment.html>

More information about the es-discuss mailing list