Talking about WebGL and Security…
i was just browsing MrDoob‘s beautiful three.js examples when i stumbled on something quite creepy.
This is a screenshot (click for full size image) of my browser rendering one of the demos:
What you see is a messed up background texture showing fragments of my local desktop. Note that some of the windows that you see weren’t even open anymore at the time the demo ran, like the Keychain one.. *shudder*
Every time i reload the demo, the background texture shows different, seemingly random fragments. This happens in both Chrome (13) and Firefox (6). I’m on a MBP featuring an Intel HD Graphics 3000, running Mac OS X 10.6.8.
What i suspect is happening here is that either WebGL, the drivers, or the GPU itself corrupts the GPU texture memory somewhere and pulls in content it shouldn’t pull. I’m certainly not an expert in this field, so this is really just an (un)educated guess.
Thoughts?
[Update: I logged a bug with Mozilla, and this bug was marked fixed and closed today. Thanks Benoit and everyone else from Mozilla and Google who was involved!]
September 5th, 2011 at 06:53
This is exactly the problem with WebGL. The low level access it gives is a little too risky.
http://www.contextis.com/resources/blog/webgl2/
September 6th, 2011 at 11:07
This problem was so far known to me only with Mac OS 10.5 and is the reason why WebGL was disabled in Mac OS 10.5 in Firefox, see
https://bugzilla.mozilla.org/show_bug.cgi?id=631258
The problem is entirely in the OpenGL implementation / driver and is known to me only on Mac OS.
Please let us know if you find any steps to reproduce this reliably. As far as Mozilla is concerned the most helpful thing would be if you filed a bug at bugzilla.mozilla.org, product “Core”, component “Canvas:WebGL”.
September 6th, 2011 at 11:08
To be clear this problem is not WebGL specific and could happen with any OpenGL application. But the fact that WebGL exposes it to Web content does obviously make it worse.
September 6th, 2011 at 11:15
…and also, the other scary thing is that this is so not-WebGL-specific (it’s just that OpenGL textures get randomly corrupted) that it could probably happen equally well with any browser feature that uses OpenGL textures, such as the accelerated compositing found in Firefox, Chrome, IE, and soon all browsers. I hope we don’t end up having to disable all features using OpenGL textures on Mac OS.
September 6th, 2011 at 11:27
Last spam, I promise. So far this bug had only been reproduced (on OS 10.5) after the computer had come out of sleep. It seemed that the GL texture corruption occurred only when Macs went to sleep mode. If you reboot your Mac and do not let it sleep since it booted, can the bug still be reproduced? It would be nice if it were specific to sleep as that would open possibilities of work-arounds.
September 6th, 2011 at 13:48
Thanks Benoit! I can reproduce this after reboot, and filed bug #684882.
September 6th, 2011 at 15:10
Thanks but I can’t see random Mozilla security bugs :) Can you please at least CC me on it ( I am [:bjacob] or enter the same email address as I use for posting this comment). In this particular case I wonder if it’s worth hiding this security bug, since you already blogged about it and also the similar https://bugzilla.mozilla.org/show_bug.cgi?id=631258 (on Mac OS 10.5) has been made public already.
September 6th, 2011 at 15:14
Oh ok – I cc’ed you on the bug. It seems i can’t undo the security setting (the checkbox is disabled).
September 10th, 2011 at 20:50
Please retry in today’s Nightly (2011-09-10) or later. A tentative work-around was implemented and you’re the only person I currently have a access to, who can reproduce this particular bug.
September 11th, 2011 at 06:14
Benoit, I still see the issue :(
http://dl.dropbox.com/u/635275/Screen%20shot%202011-09-11%20at%206.11.03%20AM.png
September 11th, 2011 at 10:32
In this new screenshot I don’t see very clearly contents from other windows. I do see botched rendering but I would like to know if you still see contents of other windows/desktop/etc?
September 11th, 2011 at 10:33
Oh OK, I guess I see another window in the background. ok.
September 12th, 2011 at 18:34
Here are new try-builds:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-948b79ee11f3/
and
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-e80e7435e38f/
Please try especially the first one first, I have relatively high hopes that it will work around the bug…
September 13th, 2011 at 04:05
Ignore the above comment, these builds have been reported to not solve the problem. Will probably have to reimplement glGenerateMipmap.
September 21st, 2011 at 18:41
I think a good thing would be that the browsers ask if you trust the website with a tooltip message, than after the WebGL feature would be enabled to work.
September 23rd, 2011 at 22:03
Please retry in tomorrow’s Nightly, or if you want to try now, use this build:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-a2ad04cd8ca3/
This should definitely be fixed now.
Also, I hear that the bug is fixed in Mac OS 10.7.2. Would be interested in a confirmation.
September 29th, 2011 at 16:44
The previous fix didn’t work, but since then we’ve come much further along in understanding the problem, and it turns out that it’s specific to rendering cube maps of size larger than 894 (!)
Please retry in tomorrow’s Nightly, it should be fixed for good this time.
December 2nd, 2011 at 11:25
Interesting to see other folks with this issue.
I’m able to reproduce this with FireFox 8.0.1 (regular release) consistently on OS X 10.6.8 (2011 MacBookPro 13″) with very simple examples (see: http://www.aerotwist.com/lab/getting-started-with-three-js/ – I was following this tutorial).
The same examples work fine in Chrome 15 on the same Mac. I’m stumped to find a solution; however the corruption does seem to become exponentially worse the larger the canvas element is set.
January 18th, 2012 at 01:37
I just wanted to confirm that this is fixed (really, worked-around) in Firefox 9 (and in current Chrome too, with near certainty).