Not really. Timing attacks are not all that hard to understand - if the timing (or anything else) a user sees depends on information they shouldn't be able to

Not really. Timing attacks are not all that hard to understand - if the timing (or anything else) a user sees depends on information they shouldn't be able to see, then there's a (theoretical, at least) information leak and that's a security flaw. I'm not a security expert, and this is something that's always in the back of my mind when considering security. It's ... one of the only things in the back of my mind - you need a constant time string compare for passwords is the most obvious example (and one that literally any decent programmer should be somewhat aware of). I only know the basics of security, and this is one of the basic principals. It's up there with "escape strings". People simply don't think about every layer of the stack. If they did, then it would be obvious (but there's so much in the stack that this is infeasible). JavaScript came out in 1995. Timing attacks on the CPU have been feasible since them (and heck, if you go back further then everything was terminals and multi user operating systems anyway). There's never been a time when CPUs haven't run potentially hostile operations. But virtually no-one (myself included) thought "can a timing attack happen"? despite timing attacks being a very common type of attack.