The idea is quite fascinating and 'out there'. However, the authors themselves cover several clear drawbacks on the second page: > We assume that the attacker

The idea is quite fascinating and 'out there'. However, the authors themselves cover several clear drawbacks on the second page: > We assume that the attacker has access to a compiled (binary) version of the program but not its source code. Although this is a severe limitation (it means that our technique cannot be used to protect open source software), it is a necessary one. Developers are unlikely to be willing to work with source code that has had extra bugs added to it, and more importantly future changes to the code may cause previously non-exploitable bugs to become exploitable. Hence we see our system as useful primarily as an extra stage in the build process, adding non-exploitable bugs. I wonder if running software through this additional build step would also cause headaches for developers debugging and triaging real bugs in the software.