3 ms·

Passionate and unconvincing. You can't get around the fact that WebGL lets a website control the graphics driver in a way which is much too direct for comfort.

Passionate and unconvincing. You can't get around the fact that WebGL lets a website control the graphics driver in a way which is much too direct for comfort. The central problem is the poor quality of driver code compared to OS code. If these were of equal quality, then indeed this would be no more dangerous than a JVM. [EDIT: and for extra danger, the driver code generally runs at elevated privilege.] You can presumably exploit a hole in the OS by executing something in a JVM, but that's been an extremely rare exploit because of the high quality of the JVM and OS code in the relevant parts of their interface. This thing opens a huge attack surface against much more vulnerable code. Driver code is buggy, usually prematurely released in a rush to market, and deliberately closed and obscured. Maybe the answer is to make that code better across all the graphics companies, but until this happens, I fear WebGL. The guy himself gives examples in which they have to work around known bugs which exploit vulnerabilities with formally valid inputs. But what about the unknown bugs? Those are the ones that will get us, no? Now, I don't know if Flash 11 or Silverlight are just as bad. Maybe they are (although I see claims in this thread that this is not so for Silverlight). But this is not a good reason to support a hugely insecure technology. It's a reason to fear these other technologies as well.

icefox 15y ago
I am not familiar with flash's api, can anyone point us to the docs in flash on how to access the shaders or a specific example?
- cube13 15y ago
  Until recently, Flash didn't even use any hardware acceleration for video. I don't believe that it actually gives the direct access to the hardware that WebGL does. So while it's still a security risk(especially given Adobe's track record), I'm not entirely convinced that it's a greater potential risk than WebGL.
  - recoiledsnake 15y ago
    True. Flash is a plugin that Adobe ships, whereas IE is the responsibility of Microsoft because it ships with Windows. Flash taking a risky bet is different from the IE shipping potentially vulnerable code with the Windows box.
- ken_railey 15y ago
  The shader language is called AGAL, here is an intro: http://blogs.adobe.com/flashplatform/2011/04/intro-to-adobe-graphics-assembly-language-agal.html http://blogs.adobe.com/flashplatform/2011/04/intro-to-adobe-...
  - malkia 15y ago
    Thanks, never heard of it. But why would they chose something so low-level that looks like assembly (reminds of the old shaders - I guess I have to read, maybe... easier translation for CPU if there is no GPU?).
    - Impossible 15y ago
      Adobe also has a tool called Pixelbender 3D where you can write shaders in their flavor of HLSL. Its an extension to pixel bender (which was for 2D shaders only). Pixelbender 3D has to be used offline though, so if you want to embed shaders in a swf they have to be written in assembly. The reasoning for this is that the pixelbender shader compiler is larger than any single part of the flash runtime, so it would greatly bloat the flash runtime for a little bit of developer convenience. Adobe has done a poor job of showing that you can use high level shader code in their demos though, pixelbender will end up being the preferred way to author shaders for molehill, the assembly stuff will only be used by a few people for tests\quick hacks.
yaakov34 15y ago
Well, this got a bunch of upvotes and a bunch of downvotes. Quite honestly, I'm not complaining about the scoring, but I'd like to understand the thinking here. Is it just "I want the shiny new API, stop saying these unpleasant things?" I am not a web developer; I just live in their world. And it's clear that we'll get WebGL and a bunch of other things like it anyhow, since there is tremendous pressure to make web apps more like local apps. Here are some well-known things about graphics drivers - I do have some knowledge in this domain, but honestly, these are things that anyone can find out himself: -- They've become quite complex. With the rise of GPGPU, the graphics driver now includes a C compiler, a virtual machine (or several specialized virtual machines), debug hooks, and tons of other code. -- The driver development teams are not focused on security. Their API is meant to be used by a local application, and if you're running an executable, especially one that can talk to the driver for your screen, the executable can already do whatever it wants. -- There has not been any sort of a scramble among video driver teams to prepare for WebGL. It's not in the job description of their product to provide a sandbox for malicious code. The graphics driver is not a JVM. And I am very unconvinced by the proposed measures for WebGL security in the browser, which include such things as blacklisting a driver once a vuln is reported. What about before it's reported? -- If you're using virtualization for security, I seriously recommend not using the "accelerated 3D" option. I don't know of published exploits, and the virtualization does make it somewhat difficult for a malware writer, but you are NOT getting any sort of a hardware-enforced guarantee the moment you enable the passing of commands to GPU. Now, VMWare (and others) are very aware of security issues, and are working on GPU virtualization with that in mind. But it's still not the same guarantee. My bottom line is that I would seriously prefer for WebGL not to become popular, until a serious standard for sandboxed virtual GPUs is worked out. But it seems some people just can't wait.
- bonch 15y ago
  > Well, this got a bunch of upvotes and a bunch of downvotes. Quite honestly, I'm not complaining about the scoring, but I'd like to understand the thinking here. Is it just "I want the shiny new API, stop saying these unpleasant things?" It's that this article is from a Google employee, and so you're going to get the Google defenders coming out of the woodwork.

icefox 15y ago

I am not familiar with flash's api, can anyone point us to the docs in flash on how to access the shaders or a specific example?

cube13 15y ago
Until recently, Flash didn't even use any hardware acceleration for video. I don't believe that it actually gives the direct access to the hardware that WebGL does. So while it's still a security risk(especially given Adobe's track record), I'm not entirely convinced that it's a greater potential risk than WebGL.
- recoiledsnake 15y ago
  True. Flash is a plugin that Adobe ships, whereas IE is the responsibility of Microsoft because it ships with Windows. Flash taking a risky bet is different from the IE shipping potentially vulnerable code with the Windows box.
ken_railey 15y ago
The shader language is called AGAL, here is an intro: http://blogs.adobe.com/flashplatform/2011/04/intro-to-adobe-graphics-assembly-language-agal.html http://blogs.adobe.com/flashplatform/2011/04/intro-to-adobe-...
- malkia 15y ago
  Thanks, never heard of it. But why would they chose something so low-level that looks like assembly (reminds of the old shaders - I guess I have to read, maybe... easier translation for CPU if there is no GPU?).
  - Impossible 15y ago
    Adobe also has a tool called Pixelbender 3D where you can write shaders in their flavor of HLSL. Its an extension to pixel bender (which was for 2D shaders only). Pixelbender 3D has to be used offline though, so if you want to embed shaders in a swf they have to be written in assembly. The reasoning for this is that the pixelbender shader compiler is larger than any single part of the flash runtime, so it would greatly bloat the flash runtime for a little bit of developer convenience. Adobe has done a poor job of showing that you can use high level shader code in their demos though, pixelbender will end up being the preferred way to author shaders for molehill, the assembly stuff will only be used by a few people for tests\quick hacks.

yaakov34 15y ago

Well, this got a bunch of upvotes and a bunch of downvotes. Quite honestly, I'm not complaining about the scoring, but I'd like to understand the thinking here. Is it just "I want the shiny new API, stop saying these unpleasant things?" I am not a web developer; I just live in their world. And it's clear that we'll get WebGL and a bunch of other things like it anyhow, since there is tremendous pressure to make web apps more like local apps. Here are some well-known things about graphics drivers - I do have some knowledge in this domain, but honestly, these are things that anyone can find out himself: -- They've become quite complex. With the rise of GPGPU, the graphics driver now includes a C compiler, a virtual machine (or several specialized virtual machines), debug hooks, and tons of other code. -- The driver development teams are not focused on security. Their API is meant to be used by a local application, and if you're running an executable, especially one that can talk to the driver for your screen, the executable can already do whatever it wants. -- There has not been any sort of a scramble among video driver teams to prepare for WebGL. It's not in the job description of their product to provide a sandbox for malicious code. The graphics driver is not a JVM. And I am very unconvinced by the proposed measures for WebGL security in the browser, which include such things as blacklisting a driver once a vuln is reported. What about before it's reported? -- If you're using virtualization for security, I seriously recommend not using the "accelerated 3D" option. I don't know of published exploits, and the virtualization does make it somewhat difficult for a malware writer, but you are NOT getting any sort of a hardware-enforced guarantee the moment you enable the passing of commands to GPU. Now, VMWare (and others) are very aware of security issues, and are working on GPU virtualization with that in mind. But it's still not the same guarantee. My bottom line is that I would seriously prefer for WebGL not to become popular, until a serious standard for sandboxed virtual GPUs is worked out. But it seems some people just can't wait.

bonch 15y ago
> Well, this got a bunch of upvotes and a bunch of downvotes. Quite honestly, I'm not complaining about the scoring, but I'd like to understand the thinking here. Is it just "I want the shiny new API, stop saying these unpleasant things?" It's that this article is from a Google employee, and so you're going to get the Google defenders coming out of the woodwork.