> 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.)
That'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.
> 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.
Yes, 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.
I do care about speed and 3D. But I don't think the web needs to be the delivery mechanism for all software. 900 years ago, they compiled Thunderbird once and everybody downloaded and used it. Now, every individual end user compiles gmail on a daily basis. The SaaS model has a lot of advantages. It has disadvantages too. I'm ok with only a subset of all potential programs being viable in a SaaS model.
In particular, I think allowing malicious people to run programs on your computer by default because, hey it's safe in the sandbox, is a terrible idea.
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.
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.
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.
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.)