views:

719

answers:

13

If I write a client-side Javascript app (with a little bit of server interaction), how can I prevent people from copying the Javascript files to their own site? Should I, at all?

+11  A: 

The best you can do is obfuscate the code so that others will have a hard time modifying it. Of course, you keep a copy of the original.

As a bonus, obfuscated code should be smaller and therefore quicker to load.

01
That's called Javascript minimization, isn't it?
Jonathan Leffler
minification actually
Matt Briggs
+4  A: 

You could obfuscate (or at least minify) the code to discourage this (although it's not unstoppable for someone who has the time. For example, the StackOverflow's deobfuscation of the WMD editor (but this was for a good reason!)).

Really any code you put frontend is going to be public and available for all to see/use.

Ross
WMD editor wasn't obfuscated, it was just minified.
lubos hasko
Minifying JavaScript has the nice side affect of obfuscating it as well... var va = fa(); is as well as obfuscated.
Unkwntech
+2  A: 

We use a lot of Javascript (and a lot of server-side) code for our web application, and we chose to "obfuscate" the Javascripts be removing any white-spaces, line breaks etc. - this will not really protect your code, but make it very very hard to read & understand, and most likely others will not bother due to the effort involved.

The reason we do this, however, is not so much that we do not want anyone to copy parts of our code, but rather to discourage our partners/customers to whom we deliver the code from making modifications directly in "our files" (to avoid troubles when the next update is installed)...

Note: Obfuscation has one disadvantage you should be aware of, though: if you ever need to debug that script code, you yourself will not be able to work with the obfuscated infromation, so this will always involve copying the 'readable' file to the server first.

ISW
I wouldn't call formatting Javascript in an editor or using some form of "pretty printer" to be a lot of effort. Reducing those things can be useful for reducing bandwidth (ie minify) but that's all.
cletus
If the Javascript file is large, it is a lot of effort. Also, "pretty printers" don't work well (or don't work at all) on the "one single line contains all code" type of files.
ISW
+17  A: 

Should you care? No.

Why? Because there's nothing you can really do about it.

Some have predictably suggested obfuscation. This works for Java and .Net but Python, Javascript and Perl are all plain text so there's very little you can really do. The value in your site is undoubtedly the server side so don't worry about the Javascript.

cletus
Quelle surprise, a downvote for stating the obvious /sigh.
cletus
What's wrong with renaming all functions and variables in a PHP file to some random string? That is exactly as good on "text files" as removing debug info from a DLL/JAR. Other obfuscation technologies can work as well. another -1 for denying the existence of a solution without explanation.
David Schmitt
That's the equivalent of stuffing your wallet and keys up to the end of your shoe when you go to the beach. It might make you feel better but it hardly secures them.
cletus
The reason why obfuscation works better on .NET and Java is because they are statically typed languages and therefore you can apply more tricks without breaking the code. It has nothing to do with plain text.
lubos hasko
I removed PHP from your post because PHP can be obfusicated so that you have to have special extensions installed for the code to be usable (namely zend), so infact PHP can be fully obfusicated.
Unkwntech
Unkwntech is speaking about stuff like Zend Guard by the way: http://www.zend.com/products/guard/
Michael Stum
And one could argue that Perl doesn't need obfuscation as it's almost more cryptic then RegEx :)
Unkwntech
@Michael Strum thanks for the link, I couldn't think of the exact name and was to lazy to look it up.
Unkwntech
Have you ever tried to read a minified javascript file, even though it is in plain text? -1
Matt Briggs
If I can figure out what I need to know from disassembled (allegedly) obfuscated Java, I think I can manage Javascript and I'm hardly an expert at such "hacking" or reverse engineering. "Information yearns to be free" (quote I heard somewhere).
cletus
The fact that you can't truely protect your JS doesn't mean you don't need to care. Why make it easy for those who intend to rip you off. No protection is absolute, the goal is to make overcoming the protection more costly than the gains to be had.
AnthonyWJones
Javascript has an innate defense: its tied to serverside code, which is inaccessible. Obfuscation is a placebo. It also makes it more difficult to diagnose error reports that you get. If someone is going to rip you off (and I think you're overstating the value of your JS code) you can't do much
cletus
My co-worker saw some cool javascript trick and he said that he will just steal it, because its javascript. he looked at javascript code and he could not understand where is the thing he wanted to steal. obfuscation does work with javascript.
01
And what was the cool trick in question?
cletus
The down votes make me laugh. Javascript is best used as a utility to enhance your site. The only code worth protecting is code that exposes information about the inner workings of your site and your company. Neither of these things belong in client script to begin with!
Jim Petkus
@Jim: don't I know it. I think the count is currently 17 upvotes, 8 downvotes and due to being at the daily rep cap my rep from this answer is... -16.
cletus
@cletus validation tooltip
01
+3  A: 

Why worry about it at all? If your scripts are worth stealing you could instead make them open source and get help in honing them.

PEZ
+3  A: 

I use GWT (the Google Web Toolkit) for writing web applications, in which the code is all written in Java and can be debugged and tested with Java-centric tools, but is converted into JavaScript for release.

When not in PRETTY or DETAILED mode, the JavaScript generated by GWT is very highly optimized and obfuscated, making it extremely impractical to reverse-engineer. (A traditional JavaScript obfuscator will provide a portion of these benefits -- but not where the optimizations are dependent on GWT's ability to do detailed branch pruning and code-path analysis).

That said, in general, I'm -1 on obfuscation -- it means, for instance, that legitimate customers are less able to help you figure out their problems, even when they happen to have development skills and a copy of FireBug. You're the original author -- you know the code better than anyone else, and that gives you a competitive advantage over someone who's trying to run a cheap knockoff; further, if any such competitor is actually making real money off something they stole without permission, that opens them up having that money (or, potentially, treble the sum) taken away in a lawsuit; legitimate and serious competition won't go that route, and why worry about the other kind?

Charles Duffy
+4  A: 

You can't really since it's an interpreted language that is always delivered in source code form. Even obfuscation is not going to help much if the pirate is motivated enough.

(Case-Example: The StackOverflow WMD Editor, which could be - stricly speaking - be seen as Piracy, although I know that Jeff and Dana only had good intentions)

Michael Stum
+8  A: 

Why do you worry? I see two reasons it could be: 1) You are writing a commercial JavaScript library. Solution: Get another business plan, JavaScript libs tend to be free. Perhaps you can make money in a small niche of enterprises, but they are most likely not going to use illegaly copied code anyway.

2) You worry that your competitor is going to copy your site. If they do, you can rest assured that you will always be one step ahead of them. More likely, they are going to write their own code and copy the appearance and behavior of your site and nothing can save you from that except for getting stupid software patents, e.g. amazon one-click shopping.

IOW, don't worry. Put a copyright notice asking people to tell you if they use your stuff. If enough people do it, use the fact that you have created a useful library to get credit among geeks, which probably will be beneficial in the long run.

erikkallen
It's a web application, not a library :). Thanks for #2.
sjmulder
+4  A: 

No. Do not try and "protect" a client-side scripting language. Obfuscation doesn't work. Minifying has its uses (but anti-piracy is not one of them)

I would also recommend against minifying your code unless you get thousands of hits per day, where a few extra kilobytes per request will be a noticeable difference (and only do that once you compress all the images you're using correctly, which will save you far more than a few KB, setup caching properly and so on)..

Even if you minify/obfuscate the Javascript, people can still quite trivially copy it to their own site. It'll be a bit more difficult to modify, but depending on what the script does, that may not matter. For example, the WMD Editor people have mentioned is supplied, for public use, minified.

Obfuscation and minification can be similar, but if you were to properly obfuscate the code, you would have to basically rewrite large segments of it to make it difficult to understand.. This makes the code more complicated, and far harder to deal with (for you), so will introduce bugs.. If your Javascript becomes buggy, that will prevent piracy, since no one will want to use (or steal) it.. but, err, that's not good.

One of the great things about Javascript is anyone can right-click/view-source and learn Javascript by looking at live, working code.. If you are worried about people looking at the code, and copying it, the web/Javascript isn't the right language..

I would recommend putting a comment at the start of all your .js files and <script> blocks, with your information (name, website), and a license of some kind. Depending on what the code is, perhaps putting a notice saying "If you use all or part of this code in a project, please let me know about it!" may be far more effective than "Do not use this code for any other purpose, ever!"

dbr
+1  A: 

Going on the assumption that any sufficiently good javascript will get picked up by others, how about just swimming with the current and making the most of it?

Slap a license on it which permits use while requiring for example attribution. Maybe with a non-commercial clause like some Creative Commons variants too, if you really must.

JosefAssad
+3  A: 

No. You should not worry at all.

If your business is dependent on the secrecy of your JavaScript code, there is some serious problem with it.

Otherwise, just don't bother. May be you should try minimizing your JavaScript code to make pages load faster.

Niyaz
+2  A: 

If you have trade secrets, you can move the most sensitive parts of the code to ActionScript (Flash). It's essentially the same language as JavaScript, and it's stored in tokenized form.

Nosredna
+1  A: 

Most of your application logic should be server-side. Javascript should only handle GUI stuff and simple interactions with the server. If your Javascript code contains enough application logic that you're worried about somebody stealing it, then you're probably doing something wrong.

davogones