”This attack works in Chrome and Firefox, but has been fixed in recent versions.”

In other words, this is a clever exploit of a bug - not a fundamental issue with CSS. The rest is FUD.

I've commented to a mathematical friend more than once that computer science is mathematics, plus the assumption that time exists. (This also explains why I'm LISP-boner impotent. LISP is computer science, ++delay, minus the assumption that time exists; the user sees time, while the programmer doesn't—what's not to like?—but I still don't get the happy hardness.)

Moral of the story: fear the clock.

Do not fear napkin Turing-complete, CSS Turing-complete, nor LISP Turing-complete. (Turing-complete happens by accident at least once out of every nine innings of billiard-table HO-gauge NAND-gate pick-up-sticks.)

Perhaps what we need is a degraded system timer.

Ideally, the local mean would wander somewhat slowly on a fractalish time scale, only minimally convex around the extremes so as to stay within a +/- 30 second deviance specification for 99.8% of all samples. Ideally, the estimate of the mean would converge considerably more slowly than sqrt(N). But I don't know my thick-tailed distributions well enough to say what that would look like as an actual thing. You also don't want the difference between step changes to be small, on average; and you don't want the locations of the step changes to occur on precise, minute boundaries, either (duh!) In fact, I think sloppy-clock would return an ascending integer sequence, but the wall-time duration of each distinct integer interval (of minute-ish duration) would be unpredictable, as described.

My math is feeble enough that I can't even prove that my sloppy-clock as roughly stipulated even exists in practice, but let's assume it does.

Then you need to implement a security ring where the best clock available is sloppy-clock—and stuff all foreign scripts in there. Yes, plugging time leaks from the outside world in a sophisticated API is hard. True mathematicians need not apply (i.e. LISP won't help you in this endeavour, not even a little bit).

By avoiding capacitors (condensors) von Neumann's IAS computer could be frozen and single-stepped, or run at any frequency you desired, until the internal bit signals themselves became unstable. (Some of these early designs were actually asynchronous and self-timed.) Effectively uncoupled from the real world, such a machine has no ability to introspect the duration of its own operations—unless you screw up, and give it an actual wall clock or cycle-clock or global operation-count API (the second case is only possible with synchronous designs).

Uncoupled computing (Internet 404) is not popular under the modern CSS paradigm, so you do probably have to at least make a concession for sloppy-clock (which dingbat users can upgrade to precise-clock if it bothers them that their ESPN scoreboard page refreshes aren't entirely concurrent with the real world; it would also suck for implementing chess clocks; but not, strangely, for anticipating when a soccer game will officially end).

Anyways, this whole proposal is a massive research project.

I'm merely pointing out that computer science is merely mathematics—right up until time begins.

Von Neumann's early IAS computer didn't even have (internal) time. (That's because they had more than enough problems to deal with, already, without scoring an own goal.) Interestingly, Turing specified hardware random number generation from the get go, on purely formal reasoning about the space of available computation. Turns out, precisely measurable operational elapsed-time is ultimately more insidious (under promiscuous interconnection) than nondeterminacy. (A promiscuous web page being any web page bearing more than one cookie, or related code artifact.)

Maybe time does not fly like an arrow as described in its early scouting reports—but it certainly does leak (across code-execution trust domains) like a bat out of hell.