PDA

View Full Version : WebGl/WebCL and “IP“ protection



sean.settle
08-12-2011, 01:28 PM
I‘m new to Javascript and WebGL/WebCL, but I‘m relatively familiar C and OpenGL/OpenCL. My concern is that Javascript is plain text, and despite obfusctors (which are relatively simple to reverse engineer), that any work could easily be duplicated without knowledge or concent. I‘d like to hear people‘s recommendations or thoughts on this issue, hopefully from both open and closed source points of views. The technology has great use cases but doesn‘t seem to protect developers‘ investments enough.

Jesse Jones
08-15-2011, 12:41 PM
I came here with the same question. Suppose we put a lot of work into a site, & don't want it to be copied. Is there some way to perhaps generate an encrypted script file on the back end? Set permissions to deny an unseemly request?

More of a 3D developer than a security person here, so please excuse my shots in the dark.

sean.settle
09-22-2011, 03:31 AM
bump.

I posted this originally a little over a month ago but for some reason this hasn't received the attention I had anticipated for something seemingly so simple yet important. Here's attempt number two.

VinceGL
09-22-2011, 04:45 AM
Web is open. If you want to do some closed source code use Flash/Java/Unity3D/etc.

All you can do is "hidding" your javascript code (obfuscate, use web worker or packing it on a custom format and reverse it back, check url before executing script, etc.).

gliniak
09-28-2011, 09:13 AM
There was discussion about this issue on this forum. Use search function or just browse the topics - there aren't too many of them.

leonardteo
10-03-2011, 03:05 PM
No, I don't think there's any "IP protection" in using WebGL. It's wide open. People can and will examine your source code, shaders, even 3D models can be scraped easily.

Leo

DCBishop
08-10-2012, 12:27 AM
Genuine IP protection/DRM is a myth.

If people want to rip things like 3D geometry/textures there are programs that allow you to pull it out of the buffers directly anyway even when it's compiled desktop applications or running though Flash, running through Unity, or some DirectX webplugin. Flash, Java and so on can be decompiled anyway.

About the best you could do would be to preform some basic lightweight encryption to the raw data somehow and decrypt it on the fly in the shaders (ie run vertex data through some obfuscation matrix, negate all the odd/even vertex positions or even add an extra vertex attribute that cancels out a random offset like a one time pad).

That would incur a performance overhead and could still be bypassed without much more effort the de-obfuscating stuff. They can grab the shader code and reverse it. Also they probably could still pull it out of the pipeline in it's final form. And of course that won't protect your source code.

None of the plugin/closed/proprietary solutions are really going to be totally effective. They all have various ways to undo them. Everything can be decompiled to various degrees. Flash videos can be ripped using stream rippers (HTML5 videos can be downloaded simply be right clicking, or in the case of YouTube using the browsers inbuilt developer tools to disable the transparent shield frame first). I haven't heard of a Google Native Client decompiler yet but it's only a matter of time. The web is totally open, all the text, images, JavaScript and videos can all be copied.

Compiled C gets cracked even when using the major antipiracy solutions and generally nothing stops people ripping models from datafiles there either.

Even game consoles where they control the hardware, digitally sign and encrypt everything still get cracked/modchiped eventually.

The question is how much effort people would go to in order to rip your content.

The other question is how much effort are you willing to invest in order to try and prevent it happening. That time could probably be better spent on improving or adding other features. About the only reason to bother would be if you have to work with parties that demand some kind of DRM solution.