2015-11-04 23:04 GMT+01:00 Matthew Robb <matthewwr...@gmail.com>: > > On Wed, Nov 4, 2015 at 4:46 PM, Tom Van Cutsem <tomvc...@gmail.com> wrote: > >> 1) If a module A hands out a reference to, say, a function f to modules B >> and C, then C could use this primitive to replace f with its own proxied >> version. Module B expects f to work as A intended, but module C can >> completely override its behavior, stealing any arguments to the function >> that B would pass. This is really bad behavior from a security and >> modularity perspective. > > > It seems like a straight forward solution for this might be adding > something like `Proxy.preventTrapping(...)` and have this applied to all > module exports/imports by default. Since modules work off bindings and not > object properties. >
We've thought about preventing certain objects from becoming trapped. However, my explanation above only used modules to frame the discussion. The security/modularity problem is in no way tied to module export/import bindings only. Code can be modularised in ways other than using modules, the most common one being multiple <script> tags on a page, good old CommonJS modules, etc. In other words: for most JS code (and virtually all legacy code), module boundaries are implicit. Even if they were explicit, if two modules start to exchange object references, you transitively don't want to have those objects be trapped either, so just defending module boundaries would not even be sufficient. In addition, limiting the scope of Proxy.startTrapping to fewer objects does not address the second point about implementation complexity. O.o is a much safer alternative to Proxy.startTrapping and covers at least part of its use cases. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
