On the one hand, langsec specifically handles these problems. A program for searching through a file will produce the same results whether it runs in a tenth of

On the one hand, langsec specifically handles these problems. A program for searching through a file will produce the same results whether it runs in a tenth of a second or ten seconds, and as such doesn't need to - in langsec, shouldn't be able to - access the time. That's what langsec is. It can even identify hazards like the SharedArrayBuffer high-res timers that compare the execution speed of different programs by communicating between processes; most programs shouldn't care which thread finished first, so that information shouldn't be available! And so we build formalisms for computing that don't make that information available to the program. On the other hand, that's probably infeasible for the real world. Humans care about time too much for it to be declared off-limits to many programs. Similarly with things like communicating processes. These attacks are so fundamental that it'd be effectively impossible to build a program that didn't throw up an impenetrable wall of critical langsec violations. So I'm not sure. The langsec framework does offer a solution. It might just be that, in the same way that things like haskell offer their solutions, it's too difficult for the real world to apply it.