The title reads like someone found a new exploit. There's no actual content in there, instead plain wrong information.

For instance:

> "A practical example of such a bridge from low level to the very top is an example where 70 lines of C code exploiting Spectre can be compiled to JavaScript / Wasm:"

The code in spectre.c won't compile or work on JS or WASM because it uses high-precision timing intrinsics not available in the browser sandbox. It was possible to exploit performance.now(), but all browsers have released updates which reduce precision of perf.now() dramatically.

May be there are other time sources lurking somewhere in the browser which could be exploited, but the article is just spreading FUD.

I'm looking forward to the first XSS vulnerability that exploits a WASM module. Control flow integrity looks correct (WASM has a separate return stack, call and call_indirect validate callee signatures), but use after free and buffer overflows are still possible.

There is no cache flushing in asm.js or wasm, so a key component of the example spectre.c, "mm_clflush()" is a no-op.

Even if the example were to compile, I don't see how it would work as is. It might be possible to attempt an alternative attack where you attempt stuff the cache and determined what got evicted, but that is a different attack and certainly not in the vein of "just recompile your c/c++ based exploits for the web".