[2:00]<Wes-> anybody in here who has done some serious thinking about commonjs sandboxes? [2:01]<Wes-> or "secure" modules? [2:02]<jbrantly> I know some people in #node.js have (but of course in context of node) [2:03]<jbrantly> can't think of the project offhand.. :/ [2:03]<Wes-> jbrantly: I'm trying to figure out how they would communicate securely with the outside world [2:03]<Wes-> jbrantly: Best I can think of is (immutable) strings [2:05]<jbrantly> Wes-: http://github.com/fictorial/jefe and from earlier: (3:12:26 PM) maushu: Anyone has any idea how to design a communication between node.js sandboxes? [2:05]<Wes-> jbrantly: Thanks! Geez, now I wish I was still lurking in there :) [2:06]<jbrantly> Wes-: no answers that I saw, but there are people thinking about it :) [2:07]<Wes-> Interesting, it looks like jefe allows the outer container to push objects directly at the sandbox [2:08]<Wes-> I'm trying to work out exactly where the module memo is visible and to whom [2:08]<Wes-> So far, separate runtimes and separate worker threads get separate memos [2:08]<Wes-> sandboxes are trickier, because I don't understand them 100% [2:09]<Wes-> pushing an object into a sandbox means it's in the same runtime - I don't know if it means it's on the same thread, but certainly the module memo should be separate [2:10]<Wes-> Hmm, it had better be on the same thread, come to think of it, since worker threads can't share objects and promiscuous threads are verbotten [2:11]<Wes-> So, sandboxes shares threads and runtimes with the main container, but not the same module memo [2:11]<Wes-> They also don't share a global object [2:11]<Wes-> And since they don't execute concurrently with the main code, I can control what global object is in the jsapi context when they DO run [2:12]<Wes-> Which means I can make the module memo per context-wide global, saving me from traversing the scope chain looking for 'require' [2:12]<Wes-> (in order to have module-memo-scoped storage in c modules)