2./2.1./4. Yes this is true, and that's exactly where root of my problem with this direction of research lies. The incentives of software vendors are partially

2./2.1./4. Yes this is true, and that's exactly where root of my problem with this direction of research lies. The incentives of software vendors are partially misaligned with those of the users. A vendor will want to maximize their profit, if a tool that implements this research allows them to be lazy then en-masse they will (ab)use it. 3. Software is layered, if every layer of your electron app starts using this type of obfuscation you will notice the slowdown. 1. I think there's an underlying assumption we both make about this research: it will increase the costs of finding exploits, but it will definitively not prevent a skilled attacker. I also don't think it absolutely disqualifies anyone who's already able to craft an exploit, perhaps it will take them longer but anyone with the reversing chops to abuse an aslr weakness can figure out how to patch out or reverse the jumptables. With that in mind, it comes back at the question: Is it worth it? Increase the costs for an attacker but simultaneously adding an incentive for vendors to be lazy, an chose a cheap band-aid bolted-on-security approach as opposed to what we all know is the eventual (expensive) fix for memory related security problems? I still think: hell no, don't make this stuff available, invest resources in alternative mitigations if not in outright solving the issue.