That’s something different: that’s just a straight-up bug in the driver or compositor, directly allowing access to the graphics memory of other programs. It’s stupid that such bugs occur, but occur they do. GPU drivers especially have historically been mindbogglingly badly implemented, though most of the worst problems are fully ironed out now. But what’s being reported here is far more subtle, a side-channel attack based on data compression.

I don't think this was the same vulnerability that you saw happening. I think many operations in shaders produce "unspecified" pixel values, which in practice often just manifests in getting pixel values from some previously freed buffer that is not yet overwritten.

I believe webgl should remove these kind of side channels, but implementations could have bugs.

Also GPU vendors should consider multi-user usage anyway and make these side channels impossible outside of webgl too. I doubt that they care and they would rather chase performance numbers.

When was this? When WebGL was a new thing, there was no protection whatsoever and an uninitialized textures and buffers could contain stale data from other processes. But this has been fixed like a decade ago.

In any case, what you saw is not what is described by this article. This article extracts pixel data very slowly by measuring GPU timings.

>sometimes I would get portions of other app windows inside the result

I seen something similar, and i always assumed it was just texture buffers reusing freed memory that was not cleared.

> I thought it was just a glitch on my system and couldn't replicate it reliably, it would just happen sometimes. Good to know it wasn't just my system :)

Similar to this attack then, seems it can take up to 30 minutes on a AMD system, and up to 215 minutes on a Intel system, and it's still not 100% accurate.