Secure distribution of NodeJS applications

12,764 views
Skip to first unread message

Jeremy Rudd

unread,
Feb 23, 2012, 10:56:43 AM2/23/12
to nod...@googlegroups.com
What: Can NodeJS apps be distributed as binary? ie. you compile the .js app via V8 into its native binary, and distribute the binary to our clients? ... or is minifying the code all you can do?

Why: We build serverside applications in NodeJS for clients, that have often to be hosted on the client's servers. Distributing source code means clients can easily steal our solution and stop paying licensing fees. This opens up the possibility of easy reverse-engineering or reuse of our apps without our awareness.

Ben Noordhuis

unread,
Feb 23, 2012, 11:27:23 AM2/23/12
to nod...@googlegroups.com

[Insert obligatory "get better clients" comment here.] :-)

V8 has a feature called snapshotting where it loads JS and spits out
machine code. V8 uses it to improve start-up times but maybe you can
reuse it for your purposes.

Chris Rhoden

unread,
Feb 23, 2012, 11:28:23 AM2/23/12
to nod...@googlegroups.com
Why not distribute a VM?


--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en



--
chrisrhoden

Rob Ashton

unread,
Feb 23, 2012, 11:28:31 AM2/23/12
to nod...@googlegroups.com
I thought snapshots also included the source code - at least that was my understanding from a previous thread on the same matter?

Tim Caswell

unread,
Feb 23, 2012, 11:40:25 AM2/23/12
to nod...@googlegroups.com
Yes, since javascript functions show their source when they are toStringed, the source needs to be kept in memory, even in snapshots. 

I will say if you're building a custom binary anyway, why not put the sensitive parts in a C++ addon and require that from the JavaScript?  Reverse engineering

Jeremy Rudd

unread,
Feb 23, 2012, 11:54:24 AM2/23/12
to nod...@googlegroups.com
Don't know much about C++ addons. Can they access NodeJS objects as usual? All classes and functions?

Anyways, about the VM thing, is it possible to capture the snapshot the V8 engine generates, and then use that to run the app?

Regardless, if you're saying that the Node/V8 engines keep the source code in memory, that means less security. So I'll have to resort to source code obfuscation / uglification.

Tim Caswell

unread,
Feb 23, 2012, 11:58:04 AM2/23/12
to nod...@googlegroups.com
Yes, functions written in C++ can be called from javascript (this is how all the node primitives are implemented).  C++ can call back to js, it's just not as straightforward.

--

Chris Rhoden

unread,
Feb 23, 2012, 12:00:33 PM2/23/12
to nod...@googlegroups.com
My recommendation as far as the VM is simply to package up a VMWare appliance or something similar and have the clients run it on their network. You don't need to give them passwords if you have configured it correctly.
--
chrisrhoden

Matt

unread,
Feb 24, 2012, 1:45:19 AM2/24/12
to nod...@googlegroups.com
I have a similar requirement for a project, and came to the conclusion that node core could be extended and recompiled to produce custom binaries (someone with more knowledge can correct me if I am wrong here).  With a little bit of care, you should also get the benefit of all the cross-platform capabilities that the project offers.  However, I think at the moment this sort of "core extension" it a little tricky to accomplishment elegantly, which led me to create this issue: https://github.com/joyent/node/issues/2584.  At any rate, I would also be interested if someone has a better solution to the original question.

Lalo Martins

unread,
Feb 24, 2012, 1:52:44 PM2/24/12
to nod...@googlegroups.com
quoth Jeremy Rudd as of Thu, 23 Feb 2012 07:56:43 -0800:

> *What:* Can NodeJS apps be distributed as binary? ie. you compile the


> .js app via V8 into its native binary, and distribute the binary to our
> clients? ... or is minifying the code all you can do?
>

> *Why:* We build serverside applications in NodeJS for clients, that have


> often to be hosted on the client's servers. Distributing source code
> means clients can easily steal our solution and stop paying licensing
> fees. This opens up the possibility of easy reverse-engineering or reuse
> of our apps without our awareness.
>

> *Shamelessly cross posted on*:
> http://stackoverflow.com/questions/9413123/secure-distribution-of-
nodejs-applications


Ok, I tried my best to keep my peace, but I can't resist posting this.

This is a terrible, terrible misguided idea. And please don't co-opt the
word “secure” for it. This has nothing to do with security for either
party; on the contrary, it's more about dealing with your insecurities.

Distribute your product with source. If your clients have enough
technical ability to “steal” it, they also have enough to help you fix
bugs.

And then make it a big deal in your promotion material that it comes with
sources.

If somebody “steals” your work, sue them. Contract law is more than
sufficient for that, and if your clients are determined to “steal” your
work, binaries won't stop them.

If the problem is more about especially clever things you do to solve
their problem -- again, contracts will protect you much better than
binaries or obscured code, but you also have the option of patents. (Odds
are, though, the thing you're trying to protect isn't 10% as valuable as
you think it is.)


best,
Lalo Martins

Baz

unread,
Feb 25, 2012, 4:51:45 PM2/25/12
to nod...@googlegroups.com
Correct.
 
Ok, I tried my best to keep my peace, but I can't resist posting this.

This is a terrible, terrible misguided idea. And please don't co-opt the
word “secure” for it. This has nothing to do with security for either
party; on the contrary, it's more about dealing with your insecurities.

Distribute your product with source. If your clients have enough
technical ability to “steal” it, they also have enough to help you fix
bugs.

And then make it a big deal in your promotion material that it comes with
sources.

If somebody “steals” your work, sue them. Contract law is more than
sufficient for that, and if your clients are determined to “steal” your
work, binaries won't stop them.

If the problem is more about especially clever things you do to solve
their problem -- again, contracts will protect you much better than
binaries or obscured code, but you also have the option of patents. (Odds
are, though, the thing you're trying to protect isn't 10% as valuable as
you think it is.)


best,
                                              Lalo Martins

manimal45

unread,
Feb 26, 2012, 9:18:26 AM2/26/12
to nodejs
I think original poster knows about business/contracts protection.
His question seems to me technical, and would be far from ideal to
consider the case closed.

Aside from the "secure" aspect, I believe the very first intend of
node.js was to easily build scalable network applications.
Now, imagine you've built an amazing service on top of hook.io, or
cluster or whatever with many small node.js "agent".
What do you say to your customers when it comes to deployment ?
Today, you need to install python, node .... and then install the
package .... and its dependies ... and cross fingers for everything to
work.

It would be awesome if 'customers' could download node.js apps as
executable.
This would open the road for many new applications where a central
"cloud" server instance could communicate with customers
infrastructure via agents.

I'm surprised there's no easy way to deploy node.js easily. But maybe
I'm wrong.

mscdex

unread,
Feb 26, 2012, 10:09:52 AM2/26/12
to nodejs
It'd be neat to be able to have specific modules' (bundled in the node
executable) exported functions not show their source code
when .toString()'ed, kind of like how native C++ functions show
"[native code]" when .toString()'ed.

billywhizz

unread,
Feb 26, 2012, 7:16:51 PM2/26/12
to nodejs
if you put your js libs in the lib directory of the node.js source and
run make, the libs will be included as natives in the compiled node
binary. you can then just require them without a path. e.g. if you
have a module named test.js in the lib dir, then just do the
following:

var test = require("test");

of course, this won't stop anyone being able to inspect the source of
your module at run time but it will enable you to release your whole
application as a single executable.

Jeremy Rudd

unread,
Feb 27, 2012, 3:52:39 AM2/27/12
to nodejs
On Feb 24, 11:52 pm, Lalo Martins <lalo.mart...@gmail.com> wrote:

> And please don't co-opt the word “secure” for it.

I'm a dev, not management. I understand the field internally and so
I'm trying to start discussions to securely distribute NodeJS apps.
Anyone wants to vote if C++ EXE's are harder to decompile than .NET
EXE's? Just throw the damn thing into Reflector and viola!. With C++
you never really get great code.


> Distribute your product with source. If your clients have enough
> technical ability to “steal” it, they also have enough to help you fix
> bugs.

I work with assembly and IL. Source code can be compiled perfectly.
Decompiled code almost NEVER compiles perfectly, the program crashes
and/or strange errors appear. Binaries force the reverse engineer to
work with assembly at a low level. Source code allows any idiot
programmer to have a go at it.


> And then make it a big deal in your promotion material that it comes with
> sources.

We're trying to protect our application from clients, not GIVE it to
them. We're distributing applications that are run internally in
organizations. We won't even KNOW if they are running hundreds of
instances/copies of our software.


> If somebody “steals” your work, sue them. Contract law is more than
> sufficient for that, and if your clients are determined to “steal” your
> work, binaries won't stop them.

Binaries will slow them down. Enough to be helpful.


> If the problem is more about especially clever things you do to solve
> their problem -- again, contracts will protect you much better than
> binaries or obscured code, but you also have the option of patents.

Patents give away the techniques. Ever wonder why McDonald machines
are not patented? Did you know that in China, for instance, the govt
openly allows local companies to copy techniques described in patents?
So much for patents.



> Odds are, though, the thing you're trying to protect isn't 10% as valuable as
> you think it is.)

That's not for you to judge :) .. and not for me to judge either. I'm
a dev, not a forecaster.

Jeremy Rudd

unread,
Feb 27, 2012, 3:58:44 AM2/27/12
to nodejs

On Feb 26, 7:18 pm, manimal45 <moshir.mik...@gmail.com> wrote:
> It would be awesome if 'customers' could download node.js apps as
> executable.
> This would open the road for many new applications where a central
> "cloud" server instance could communicate with customers
> infrastructure via agents.

I second this. There needs to be a way to 'compile' nodeJS apps into
its binary format. AND a way to distribute this as a self-extracting
installer, look at Firefox, I mean they don't ask you to install from
source. Custom branding would also improve the business-value of
distributing NodeJS apps. It looks more pro.

Jeremy Rudd

unread,
Feb 27, 2012, 4:00:29 AM2/27/12
to nodejs
Exactly. I mean which application framework on earth allows you to
"view source" from the BINARIES?! (except HTML/JS!) The toString()
function should just return a blank string from binary NodeJS apps.
This would be really useful.

Brandon Benvie

unread,
Feb 27, 2012, 5:26:37 AM2/27/12
to nod...@googlegroups.com
V8 primarily stores javascript as javascript code and it's been stated in multiple places that javascript source code as source code is actually one of the most efficient ways to ways to store js source. This article by the original creator of emscripten discusses comparisons C/C++ libraries compiled to Javascript via LLVM-->js where the js is roughly equal to the *compiled* binaries in source code size, is as fast or faster as any hand-written code, and the gap between efficiency of compiled c/c++ and js as an ever narrowing gap. 

There's a distinct problem with the goal of attempting to obfuscate/secure distributed Javascript code when the consensus behind implementations is behind continuing to use source-code as not only the method of distribution, but as the actual internal representation the virtual machine uses to store most of the code while its executing.

Brandon Benvie

unread,
Feb 27, 2012, 5:31:20 AM2/27/12
to nod...@googlegroups.com
To further expatiate, the reason behind using JavaScript source itself as the storage is made clear on what little documentation exists for V8.  http://code.google.com/apis/v8/design.html 

Essentially the code is compiled to machine code as it's run, upon demand, based on system conditions and varying factors and the actual code execution itself. Time isn't spent doing optimizations and compilation on code until its shown to be hot code, often accessed, and in need of optimization. This is part of how V8 is fast, and why JavaScript is largely stored as raw JS sourcecode most of the time even during execution.

Jeremy Rudd

unread,
Feb 27, 2012, 5:36:36 AM2/27/12
to nodejs
On Feb 26, 7:18 pm, manimal45 <moshir.mik...@gmail.com> wrote:
> It would be awesome if 'customers' could download node.js apps as
> executable.

I've opened a new issue for this. Add your comments there!

https://github.com/joyent/node/issues/2835

Tim De Lange

unread,
Feb 27, 2012, 5:27:26 AM2/27/12
to nod...@googlegroups.com
There is no such thing as a javascript binary. The code included with node is stored in string format in the node executable.

In my opinion, this is not a Node problem to solve. Obfuscation/source code hiding is an opportunity for a third party to make a native module to encrypt/decrypt source files.

Because of the nature of javascript, there is no way to properly protect your source code. Even if toString returns blank, you'll be able to harvest the source code from the binary itself. 

And if you encrypt it, you'll have to somehow provide the key to decrypt it so it  can be run anyway.

With java and .net, the decompilation tools may not give you code that always compiles, but it almost always gives you enough information to add or replace the license checking code functions and classes by replacing the appropriate dll's /class files with your own ones.

If you need native code, do your coding in c++.

Most of us are standing on the shoulders of giants. This is why node is so great. But yet, we are selling software touting features that are really a gift from the Node community, and that we got for mostly free.

Try getting the same sort of quality in a web/network framework for free in the C++ world. You wont see many. The reason is simple, openness. 

You pay for Node's goodness by being trapped in openness. Same as with ruby, perl, php and the like.

Bitching cause the Node creators were generous enough to share their work with you, but  not  cheap enough to lock it down is ludicrous.

-Regards

Tim De Lange


Oliver Leics

unread,
Feb 27, 2012, 6:48:57 AM2/27/12
to nod...@googlegroups.com
Hallo Jeremy,

as a dev you are in the right position to tell the management the
truth: Every effort spent in "securing" an application from theft is a
effort better spend on other areas while developing the software. They
really have to decide if it pays out to "secure" the software more and
more. Mostly it will not.

Also: Maybe the business model is flawed or (at least) not optimal.
Sure, the costumer pays for a license. But they also pay for support,
continuous improvements of the software and content that the software
has to consume. They do not want to pay for making the software more
secure (secure in the way you want it to be secure) But they are
willing to pay for a good software-producer.

Go and tell the management the truth!

Oliver Leics

unread,
Feb 27, 2012, 6:52:11 AM2/27/12
to nod...@googlegroups.com
A software company has to offer more than just a binary.

Jeremy Rudd

unread,
Feb 27, 2012, 6:57:27 AM2/27/12
to nodejs
> There is no such thing as a javascript binary. The code included with node
> is stored in string format in the node executable.

No worries, what if the code was compiled via V8, and then stored as a
data file?
Whatever format it is in, if you could just load the same datafile you
would'nt need
the source code again.


> In my opinion, this is not a Node problem to solve. Obfuscation/source code
> hiding is an opportunity for a third party to make a native module to
> encrypt/decrypt source files.

You don't need to encrypt the source if you can just work with the
intermediate data format. See above.


> Most of us are standing on the shoulders of giants. This is why node is so
> great. But yet, we are selling software touting features that are really a
> gift from the Node community, and that we got for mostly free.

I'm sorry to sound capitalistic, but sometimes you need to make
commercial products for clients that are willing to pay. If my work
could be protected in such a case, it would help me. And yes, nodeJS
is a great gift, and I would look into giving whatever else I create
back.

> Bitching cause the Node creators were generous enough to share their work
> with you, but  not  cheap enough to lock it down is ludicrous.

Sorry if I sounded like I was bitching, I was just trying to make
NodeJS a more professional platform: .NET, Java, Flash all allow you
to 'compile' your app in some way and so I was just asking if
something like this could be implemented for node.

Best Regards

Dean Landolt

unread,
Feb 27, 2012, 9:02:35 AM2/27/12
to nod...@googlegroups.com
On Mon, Feb 27, 2012 at 6:57 AM, Jeremy Rudd <jrudd.d...@gmail.com> wrote:
> There is no such thing as a javascript binary. The code included with node
> is stored in string format in the node executable.

No worries, what if the code was compiled via V8, and then stored as a
data file?
Whatever format it is in, if you could just load the same datafile you
would'nt need
the source code again.


> In my opinion, this is not a Node problem to solve. Obfuscation/source code
> hiding is an opportunity for a third party to make a native module to
> encrypt/decrypt source files.

You don't need to encrypt the source if you can just work with the
intermediate data format. See above.


> Most of us are standing on the shoulders of giants. This is why node is so
> great. But yet, we are selling software touting features that are really a
> gift from the Node community, and that we got for mostly free.

I'm sorry to sound capitalistic, but sometimes you need to make
commercial products for clients that are willing to pay.

I was trying to keep my mouth shut but this is just too much. This short sentence is comically fallacious. To start with, if your clients are so willing to pay why are you bending over backwards to obfuscate? And nothing is stopping you from making commercial products -- certainly not node's license. This was addressed a few different ways in this thread, I'm not sure why you've chosen to ignore it. But more fundamentally: capitalism, like any economic system, is about the efficient allocation of resources in the face of scarcity. Once you've written your software it's no longer scarce. And please don't conflate capitalism with intellectual property -- the two are quite different.
 
If my work
could be protected in such a case, it would help me.

Then do the damn legwork yourself. Node has a wonderfully liberal license -- and that's a very good thing. Frankly it's developers like you that are to blame for the scourge of GPL software. Do what you will with the code, but you could benefit from trying to grok why you're getting the kind of responses you're seeing. 
 
And yes, nodeJS
is a great gift, and I would look into giving whatever else I create
back.

> Bitching cause the Node creators were generous enough to share their work
> with you, but  not  cheap enough to lock it down is ludicrous.

Sorry if I sounded like I was bitching, I was just trying to make
NodeJS a more professional platform: .NET, Java, Flash all allow you
to 'compile' your app in some way and so I was just asking if
something like this could be implemented for node.

More "professional"? Wow. Again, it wouldn't hurt to read up on the culture around open source -- if nothing else, it'll help you avoid getting flamed by saying things like this.

Tim De Lange

unread,
Feb 27, 2012, 9:45:12 AM2/27/12
to nod...@googlegroups.com
On Mon, Feb 27, 2012 at 4:02 PM, Dean Landolt <de...@deanlandolt.com> wrote:


Whatever format it is in, if you could just load the same datafile you
would'nt need
the source code again.

Wrong.

> In my opinion, this is not a Node problem to solve. Obfuscation/source code
> hiding is an opportunity for a third party to make a native module to
> encrypt/decrypt source files.

You don't need to encrypt the source if you can just work with the
intermediate data format. See above.

There is no universal  intermediate data format. Any binary representation that may be created in memory, is optimized and specific to the environment of that running instance, and will probably not run on all other installs of Node. This is not Java  or .net.

> Most of us are standing on the shoulders of giants. This is why node is so
> great. But yet, we are selling software touting features that are really a
> gift from the Node community, and that we got for mostly free.

I'm sorry to sound capitalistic, but sometimes you need to make
commercial products for clients that are willing to pay.

Plenty commercial products make good money without needing strict copy protection.  It is however true that certain markets are rife with piracy. And if your company is small and your clients are big, the balance of power might be against you. If this is the case, protect your program. However - don't lay this problem at Node's feet.

Remember, you are not a Node customer. Node owes you squat. The  Node community shared their code with you, so you are the one who has the debt, if anyone needs to listen, its you.

This is your problem, you've been given options, choose the best one and implement. If you have the same generous character as those before you, you will share what you make.

That's the great thing about opensource. You can fix it yourself.   
 
--
Regards

Tim De Lange

Lalo Martins

unread,
Mar 2, 2012, 12:36:54 AM3/2/12
to nod...@googlegroups.com
Well, if you can't be bothered listening to my arguments, here's the
quick answer: don't use Node.


best,
Lalo Martins
--
Now go and make your dreams inevitable.
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

Tim Caswell

unread,
Mar 2, 2012, 9:29:37 AM3/2/12
to nod...@googlegroups.com
I don't have experience with hiding source code (I tend to put everything I write on github out of habit), but I do know about keeping parts of code secure and out of the hands of anyone who might write a script using my library.

A quick example is a task I was working on at HP to ass http proxy support to nodejs services on webOS.  Node services on webOS can be written by third-party developers and can contain dangerous code.  WebOS sandboxes these node scripts in their own process and also inside a chroot jail.  But I needed to add a new http client API that transparently used the system's proxy settings if there was one.  Remember people are often behind corporate firewalls and need credentials to access the outside internet through a proxy. 

Now here is the dilemma.  How can I give the node process the credentials without giving the user's script in the node process the credentials?  We don't want third-party scripts having access to a user's corporate credentials, that would be a bad thing.  There were two proposed solutions:

 A: Run some node code at the beginning that gets the credentials from the system while the process is still running as root, hide the credentials in a private closure with no references and drop uid so that node code later can't ask for credentials. (something like this is already used to bootstrap the chroot).  Expose a public http client API that has closure access to the credentials, but doesn't give them out.
 B: Write a binary addon that knows how to get the credentials on demand, but only expose a http client API to the javascript.

A is security through user id permissions, B is security through obscurity.  If the node script was able to reverse engineer the protocol the binary addon used in B to get the credentials, it could do the same itself and publish the protocol to other users.

The point is, if someone has your code, they can eventually reverse engineer what it's doing, but yes, binary addons are much harder to do this to.  This problem isn't unique to node, and using binary addons is just as secure as anything else out there.  Especially if the code is running a user's machine where they have full access to examine the binary's bits.

Tim Caswell

unread,
Mar 2, 2012, 9:30:33 AM3/2/12
to nod...@googlegroups.com
*add HTTP proxy support (I should check more before sending)

On Fri, Mar 2, 2012 at 8:29 AM, Tim Caswell <t...@creationix.com> wrote:
I don't have experience with hiding source code (I tend to put everything I write on github out of habit), but I do know about keeping parts of code secure and out of the hands of anyone who might write a script using my library.

A quick example is a task I was working on at HP to add http proxy support to nodejs services on webOS.  Node services on webOS can be written by third-party developers and can contain dangerous code.  WebOS sandboxes these node scripts in their own process and also inside a chroot jail.  But I needed to add a new http client API that transparently used the system's proxy settings if there was one.  Remember people are often behind corporate firewalls and need credentials to access the outside internet through a proxy. 

Jeff Barczewski

unread,
Mar 2, 2012, 11:08:01 AM3/2/12
to nod...@googlegroups.com
One simple approach is to simply try to slow down the competition from stealing your code. Minimizing your code with something like uglify, should make it harder for someone to take code and continue to work with it (to make enhancements and changes), at least it would slow them down.

Then you continue to evolve your product with continual improvements making it less desirable for someone to go to a stagnant competitor.

Of course you can also open source some or all of the product and hopefully get community to help improve the code and just sell commercial licenses, support, add ons or services. You could even have some parts that one needs to be connected to use (which is not distributed).


I do agree that having a way to deliver standalone node.js apps is valuable too. The more ways we can use and deliver node.js the better. It could start as simply a self extracting archive that launches itself and cleans up when done. I have used things like that before with windoze and Ruby until jRuby came along and made it better to use precompiled JAR. The packaging of the app into single file can also help with making it more difficult to get at the code.

Just my thoughts. Your mileage may vary.

Jeff

Baz

unread,
Mar 3, 2012, 9:49:28 PM3/3/12
to nod...@googlegroups.com
And if your company is small and your clients are big, the balance of power might be against you.

In my experience, large enterprises pirate the least. They have too much to lose not to pay a little license fee, they pre-plan their expenditures far in advance, and the money comes out of a collective budget, not painfully from an individual's pocket.

Small companies are often too cash-strapped to pay for too many licenses - if they don't pirate, they just wouldn't use it (kind'of like torrenting a movie you'd never pay for). Just charge enough to be happy knowing they're pirating, and wait for them to upgrade. 

Don't sell to medium sized companies :)




Michael J. Ryan

unread,
Mar 4, 2012, 2:03:10 AM3/4/12
to nod...@googlegroups.com
I don't know why he doesn't just create a few core components in a c library/module and use guilty or closure to obfuscate the rest... Or, look into an ASP (Application Service Provider) model.

As to binary deployments... .net and java are both mentioned as more professional, and neither are stand alone deployments... I do .Net for my day job... I see this mindset a lot.



-- Sent from my HP TouchPad

Alan Gutierrez

unread,
Mar 4, 2012, 5:31:15 AM3/4/12
to nod...@googlegroups.com
On 2/26/12 9:18 AM, manimal45 wrote:
> I think original poster knows about business/contracts protection.
> His question seems to me technical, and would be far from ideal to
> consider the case closed.

The original poster probably does not know about copyright and
contracts, otherwise they would not be heaping on the cost and agony of
a special build to prevent copying of code. The original poster is
making a common mistake. Lalo is giving the appropriate answer.

This came up in comp.lang.perl.misc daily back in the day, before there
was much of an understanding of open source, because tools like VB
generated binaries, and that's how you protected your "codes".


> I'm surprised there's no easy way to deploy node.js easily. But maybe
> I'm wrong.

Appliance. Any x86 operating system can run as a guest on any other x86
operating system. Deploy your application as an appliance.

--
Alan Gutierrez - @bigeasy

Ken

unread,
Mar 5, 2012, 12:42:17 AM3/5/12
to nod...@googlegroups.com
I realize this thread has largely devolved into a philosophical discussion about whether one *should* do this, but I think the technical question of how one *could* do this is still a valid one.  I've thought about this a while and so far the only practical and secure answer I've come up with is to encrypt the javascript using PGP or a similar scheme.   This would require a custom built version of the node executable that is capable of reading the encrypted files because it has the public key baked in.  You'd use the private key to encrypt the javascript files that you distribute with your application.  Some care would need to be taken to ensure that the executable couldn't be coerced into producing decrypted versions of your files.

--Ken

On Thursday, February 23, 2012 7:56:43 AM UTC-8, Jeremy Rudd wrote:
What: Can NodeJS apps be distributed as binary? ie. you compile the .js app via V8 into its native binary, and distribute the binary to our clients? ... or is minifying the code all you can do?

Why: We build serverside applications in NodeJS for clients, that have often to be hosted on the client's servers. Distributing source code means clients can easily steal our solution and stop paying licensing fees. This opens up the possibility of easy reverse-engineering or reuse of our apps without our awareness.

Dean Landolt

unread,
Mar 5, 2012, 9:45:41 AM3/5/12
to nod...@googlegroups.com
On Mon, Mar 5, 2012 at 12:42 AM, Ken <ken.wo...@gmail.com> wrote:
I realize this thread has largely devolved into a philosophical discussion about whether one *should* do this, but I think the technical question of how one *could* do this is still a valid one.  I've thought about this a while and so far the only practical and secure answer I've come up with is to encrypt the javascript using PGP or a similar scheme.   This would require a custom built version of the node executable that is capable of reading the encrypted files because it has the public key baked in.  You'd use the private key to encrypt the javascript files that you distribute with your application.  Some care would need to be taken to ensure that the executable couldn't be coerced into producing decrypted versions of your files.

Either you're misunderstanding PKI or I'm misunderstanding you. But you do realize that in this scheme you still have to hand your client -- the person you're trying to hide your valuable secrets from -- the private key? Sure, you can bury it in layers of obscurity but it's there, and with the right tools will be in plain sight at some point.

Oliver Leics

unread,
Mar 5, 2012, 9:51:34 AM3/5/12
to nod...@googlegroups.com
On Mon, Mar 5, 2012 at 6:42 AM, Ken <ken.wo...@gmail.com> wrote:
> I realize this thread has largely devolved into a philosophical discussion
> about whether one *should* do this, but I think the technical question of
> how one *could* do this is still a valid one.

It is _not_ a philosophical conclusion that in most cases it is not
worth the effort to add multiple encryption layers. If at all, it is a
economical conclusion.

Technically none of the so called *coulds* are valid. They remain
broken and you end up with adding layer after layer after layer, all
of them beeing broken.

Philosophically: You add all thoose layers not for real security, you
add them to feed the paranoia of you and your clients. Let go that
paranoia and you are free again to focus on the real problems of your
software and your clients.

> I've thought about this a
> while and so far the only practical and secure answer I've come up with is
> to encrypt the javascript using PGP or a similar scheme.

This is _not_ secure, its only a "make it as hard as we can"

As you sayed:

> This would
> require a custom built version of the node executable that is capable of
> reading the encrypted files because it has the public key baked in. You'd
> use the private key to encrypt the javascript files that you distribute with
> your application.

If you deliver the key with the encrypted content, why encrypt them at all?

> Some care would need to be taken to ensure that the
> executable couldn't be coerced into producing decrypted versions of your
> files.

Its not "Some care", it is "Mission Impossible"

Been there, done that.

billywhizz

unread,
Mar 5, 2012, 11:59:42 AM3/5/12
to nod...@googlegroups.com, oliver...@gmail.com
oliver is correct. have had this argument many times. all you can ever do is make the source code difficult to get at and it's a question of how much effort you want to expend to do that. with something like v8, it's going to be difficult to even make it difficult as all someone will have to do is attach a v8 debugger and they can look at whatever they want...

best you can do would probably to compile the js source into the binary and at least that way it's not sitting on the filesystem as a text file so anyone can find it.

Ken

unread,
Mar 6, 2012, 4:32:42 AM3/6/12
to nod...@googlegroups.com


The private key would be kept by you.  You do have to "give" them the public key in some sense, but it would be embedded within the custom built node executable, probably somewhere within the call chain for require.  The encrypted javascript files could be required by this version of node but not by any other, and would be of no use without it.  Embedding keys within applications is a common approach and while it is subject to a variety of attacks and the source of many infamous hacks (like DeCSS), a variety of reasonably effective techniques for obfuscating them are available.  Obviously any sufficiently dedicated hacker organization could probably still crack your system but for that level of effort they could probably recreate the original software as well.  A more obvious concern arises from the fact that node is capable of executing arbitrary code, so for far less effort than recovering your key someone could probably craft a javascript program that extracts the source after it's been decrypted.  You'd need to prevent your version of node from running such scripts, perhaps by requiring all input to be encrypted or at least signed.  If you make use of third party modules you'd need to provide encrypted versions of them as well, otherwise someone could highjack a trusted module's methods for a similar purpose.

--Ken

On Monday, March 5, 2012 6:45:41 AM UTC-8, Dean Landolt wrote:

Dean Landolt

unread,
Mar 6, 2012, 5:15:54 PM3/6/12
to nod...@googlegroups.com
On Tue, Mar 6, 2012 at 4:32 AM, Ken <ken.wo...@gmail.com> wrote:


The private key would be kept by you.  You do have to "give" them the public key in some sense, but it would be embedded within the custom built node executable, probably somewhere within the call chain for require

The custom built node executable you "give" your client, per chance? QED.
 
--

Mark Hahn

unread,
Sep 18, 2012, 12:47:08 PM9/18/12
to nod...@googlegroups.com
 Distributing source code means clients can easily steal our solution and stop paying licensing fees. 

This has been a problem since the beginning of the software industry.  The only proven solution is to give enough support to make it worth their paying for.  Obfuscating and DRM never fully work.  Even shipping binaries is just a form of obfuscation.

However, you can usually make money with obfuscation by just counting on most customers being too lazy to hack it.

I can buy almost any product, including microsoft products, on a warez site.

On Mon, Sep 17, 2012 at 8:25 PM, Matthew de Detrich <mdede...@gmail.com> wrote:
Instead of trying to villify the poster (because a few posters here who are saying that securely boxing applications is useless appear to have little understanding of how some companies operate, and the fact that even though its theoretically possible to reverse engineer something, its practically impossible to reverse engineer an obfuscated C binary to a usable state as compared to some of the other languages listed), the better answer is to simply say that this kind of distribution is not possible with node.js simply because of the language javascript

Javascript is a fully dynamic language which has things like eval() and toString(). These things essentially mean that you cannot guarantee, 100% of the time, that your binary distribution of node.js (if you could do this) would work. There is code out there for example, which relies on toString() actually working properly, for the code to work (such as getting function names). Most static languages do not have these kinds of properties, and hence it is possible to completely transform the code into an obfuscated binary

This is unfortunately the downside of languages like Javascript and Ruby. The distribution methods are just boxing the application up with a VM that runs your packed source (and obviously you can obfuscate the source, something like Google Closure Compiler does) however thats far from distributing it as a binary. I am pretty sure that someone can create binary distributions of the node.js applications with a disclaimer that it may break your code, but there is very little demand for a such a feature :) 


On Friday, 24 February 2012 02:56:43 UTC+11, Jeremy Rudd wrote:
What: Can NodeJS apps be distributed as binary? ie. you compile the .js app via V8 into its native binary, and distribute the binary to our clients? ... or is minifying the code all you can do?

Why: We build serverside applications in NodeJS for clients, that have often to be hosted on the client's servers. Distributing source code means clients can easily steal our solution and stop paying licensing fees. This opens up the possibility of easy reverse-engineering or reuse of our apps without our awareness.

--

Roger WANG

unread,
Feb 26, 2013, 1:19:24 AM2/26/13
to Jeremy Rudd, nod...@googlegroups.com
Jeremy Rudd <jrudd.d...@gmail.com> writes:

> *What:* Can NodeJS apps be distributed as binary? ie. you compile the .js
> app via V8 into its native binary, and distribute the binary to our
> clients? ... or is minifying the code all you can do?
>
> *Why:* We build serverside applications in NodeJS for clients, that have
> often to be hosted on the client's servers. Distributing source code means
> clients can easily steal our solution and stop paying licensing fees. This
> opens up the possibility of easy reverse-engineering or reuse of our apps
> without our awareness.
>
> *Shamelessly cross posted on*:
> http://stackoverflow.com/questions/9413123/secure-distribution-of-nodejs-applications

In node-webkit we just released an experimental feature for this -- the
JavaScript source code is compiled to native binary with v8 snapshot
feature. I believe the same thing can be done for Node.js

See
https://github.com/rogerwang/node-webkit/wiki/Protect-JavaScript-source-code-with-v8-snapshot

Thanks
--
Roger WANG Intel Open Source Technology Center

https://github.com/rogerwang/node-webkit
node-webkit: Call all Node.js modules directly from DOM and enable
a new way of writing applications with all Web technologies.

Igor Klopov

unread,
Feb 8, 2015, 9:02:08 AM2/8/15
to nod...@googlegroups.com, jrudd.d...@gmail.com
The V8 snapshot feature from nwjs was significantly improved
ind injected in vanilla io.js/node.js. And EncloseJS was created.
EncloseJS is a compiler for io.js/node.js projects. The snapshots
dont include source code and can be of any size. No decryption
in compiled application - only execution of compiled native code.

Boris Matos Morillo

unread,
Feb 8, 2015, 10:37:10 PM2/8/15
to nod...@googlegroups.com, jrudd.d...@gmail.com
This is awesome!!

DavidCaI

unread,
Sep 7, 2016, 5:02:42 PM9/7/16
to nodejs
Reply all
Reply to author
Forward
0 new messages