We've already had these kinds of issues with webgl. Here's one that I found through some googling: http://www.cvedetails.com/cve/CVE-2014-3173/

You don't need webgl for this kind of infoleak either, regular good old 2d canvas also supports allocating memory. It also supports reading the current state of all of the pixels in the buffer through Javascript, so if you have an exploit that gets you an uninitialized canvas you can easily send whatever memory contents you got back to your server for later analysis.

Not always. I was trying to write an android application to serve as a frontend to a site by launching a background webview, drawing the elements I'm interested to a canvas and sending the pixels back to the application. (Un)fortunately, after you draw an HTML DOM element to a canvas, you're forbidden from reading the canvas pixels back and there's no flags you can set on the webview to let you do it.

Indeed, if the data in a page's canvas has a different origin, you're not allowed to read pixels back (http://www.w3.org/TR/html/scripting-1.html#security-with-can...).

If the DOM element you draw has the same origin as your canvas it seems like (from my reading of the spec) you should be allowed to do what you describe.

It's called a bug. It gets fixed. There's nothing special about this type of bug any more than any bug in the browser.

Remote screenshoting of hours old content across distinct local user accounts is perhaps more serious than many other bugs, especially when there seems to be a blame game going between the app/os/gpu vendors.

And in the mean time you share your porn with NSA for few years.

Well, the problem is it isn't a single bug, WebGL is an entire minefield of bugs. OpenGL drivers were generally never written with security in mind, and now all of a sudden we've got untrusted code able to poke away at them.

WebGL being enabled by default is insanity in my opinion.