<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 1:10 PM, Jason Orendorff <span dir="ltr"><<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Wed, Dec 3, 2014 at 9:04 AM, David Bruant <<a href="mailto:bruant.d@gmail.com">bruant.d@gmail.com</a>> wrote:<br>
> A script which builds a weakmap may legitimately later assume the weakmap is<br>
> filled. However, passing the weakmap to a mixed-trusted (malicious or buggy)<br>
> script may result in the weakmap being cleared (and break the assumption of<br>
> the weakmap being filled and trigger all sorts of bugs). Like all dumb<br>
> things, at web-scale, it will happen.<br>
<br>
</span>OK. I read the whole thing, and I appreciate your writing it.<br>
<br>
There's something important that's implicit in this argument that I<br>
still don't have yet. If you were using literally any other data<br>
structure, any other object, passing a direct reference to it around<br>
to untrusted code would not only be dumb, but obviously something the<br>
ES spec should not try to defend against. Right? It would be goofy.<br>
The language just is not that hardened. Arguably, the point of a data<br>
structure is to be useful for storing data, not to be "secure" against<br>
code that **has a direct reference to it**. No?<br>
<br>
So what's missing here is, I imagine you must see WeakMap, unlike all<br>
the other builtin data structures, as a security feature.<br>
Specifically, it must be a kind of secure data structure where<br>
inserting or deleting particular keys and values into the WeakMap does<br>
*not* pose a threat, but deleting them all does.<br>
<br>
Can you explain that a bit more?<br>
<br>
I see the invariant you're talking about, I agree it's elegant, but to<br>
be useful it also has to line up with some plausible security use case<br>
and threat model.<br></blockquote><div><br></div><div>As Mark presented it in the meeting (<a href="https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-19.md#412-should-weakmapweakset-have-a-clear-method-markm">https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-19.md#412-should-weakmapweakset-have-a-clear-method-markm</a>): </div><div><br></div><div><br></div><div>"the mapping from weakmap/key pair value can only be observed or affected by someone who has both the weakmap and the key. With clear(), someone with only the WeakMap would've been able to affect the WeakMap-and-key-to-value mapping."</div><div><br></div><div>(This is the same thing that David was explaining, but slightly different delivery)</div><div><br></div><div>As I understand this explanation, removing clear() simply closes off a path that would otherwise allow for potentially malicious meddling—no more, no less. </div><div><br></div><div>Rick</div><div><br></div></div></div></div>