As a follow-up to the fixed properties proposal:<div><br></div><div>I created a prototype implementation of fixed properties on top of the existing Proxy API. The idea is to wrap an existing proxy handler in a FixedHandler. This FixedHandler does the bookkeeping and checking to ensure that the wrapped handler doesn't misreport non-configurable properties.</div>

<div><br></div><div>Full source code available here: <<a href="http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/FixedHandler.js" target="_blank">http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/FixedHandler.js</a>></div>
<div><br></div><div>I also adapted David Bruant's self-hosted implementation of Arrays using Proxies <<a href="https://github.com/DavidBruant/ProxyArray">https://github.com/DavidBruant/ProxyArray</a>> to use the above FixedHandler. Things appear to work out nicely: <<a href="https://github.com/tvcutsem/ProxyArray">https://github.com/tvcutsem/ProxyArray</a>> is a self-hosted implementation of Arrays using proxies with fixed properties.</div>
<div><br></div><div>"length" appears to be faithfully emulated, but this could use more testing. See <<a href="https://github.com/tvcutsem/ProxyArray/blob/master/Arrays.html">https://github.com/tvcutsem/ProxyArray/blob/master/Arrays.html</a>> for an initial testcase.</div>
<div><br></div><div>Cheers,</div><div>Tom</div>
<div><br><div class="gmail_quote">2011/6/22 Tom Van Cutsem <span dir="ltr"><<a href="http://tomvc.be" target="_blank">tomvc.be</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

We haven't actually revisited the membrane code in light of the fixed properties strawman.<div><br><div>One change that I can imagine being made, is that a membrane wrapper, when first created, explicitly copies over the non-configurable properties of its target (this is similar to what the "wrap" method does in <<a href="http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties" target="_blank">http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties</a>>). After this initialization, the handler can set a flag that disallows any further properties to be defined via the defineProperty trap. That would disallow untrusted code from defining new properties on the wrapper.</div>


<div><br></div><div>Regardless of whether this would work or not: it sure is introducing a lot of complexity in the already complex membrane code, which is not what I would call progress!</div><div><br></div><div>Cheers,</div>


<div>Tom</div><div><div></div><div><div><br><div class="gmail_quote">2011/6/22 David Bruant <span dir="ltr"><<a href="mailto:david.bruant@labri.fr" target="_blank">david.bruant@labri.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Le 22/06/2011 10:14, Tom Van Cutsem a écrit :<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It just occurred to me that the security issues you describe re. fixed properties & membranes may not be as bad as we first thought they were.<br>
<br>
<br>
Because of the recursive wrapping of the membrane code, all of the get/set/value attributes of fixed properties will contain wrappers themselves. So, after revoking a membrane, untrusted code will still have access to the structural information of these properties, but won't be able to do anything useful with its values (they are revoked wrappers themselves). The structural information itself does not convey any useful authority to the untrusted code.<br>



<br>
</blockquote></div>
It does leak that the property exists (because a value is returned instead of throwing inconditionally). It doesn't sound very dangerous and exploitable, but it's a leak.<div><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The wrapper may still "leak" previously exposed information (e.g. primitives are not wrapped), but the untrusted code could retain access to this information regardless (even if we switched to validating proxies).<br>



<br>
</blockquote></div>
The wrapper can also leak previously unexposed information (not for one piece of untrusted code, but at least two). That was the point of the adjustement of my example:<br>
( 0) Untrusted code 1 and 2 have a reference to the wrapper w )<br>
1) Untrusted code 1 does: Object.defineProperty(w, 'p', {configurable:false, value:1})<br>
2) Trusted code closes the gate<br>
3) In Untrusted code 2: 'p' in w === true<br>
<br>
Before 1), this 'p' property wasn't exposed to Untrusted code 2. Closing the gate on 2) should prevent everyone (like Untrusted code 2) who hadn't seen 'p' before gate-closing to see it afterward. It is not big, but it allows two pieces of untrusted code to communicate (more than they would if the trap was called and threw right away).<br>



<br>
The easy workaround is to hand a different wrappers to different untrusted codes, but duplicating the number of necessary objects to guarantee security is an unfortunate workaround.<br><font color="#888888">
<br>
David</font><div><div></div><div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, long story short: I don't think proxies with fixed properties weaken the actual security afforded by membranes, but I fully agree that the fact that information is lingering in revoked proxies is surprising.<br>
<br>
<br>
Cheers,<br>
<br>
Tom<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>