I have spent some time analyzing which could be the best way to protect a privative version of a webphone based on QoffeeSIP
that we are developing now at Quobis
. I have seen this same question on different sites with quite confusing responses. So I'm going to share what I learned just in case it could help to anybody.
Well, I'm not going to define what is WebRTC because Internet is full of it this year (only overtaken by cats
First of all I want to remark that protect your code in the sense of anybody could copy/modify and redistribute it is impossible
In general, I found that there is a bit confusion between minimize and obfuscate terms so we're going to speak a bit about these techniques.Minimization
The target is to get the code as small as possible. Obviously generated code is more difficult to understand, but it could be easily reversed with tools like JSbeautifier
. (really not as easy depending of the minimizing tool)
Some common possible options at this point are:
- UglifyJS: The coolest thing right now xD. It is a Node.js package so it's easy to include. Some days ago version 2 was published. We will see that it's fast, really fast.
- Google Closure Compiler which uses Google to its apps. It is availiable a Java command line tool but there are node modules which use the online API.
- YUI Compressor from Yahoo, it was the facto standard but now last alternatives are beating it.
A little comparison: I can't find original link, sorry :(
- Average time: (lower is better)
- UglifyJS: 0.11554 seconds
- Closure: 1.41037 seconds
- Average reducction: (higher is better)
- UglifyJS: 45.6%
- Closure: 51.5%
NOTE: Another one
(more complete) with YUI included too.
to check your code while developing.Obfuscation
It is defined as "the hiding of intended meaning in communication, making communication confusing, wilfully ambiguous, and harder to interpret."
We have some options here when we are working with a web app:
- Encrypt the transport layer: needed to avoid sniffing to another users of the same LAN. So using HTTPS to serving the application is a must.
- Move functions to the server side, which it's not possible in the case of WebRTC because we want end to end media.
- Use a browser plugin, it has no sense since one of the advantages of WebRTC is that the user doesn't have to install anything.
- Implement the code in native client for Chrome browser. The advantaje is that common C code protections can be used and the app runs sandboxed. But it is not our case because we need multi-platform support.
NOTE: Really @source tag is proposed by FSF to include a link to source code of the app. But I think that it could be a good idea to use it because browser plugins that follow the recommendations
should "understand" it.
// @source: https://qoffeesip.quobis.com
// Copyright (C) Quobis
// Licensed under Quobis Commercial license
I also want to point out some common obfuscation/encryption problems:
- Performance decrement, specially speed.
- Increase troubleshooting difficult.
- Compatibility problems (IE!!).
- Size increase.
- As it was said, a skilled expert could always reverse it and get a code equivalent to ours.
All these problems are more important on the case of encryption, except the last one logically. So at this point we have some options, but I've reduced them to these ones:
- A paid option like JsCrambler: This is the reference tool, generated code seems to be really dificult to recover and it supports an important number of encryption algorithms.
- A free solution provided by my colleague Damián: Horrible.js. It implements obfuscation and a kind of simple (so light) optional (through "factor" parameter) encryption. Next picture shows an example using it with the three different factors.
Finally, if you don't like the ugly generated code you can always use Nice.js
to get something like this example: xD
In conclusion, I like Horrible.js with factor 3. In my opinion, it has no sense to paid for mitigating a risk impossible to solve completely.