[[Extensible]]and Proxies (Was: Proxy.isProxy )

Tom Van Cutsem tomvc.be at gmail.com
Fri Jul 15 03:51:49 PDT 2011


Hi Allen,


While proxies are definitely designed to emulate some of the peculiar
behavior of host objects, that does not necessarily imply that proxies
should be as powerful and free of restrictions as host objects. If any JS
script can create a proxy, and a proxy can violate invariants that do hold
for built-in Object or Function values, the logical implication is that
Javascript code, in general, can no longer rely on those invariants. Code
that does can then more easily be exploited.


Consider a non-configurable, non-writable data property. The binding of such
a property for regular objects is guaranteed to be immutable. Immutability
can be used for caching purposes, but is equally useful to not have to adopt
a defensive coding style (as a point in case, take Mark's implementation of
the structured clone algorithm in JS. Such defensive coding would be
unnecessary when dealing with frozen objects.) In a security context,
immutability may be used to determine whether or not to allow some
third-party code to access an object.


In short, if proxies could violate the semantics of e.g. frozen objects,
then it seems to me that the usefulness of that concept is severely
crippled. Where Object.isFrozen would have been a test for guaranteed
immutability (of an object's structure), it merely becomes a test that hints
at it, but cannot be relied upon.


Cheers,

Tom

2011/7/15 Allen Wirfs-Brock <allen at wirfs-brock.com>

>
> On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote:
>
> On Thu, Jul 14, 2011 at 3:00 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>
>>
>> On Jul 14, 2011, at 1:19 PM, Mark S. Miller wrote:
>>
>
> Do you really think it makes sense to allow new properties to appear on
> non-extensible objects? Really?
>
> Perhaps you do. Again, unless and until we get agreement to clean up these
> (irregularities, inconsistencies, features, whatever you want to call them)
> in 8.6.2, ES5.1 is, as you say, what it is. I hope we can do better.
>
>
> Prior to ES5, [[Extensible]] did exist.  We added it in a manner that was
> consistent for native objects.  We may have over-stepped in requiring that
> host objects have such an internal property when in the past they didn't.  I
> don't think there is any fundamental necessity that such an internal
> property exists for host objects or that it is possible to be able to place
> a host object into a state where properties cannot be added. I not sure that
> DOMs violate this, but I'm also not sure that they don't.
>
> If an object (whether native or host) has such a state, then it clearly is
> a bug if new properties can be added when the object is in such a state.
>  But is it a critical safely bug that must be proactively detected and
> prevented?  I not yet convinced that it is or that the benefit of
> proactively guaranteeing  that such an invariant cannot be violated is worth
> the cost.
>
>
>
>>  and the host object invariants are incomplete and hard to make impossible
>>> to violated.
>>>
>>
>> Host objects are part of the platform. A platform provider is free to
>> violate any part of the spec they like, and there's nothing we can do about
>> it other than to add tests to std test suites to make the violations obvious
>> to the community.
>>
>>
>> We could provide a defined interface mechanism that validates constraints
>> or limits behavior in a way that guarantees the desired invariants. That's
>> what Proxies appear to be trying to do, why not do it for host objects.  If
>> you can depend upon host objects actually supporting your invariants why
>> does not matter whether or not Proxy objects also do so.
>>
>
>
> I think this is key to the whole discussion, as you and I have discussed
> verbally. The main use case you seem to be thinking in terms of is Mozilla's
> own use, as a platform provider, of the proxy mechanism as a way to replace
> your current mechanisms for providing host objects. This is a laudable goal
> which I fully support. However, for your use as a platform provider, it is
> legitimate for you to provide yourself dangerous shortcuts that we cannot
> expose to untrusted code, given that you take responsibility for not abusing
> these dangerous shortcuts.
>
>
> No, that is just one use case.  However, in general I think the ability to
> use intercession to produce interesting object semantics is a valuable
> feature that has various uses include hosting other languages.  However, I
> am content to leave the maintenance  of complex invariants up to the
> implementors of such object semantics and to tolerate any failure to do so
> as user bugs alongs as they can't violate memory safety.
>
>
> For clarity, let's take an extreme example: peek and poke. For those who
> missed the history, peek and poke <
> http://en.wikipedia.org/wiki/PEEK_and_POKE> were primitives in some Basics
> for providing direct unchecked access to raw memory. If you, as platform
> providers, wanted to provide yourself with peek and poke operations in order
> to gain some efficiency or whatever, there's nothing fundamentally wrong
> with that. But clearly, no matter what the gains, that shortcut should never
> be exposed to untrusted code.
>
>
> We aren't talking about implementation private extensions and we aren't
> talking about peek and poke which which can be used to violate fundamental
> memory safety invariants in any program.  I don't see the issues we are
> talking about as involving invariants of such universal significance or
> which are exploitable in the same broad manner.  If there are equivalent
> severity exploits that you are concerned about I haven't heard what there
> are yet.
>
>
> This also demonstrates out why the notorious Chapter 16 exemptions need to
> be tightened. As currently written, a platform could provide peek and poke
> as native methods without violating the spec. However, so far I am at a loss
> on how to tighten this up so that it is neither too tight for agreement nor
> too loose for safety. Perhaps this is the real 4.3.28 issue you were raising
> above?
>
>
> I would be quite open to specifying   memory safely invariants. I'm don't
> think there are many others of equal significance.  Chapter 16 needs to be
> very loose or it would prevent most future extensions to the language.
>
> Allen
>
> _______________________________________________
> 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/20110715/57f929cb/attachment.html>


More information about the es-discuss mailing list