Wednesday, December 30, 2009

Now there's WebGL. Is the browser becoming a fat client?

At the start of the decade, the browser is always known as a thin client. It is able to display the presentation layer while the heavy duty processing is usually done on the server end. However increasingly, it seems that the browser is getting "fatter". It started with the Javascript and DHTML. Now, there's a new standard coming up called WebGL.

WebGL is similar to OpenGL. It's the language that will enable you to do 3D modelling right on your web browser. Theoretically, this could mean you can play 3D games right off the browser. Exciting? However, this is where I worry. We're fast crossing the line where the browser itself becomes a mini application server.

Why worry? Quite simple. Previously, the only way to "catch" a virus is for you to physically run the virus on your computer or for some hacker to exploit some security vulnerability to enable them to execute a malicious script to allow them to take over your computer. The browser nowadays seem to be loaded with many extra processing features which means that the hackers will have more things to "play with".

If WebGL is able to harness the power of your 3D graphics card, that would also mean that the application in the browser could somehow access your computer's hardware. If the browser could access your hardware, what's stopping the browser from accessing the other parts of your computer? Namely your hard disk where your important information is being stored?

From the security perspective, I'm quite against WebGL being built into the browser. However, if it's a plug-in (which you can disable as and when) and there are rules that dictate that the browser is sandboxed (restricted) to certain functions, this may be feasible. So far though, I've read nothing with regards to this.

9 comments:

I don't think you need to worry about this specifically. WebGL only allows people to write in normal JavaScript or in code that can specifically run on the graphics card, using a specialised shader language. It's no more likely to "leak" to other parts of the machine than a Java applet, or indeed JavaScript, are.

On the other hand, it does create a new way for broken web pages to annoy you by using up all of your graphics card's resources -- just like existing ones can annoy you by sucking up all of your CPU power.

Yes you're right. It is possible for you to be tricked into a website that is using WebGL to specifically cause your machine to crash by using 100% of your CPU resources, freezing all your current open applications.

However, it is also possible that the implementation of this graphics card interface to be less than ideal (like all softwares), allowing people to access the other areas of your computer.

Java applets need to be signed in order for it to be allowed access the other areas of your computer. So far for WebGL, is there any indication of such fail-safe mechanism? An alert to the user that the web application is accessing your computer hardware?

"However, it is also possible that the implementation of this graphics card interface to be less than ideal (like all softwares), allowing people to access the other areas of your computer."

While any software can have security problems, the way in which WebGL allows access to the video hardware is makes it very unlikely. To use the Java comparison, you're quite right that unsigned Java applets do not have access to anything outside the sandbox. WebGL shader code is as unlikely to get out of its own "sandbox" as an unsigned Java applet would be to get out of the sandbox and start accessing other parts of the machine. So, yes, WebGL could create new security holes, but it's no worse than the current situation with Java applets.

(That's a very inexact analogy -- the sandboxes in question work in a very different way -- but I'm making it for purposes of comparison.)

"WebGL shader code is as unlikely to get out of its own "sandbox" as an unsigned Java applet would be to get out of the sandbox and start accessing other parts of the machine. So, yes, WebGL could create new security holes, but it's no worse than the current situation with Java applets."

Yup. I don't disagree with that. But then again, like I stated before, I don't quite like java applets in the first place. :)

I believe you do have experience in WebGL. Does WebGL prompts the user like what a signed java applet does?

What I do like about Java applet is that if it is going to access your client side resources, it actually prompts you by indicating that it's a signed applet. To me, that's a "warning" sign that something is different.

As a person who used to build products and frameworks, I'm hesitant on any product that access information without any prompting. Maybe it's just me. :)

I definitely see your concern; I think the difference in perception is that for me, the JavaScript that's accessing the WebGL libraries isn't really doing anything more risky than, say, accessing your sound card. I'm a lot more worried about the client-side storage stuff that's apparently also coming in HTML5.

Yup. The javascript is suppose to just access the capabilities of the graphics card, but I always worry about the what ifs. :)

It really looks like HTML5 will transform the browser into a fat client, something which I do not really like. Off-line storage is something that I've not yet used even though my browser supports it. If any web application can access certain resources available in the client of the browser, this could potentially open a big loophole for malware and viruses to come in.

Anyway, good luck in your WebGL experimentation. :) I hope there won't be a cross browser problem like AJAX.