5 ms·
> And unsecured access to the graphics stack is a terrible idea. No one gives you unsecured access to the graphics stack. WebGL shaders are parsed and modified
by azakai 14y ago
> And unsecured access to the graphics stack is a terrible idea.
No one gives you unsecured access to the graphics stack. WebGL shaders are parsed and modified for security (for example, inserting things like bounds checks).
(Of course, there are security risks with any new technology.)
- tumult 14y agoI didn't know that. Thanks. But I'm not so much worried about bounds checks as I am other obscure forms of overflow or corruption in graphics drivers. They barely work for things that are built specifically for them.
- TazeTSchnitzel 14y agoTo be fair, some user-agents, such as the Blackberry PlayBook, ask for permission from the user to use WebGL when a site wants it.
- novalis 14y agoThat only transfers the decision to run it, doesn't make it any more safe. You can override anything, that doesn't "clean" it or make beneficial by default.
- azakai 14y agoBounds checks were just an example. Another example: When you get bufferData in WebGL, it doesn't just call glBufferData with those arguments. It carefully checks those arguments for validity, including against the current state (currently bound buffer, its size, etc.). This ensures that the GL driver only sees calls with valid, reasonable info. It does incur a performance hit, but as you can see from WebGL demos on the web, it isn't terrible. GL drivers in general are pretty complex. But the very small subset of GL that WebGL uses - both in terms of the commands used, and the content it passes in those commands as just mentioned - is much simpler to secure. Browser vendors have been working with GL driver makers on safety for a while now to improve things further. Again, are there security risks? Sure, any new technology has them. JavaScript engines and video codecs have them, exploits for those are discovered all the time, but without those our browsers would be much less useful. The same is true for WebGL.
- tumult 14y agoThanks again, I had no idea that browsers performed that much analysis. It's been a while since I've read up on WebGL.
- tedunangst 14y agoThat's the problem. We aren't even sure what attacks exist against the graphics stack, let alone how to secure it. There is a mountain of "who would ever call this maliciously?" code sitting under webgl. I have similar thoughts about allowing web sites to install fonts. Font rendering is hard, and font engines have not traditionally been exposed to attack. The idea that we have found all the bugs in them is absurd. There were security problems found in png many years after release, and that was something people knew needed to be secure from the beginning.
- azakai 14y ago> That's the problem. We aren't even sure what attacks exist against the graphics stack That could be an argument against new JavaScript JITs, too, or new video codecs. But we add those to browsers all the time, because they are important. So is being able to render 3D, I would argue. Furthermore, of course we have an idea of the risks here, and the ways to prevent them. A huge amount of effort has gone into that, but in speccing WebGL and in implementing it, and in collaboration with GL driver vendors. And security experts have been poking at GL and WebGL for a while, just like they poke at JS engines and video codecs.
- tedunangst 14y agoYes, it is an argument against JITs. For a little while, OS builders were making progress on mitigation techniques, then the browsers all got together and decided it would be cool to allow attackers more control over the executable parts of the address space.
- azakai 14y agoWithout JITs, you greatly limit the languages you can run quickly (no JavaScript, no C#, no Java, no Lua, etc. etc.) - that's a lot to give up. 3D is also a lot to give up. I understand if you happen to not care about speed or 3D, and that's fine, but most people do.
- 14y ago