securing the source code in a node-webkit desktop

Question

first things first , i have seen nwsnapshot. and its not helping.

i am building an inventory management system as a desktop app using node-webkit . the project being built is using compoundjs (mvc javascript library). which have a definite folder structure (you know mvc) and multiple javascript files inside them.

the problem is nwsnapshot allows the app to have only a single snapshot file but the logic of application is spread over all the folders in different javascript files.

so how do i secure my source code before shipping it to client? Or any other work-around Or smarter way (yes, i know about obfuscating).

Answer 1

You can use nodewebkit command called nwsnapshot to compile the javascript code into binary which will be loaded into the app without specifying any js file

nwsnapshot --extra-code application.js application.bin

in your package.json add this:

snapshot: 'application.bin'

Answer 2

You may consider to merge the JS files into one in the build process and compile it.

Answer 3

It really depends on what you mean by "secure".

You can obfuscate your javascript code fairly well (as well as potentially improve performance) by using the Google Closure Compiler.

I'm not aware of any off-the-shelf solutions to encrypt/decrypt your javascript, and honestly I would question the need for that.

Some people think they need to make it impossible to view their source code, because they're used to dealing with compiled languages where you only ship binaries to users. The fact is, reverse-engineering that binary code was never as difficult as some people think it is, so if there's any financial incentive, there is practically no difference between shipping source code and the traditional shipping of binaries.

Some languages have offered genuine encryption of deployed assets, such as Microsoft's SLPS. It seems to me that the market for this was so small that Microsoft gave it to a partner (just my view). The truth is that most customers are not interested in taking your source code; they're far more interested in your ability to service and support that code in an efficient manner, while they get on with their job.