Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I 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.


Bounds 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.


Thanks again, I had no idea that browsers performed that much analysis. It's been a while since I've read up on WebGL.


To be fair, some user-agents, such as the Blackberry PlayBook, ask for permission from the user to use WebGL when a site wants it.


That 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: