[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.
--
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
--
> *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
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
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!
> There is no such thing as a javascript binary. The code included with nodeNo worries, what if the code was compiled via V8, and then stored as a
> is stored in string format in the node executable.
data file?
Whatever format it is in, if you could just load the same datafile you
would'nt need
the source code again.
You don't need to encrypt the source if you can just work with the
> 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.
intermediate data format. See above.
I'm sorry to sound capitalistic, but sometimes you need to make
> 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.
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.
Sorry if I sounded like I was bitching, I was just trying to make
> Bitching cause the Node creators were generous enough to share their work
> with you, but not cheap enough to lock it down is ludicrous.
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.
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 codeYou don't need to encrypt the source if you can just work with the
> hiding is an opportunity for a third party to make a native module to
> encrypt/decrypt source files.
intermediate data format. See above.
> Most of us are standing on the shoulders of giants. This is why node is soI'm sorry to sound capitalistic, but sometimes you need to make
> 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.
commercial products for clients that are willing to pay.
best,
Lalo Martins
--
Now go and make your dreams inevitable.
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
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.
And if your company is small and your clients are big, the balance of power might be against you.
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
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
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.
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.
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.
--
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.Shamelessly cross posted on: http://stackoverflow.com/questions/9413123/secure-distribution-of-nodejs-applications
--