I am going to be that guy - resurrecting a dead thread :-) I just watched the jalangi video and while I sincerely liked the overall idea, I have several reservations that I would like to list here.
First, I am concerned about the record replay approach. I don't know how practical it will be for us to expect web developers to use a two step system like that. My belief is that the more difficult we make a security tool for people to use, the less likely it is that it's going to be used. At some point in the talk he briefly mentioned that jalangi has issues with ecmascript 5. More evaluation would be necessary to determine if that would be problematic. My other concern is that this is still an academic project. This means that it's not going to be ready for serious use and issues will arise. How do we resolve any problems? Can we rely on the authors to go in and fix bugs for us? Is that going to happen in a time frame that wouldn't add risk to our project? The upside is that this is an open source project, so theoretically someone can go in and fix issues, but that will most likely be a difficult endeavor. If I had to chose, I would prefer working solely in spider monkey, so that way I know that should I have an issue, I can run to the lovely folks on #jsapi than having to go to a third party for help. Jalangi does not come without a performance penalty - he cites a 20x performance decrease. Jim has done some work on benchmarking what I currently have. It would be interesting to see how we are fairing right now, since the current approach doesn't take any advantage of performance optimizations or best practices. It currently needs a node.js server for its analysis. Technically, it can be run in the browser instead, but for that to happen it would need internal hooks. Supposedly the debugger API can be used, but that hasn't been done. However, despite all of the things above, jalangi is quite nice. I am sure it is capable of better analysis than what we have right now. They have put more thought and effort into it than us and as nbp pointed out, this can be used not only for tainting but also for a wide range of other applications. It's basically PIN for javascript. Please let me know if I missed, or misrepresented something from the video. Ivan On Tue, Aug 20, 2013 at 9:15 AM, Jason Orendorff <[email protected]>wrote: > On 8/20/13 6:20 AM, Jan de Mooij wrote: > >> If we go ahead with this, I think we should (at least initially) >> disable the JITs when taint analysis is turned on. Should avoid some >> complexity and on most websites the difference won't be noticeable at >> all. >> > > Maybe. It depends on how much complexity it really saves and whether the > difference is noticeable. If this is for use in an automated tool I imagine > the difference (i.e. forcing all JS code to run in the interpreter) would > be very noticeable. > > > -j > ______________________________**_________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@**lists.mozilla.org<[email protected]> > https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals> > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
