We Keep Coding

How does Gmail , Twitter, Grooveshark, and those web app built with pure javascript UI prevent people from stealing their code? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am currently considering to build a single page web app using restful api and put the entire UI logic in javascript on the client side. This design concept has been adopted by twitter and several other web apps.
However, I am wondering how to prevent user from stealing my javascript code, since my app logic is all stored in javascript. Does product like gmail, grooveshark, or twitter not care about this issue? do they not care if people can just replicate their app by copy the javascript? if so, does it not bring a lot of risk to the business?
I hope someone can answer my question as I am figuring out how other people are building their app. and if anyone has similar concern on this issue.

On a pure technical level you can't. Any Javascript code readable by a browser can be read by a developer UserAgent. In fact there are browser addons which allow the user to read the Javascript behind or linked by any web page.
Having said that, you can make hijacking of your Javascript code harder by using Minification. (eg: http://code.google.com/p/minify/)

As previously stated, there are no way to prevent "code stealing". Just remember we are in a world where code isn't valued anymore. It's so easy to build an application that what really matters is the branding around it.
Anyone can build a facebook of it's own, but the real value is the number of users on facebook. I don't believe that company tries to protect their code anymore, they in fact make it easy for you to get it via github or the likes. Talking about their products and the way there are made are more beneficial to them than you think.
Just take a look at twitter bootstrap. The investment they put in that code is well rewarded by all the people building apps on their technology. It reinforce the technical value of their systems.

You can minify/obfuscate your javascript code, making it essentially unreadably.
For example: http://code.google.com/p/minify/
or check this question:
How can I obfuscate (protect) JavaScript?

If your business requirements state that your source must remain a closely guarded secret and you are attempting to make a single webpage that contains all your business logic you have a conflicting design.
No matter how much obfuscation or minification you perform on your client-side code, there is going to be a way (simple browser plugins to firebug can do this) to deobfuscate your code.
There is no such thing as "security through obscurity".

Take a look at:
http://a0.twimg.com/b/1/bundle/phoenix-core-en-201112200936.js
http://a2.twimg.com/b/1/bundle/phoenix-more-en-201112200936.js
And consider how hard it is to extract useful information from the code.
This is some of the javascript code that your browser downloads when you visit a page on Twitter. This code has been minified (to make it more efficient to move around the network) and obfuscated (to make it harder to read). These techniques make it much harder for the casual user to re-use or reverse-engineer your code. Tools for doing this a widespread and include: Google's Closure Compiler, Yahoo's YUI Compressor, and others.
No such tool is perfect, however. They won't stop a determined hacker -- of course, a determined hacker could probably just reproduce the functionality, which leads to your best defense, IMHO -- which is your copyright.
When you create software, that software is protected by copyright law, in much the same way as other works are (see Software Copyright). If you create a hot new javascript app, and someone rips the code and puts it in their app, you have grounds for legal action. However, the law doesn't just prevent them from using it exactly "as is". From Wikipedia:
There is a certain amount of work that goes into making copyright
successful and just as with other works, copyright for computer
programs prohibits not only literal copying, but also copying of
"nonliteral elements", such as program structure and design.
This can be very valuable protection.

Javascript library: to obfuscate or not to obfuscate - that is the question [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I need to write a GUI related javascript library. It will give my website a bit of an edge (in terms of functionality I can offer) - up until my competitors play with it long enough to figure out how to write it by themselves (or finally hack the downloaded script). I can accept the fact that it will be emulated over time - thats par for the course (its part of business). I just want to have a few months breathing space where people go "Wow - how the f*** did they do that?" - which gives me a few months of free publicity and some momentum to move onto other things.
To be clear, I am not even concerned about hard core hackers who will still hack the source - thats a losing battle not worth fighting (and in any case I accept that my code is not "so precious"). However, what I cannot bear, is the idea of effectively, simply handing over all the hard work that would have gone into the library to my competitors, by using plain javascript that anyone can download and use. If someone is going to use what I have worked on, then I sure as hell don't want to simply hand it over to them - I want them to work hard at decoding it. If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order) - So, I'm not claiming that no one could have written this (which would be a preposterous claim in any case) - but rather, what I am saying is that no one (up to now) has made the functionality I am talking about, available to this particular industry - and I (thinking as an entrepreneur rather than a geek/coder), want to milk it for all its worth, while it lasts i.e until it (inevitably) gets hacked.
It is an established fact that not one website in the industry I am "attacking" has this functionality, so the value of such a library is undeniable and is not up for discussion (i.e. thats not what I'm asking here).
What I am seeking to find out are the pros and cons of obfuscating a javascript library, so that I can come to a final decision.
Two of my biggest concerns are debugging, and subtle errors that may be introduced by the obfuscator.
I would like to know:
How can I manage those risks (being able to debug faulty code, ensuring/minimizing against obfuscation errors)
Are there any good quality industry standard obfuscators you can recommend (preferably something you use yourself).
What are your experiences of using obfuscated code in a production environment?

If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order).
So really, you're trying to solve a business issue with technical measures.
Anybody worth his salt as a Javascript programmer should be able to recreate whatever you do pretty easily by just looking at the product itself, no code needed. It's not like you're inventing some new magical thing never seen before, you're just putting pieces together in a new way, as you admit yourself. It's just Javascript.
Even if you obfuscate the script, it'll still run as-is, competitors could just take it and run with it. A few customizations shouldn't be too hard even with obfuscated code.
In your niche business, you'll probably notice pretty quickly if somebody "stole" your script. If that happens, it's a legal issue. If your competitors want to be in the clear legally, they'll have to rewrite the script from scratch anyway, which will automatically buy you some time.
If your competitors are not technically able to copy your product without outright stealing the code, it won't make a difference whether the code is in the clear or obfuscated.

While you can go down the long, perilous road of obfuscators, you generally don't see them used on real, production applications for the simple reason that they don't really do much. You'll notice that Google apps, which is really a whole heap of proprietary and very valuable JavaScript when you get down to it, is only really minimized and not obfuscated, though the way minimizers work now, they are as good as obfuscated. You really need to know what you're doing to extract the meaning from them, but the determined ones will succeed.
The other problem is that obfuscated code must work, and if it works, people can just rip it wholesale, not understanding much of it, and use it as they see fit in that form. Sure, they can't modify it directly, but it isn't hard to layer on some patches that re-implement parts they don't like without having to get in too deep. That is simply the nature of JavaScript.
The reason Google and the like aren't suffering from a rash of cut-and-paste competitors is because the JavaScript is only part of the package. In order to have any degree of control over how and where these things are used, a large component needs to be server-based. The good news is you can leverage things like Node.js to make it fairly easy to split client and server code without having to re-implement parts in a completely different language.
What you might want to investigate is not so much obfuscating, but splitting up your application into parts that can be loaded on-demand from some kind of service, and as these parts can be highly inter-dependent and mostly non-functional without this core server, you can have a larger degree of control over when and where this library is used.
You can see elements of this in how Google is moving to a meta-library which simply serves as a loader for their other libraries. This is a step towards unifying the load calls for Google Apps, Google AdSense, Google Maps, Google Adwords and so forth.
If you wanted to be a little clever, you can be like Google Maps and add a poison pill your JavaScript libraries as they are served dynamically so that they only operate in a particular subdomain. This requires generating them on an as-needed basis, and while it can always be removed with sufficient expertise, it prevents wholesale copy-paste usage of your JavaScript files. To insert a clever call that validates document.href is not hard, and to find all these instances in an aggressively minimized file would be especially infuriating and probably not worth the effort.

Javascript obfuscation facts:
No one can offer a 100% crack free javascript obfuscation. This means that with time and knowledge every obfuscation can be "undone".
Minify != obfuscation: When you minify your objective is: reduce code size. Minified code looks completly different and its much more complex to read (hint:jsbeautifier.com). Obfucation has a completly different objective: to protect the code. The transformations used try to protect Obfuscated code from debugging and eavesdropping. Obfuscation can even produce a even bigger version of the original code which is completely contrary to the objectives of minification.
Obfuscation != encryption - This one is obvious but its common mistake people make.
Obfuscation should make debugging much much harder, its one of it objectives. So if it is done correctly you can expect to loose a lot of time trying to debug obfuscated code.That said, if it is done correctly the introduction of new errors is a rare issue and you can easily find if it is an obfuscation error by temporarily replacing the code with non obfuscated code.
Obfuscation is NOT a waste of time - Its a tool. If used correctly you can make others waste lots of time ;)
Javascript obfuscation fiction: ( I will skip this section ;) )
Answer to Q2 - Sugested obfuscation tools:
For an extensive list of javascript obfuscator: malwareguru.org. My personal choice is jscrambler.com.
Answer to Q3 - experiences of using obfuscated code
To date no new bugs introduced by obfuscation
Much better client retention. They must come to the source to get the source;)
Occasional false positives reported by some anti-virus tools. Can be tested before deploying any new code using a tool like Virustotal.com

Standard answer to obfuscation questions: Is using an obfuscator enough to secure my JavaScript code?
IMO, it's a waste of time. If the competitors can understand your code in the clear (assuming it's anything over a few thousand lines...), they should have no trouble deobfuscating it.
How can I manage those risks (being
able to debug faulty code,
ensuring/minimizing against
obfuscation errors)
Obfuscation will cause more bugs, you can manage them by spending the time to debug them. It's up to the person who wrote the obfuscation (be it you or someone else), ultimately it will just waste lots of time.
What are your experiences of using
obfuscated code in a production
environment?
Being completely bypassed by side channel attacks, replay attacks, etc.
Bugs.

Google's Closure Complier obfuscates your code after you finish writing it. That is, write your code, run it through the compiler, and publish the optimized (and obfuscated) js.
You do need to be careful if your using external js that interfaces with the lib though because it changes the names of your objects so you can't tell what is what.

Automatic full-code obfuscation is so far only available in the Closure Compiler's Advanced mode.
Code compiled with Closure Advanced mode is almost impossible to reverse-engineer, even passing through a beautifier, as the entire code base (includinhg the library) is obfuscated. It is also 25% small on average.
JavaScript code that is merely minified (YUI Compressor, Uglify etc.) is easy to reverse-engineer after passing through a beautifier.
If you use a JavaScript library, consider Dojo Toolkit which is compatible (after minor modifications) with the Closure Compiler's Advanced mode compilation.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

You could adopt an open-source business model and license your scripts with the GPL or Creative Commons BY-NC-ND or similar

While obfuscation in general is a bad thing, IMHO, with Javascript, the story is a little different. The idea is not to obfuscate the Javascript itself but to produce shorter code length (bandwidth is expensive, and that first-time users may just be pissed off waiting for your Javascript to load the first time). Initially called minification (with programs such as minify), it has evolved quite a bit and now a full compiler is available, such as YUI compiler and Google Closure Compiler. Such compiler performs static checking (which is a good thing, but only if you follow the rules of the compiler), minification (replace that long variable name with 'ab' for example), and many other optimization techniques. At the end, what you got is the best of both worlds, coding in non-compiled code, and deploying compiled (, minified, and obfuscated) code. Unfortunately, you would of course need to test it more extensively as well.

The truth is obfuscator or not, any programmer worth his salt could reproduce whatever it is you did in about as much time as it took you. If they stole what you did you could sue them. So bottom line from the business point of view is that you have, from the moment you publish, roughly the same amount of time it took you to implement your design until a competitor catches up. Period. That's all the head start you get. The rest is you innovating faster than your competitors and marketing it at least as well as they do.

Write your web site in flash, or better yet in Silverlight. This will give your company unmatched GUI, that your competitors will be salivating about. But compiled nature of flash/dotnet will not allow them easily pick into your code. It's a win/win situation for you ;)

Javascript Distributed Computing [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Why aren't there any Javascript distributed computing frameworks / projects? The idea seems absolutely awesome to me because:
The Client is the Browser
Iteration can be done with AJAX
Webmasters could help projects by linking the respective Javascript
Millions or even billions of users would help DC projects without even noticing
Please share your views on this subject.
EDIT: Also, what kind of problems do you think would be suitable for JSDC?
GIMPS for instance would be impossible to implement.

I think that Web Workers will soon be used to create distributed computing frameworks, there are some early attempts at this concept. Non-blocking code execution could have been done before using setTimeout, but it made a little sense as most browser vendors focused on optimizing their JS engines just recently. Now we have faster code execution and new features, so running some tasks unconsciously in background as we browse the web is probably just a matter of months ;)

There is something to be said for 'user rights' here. It sounds like you're describing a situation where the webmaster for Foo.com includes the script for, say, Folding#Home on their site. As a result, all visitors to Foo.com have some fraction of their CPU "donated" to Folding#Home, until they navigate away from Foo.com. Without some sort of disclaimer or opt-in, I would consider that a form of malware and avoid vising any site that did that.
That's not to say you couldn't build a system that asked for confirmation or permission, but there is definite potential for abuse.

I have pondered this myself in the context of item recommendation.
First, there is no problem with speed! JIT compiled javascript can be as fast as unoptimized C, especially for numeric code.
The bigger problem is that running javascript in the background will slow down the browser and therefore users may not like your website because it runs slowly.
There is obviously an issue of security, how can you verify the results?
And privacy, can you ensure sensitive data isn't compromised?
On top of this, it's quite a difficult thing to do. Can the number of visits you receive justify the effort that you'll have to put into it? It would be better if you could run the code transparently on either the server or client-side. Compiling other languages to javascript can help here.
In summary, the reason that it's not widespread is because developers' time is more valuable than server time. The risk of losing user data and the inconvenience to users outweighs the potential gains.

First that comes to my mind is security.
Almost all distributed protocols that I know have encryption, thats why they prevent security risks. Although this subject is not so innovative..
http://www.igvita.com/2009/03/03/collaborative-map-reduce-in-the-browser/
Also Wuala is a distributed system, that is implemented using java applet.

I know of pluraprocessing.com doing similar thing, not sure if exactly javascript, but they run Java through browser and runs totally in-memory with strict security.
They have 50,000 computers grid on which they have successfully run applications even like web-crawling (80legs).

I think we can verify results on some kind of problem.
Let's say we have n number of items and need to sort it. We'll give it to worker-1, worker-1 will give us the result. We can verify it O(n) time. Please consider that it take at least O(n*log(n)) time to produce the result. Additionally we should consider how large is n items? (concern about network speed)
Another example, f(x)=12345, and function is given. Purpose is to find value of x. We can test it by replace x with some worker's result. I think some problems that are not verifiable are difficult to give to someone.

The whole idea of Javascript Distributed Computing has number of disadvantages:
single point of failure - there is no direct way to comunicate between nodes
natural fails of nodes - every node is working as long as browser
no guarantee that message sent will be ever received - according to natural fails of nodes
no guarantee that message received have been ever sent - because some hacker can interpose
annoying load on client side
ethical problems
while there is only one (but very tempting) advantage:
easy and free access to milions of nodes - almost every device has JS supporting browser nowadays
However the biggest problem is corelation between scalability and annoyance. Let's say you offer some attractive web service and run computing on client side. More people you use for computing, more people are annoyed. More people are annoyed, less people use your service. Well, you can limit annoyance (computing), scalability or try something between.
Consider google for example. If google will run computations on client side, some people will start to use bing. How many ? Depends on annoyance level.
The only hope for Javascript Distributed Computing may be multimedial services. As long as they consume lots of CPU, nobody will notice any additional load.

I think the no.1 problem is javascript inefficiency at computing. It wouldn't be just worth it, because an application in pure c/c++ would be 100 times faster.

I found a question similar to this a while back, so I built a thingy that does this. It uses web workers and fetches scripts dynamically (but no Eval!). Web workers sandbox the scripts so they cannot access the window or the DOM. You can see the code here, and the main website here
The library has a consent popup on first load, so the user knows what's going on in the background.

Why is JavaScript considered bad by some? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Why is JavaScript allowed to be disabled in the browser? (i.e. Why is it considered bad?)

<body onload="for(i=0; i<1000000; i++){window.open(
'samplesite.com?pageid=' + i);}">

Why is javascript allowed to be disabled in the browser? (i.e. Why is it considered bad?)
Because it can be grossly misused (blinking images, anyone?), may slow the browser down and of course there's always the (very justified!) fear of exploited security holes.

First of all with Javascript you can create events that the user might not want you to, like e.g. changing the size of the window...
On the other hand think about people who are somehow limited... What if your user was blind and uses a screenreader while your page continously changes its content somehow... There are many reasons against Javascript when it comes to accessibility...

Back in time, it used to be:
A source of annoying cursor-following animations (I am sure you remember stuff, like raining sheeps or clocks following your cursor... I want to find the smart*** who thought of that and slap them with a trout)
Considered insecure
Served no purpose but bog down the browser
However, over the years it has become more advanced and applied with more thinking behind it.

Historically it has been a huge security problem for web based services. Also with any technology that is exploitable and has a low technical barrier for entry it ends up the tool of the low brow trouble maker (script kiddies). Quick searches for javascript or xss in a security exploit database will show hundreds of pages of vulnerability.

JavaScript is often considered dangerous or at least annoying for two reasons:
Websites can suddenly do stuff that you don't want them to do, e.g. open popups
Websites can suddenly keep you from doing stuff that you want to do, e.g. disabling right-clicks
Now, in the vast majority of cases JavaScript is harmless and can really enhance the user experience (Ajax comes to mind). But all it takes is one malicious site that uses JavaScript to do evil (TM) things like Cross-site Scripting. For that reason it is commonly considered best practice to disable JavaScript globally and to allow it for just those sites or domains that you explicitly trust. In this day and age being paranoid on the Internet is actually a good thing.

It's a weakly-typed scripting language. Programmers who usually use "big strong" languages look down upon such nonsense. Shame on you for even considering using it, and my God have mercy on your soul.

It can cause security problems. Especially in old versions of IE (not so much anymore).
Or maybe it has something to do with Stallman's ranting ;-)

The main consideration is security. Drive-by downloads that exploit browser security holes via JavaScript are currently the most common way for malware to spread.

As well as what others have said it confuses search engines. The more 'dynamic' content you add the higher the chances it cannot be indexed. In addition the Internet is used by many as a reference library. Books in a real library do not change things around while you are reading the page. You may think of your site as an "application" but your users may prefer to treat it as a "document".
In short JavaScript obfuscates information, sometimes to the point of completely denying access (i.e., the JavaScript code is buggy and crashing). A classic example of this was that I was unable to watch the Live8 concert broadcast by AOL a few years back because the JavaScript code was so poorly written it didn't actually work on my girlfriends' AOL browser (ironic I know). I tried to get to the movie URL directly but the obfuscation was so complex I couldn't find it. It did nothing to endear me to AOL.
BTW, I happen to be one of those people who disable JavaScript by default. If I need it I can enable it for a specific site or page in 2 seconds (really) using the NoScript add-on for Firefox.

Some companies, or business units, have a policy of not allowing javascript turned on, as there are concerns about any risk of security exploits, and that may be the biggest problem, that since it can't be locked down securely then it must be disabled. If you can run javascript in a strict mode, that doesn't allow ajax requests, for example, then you may find that more people are willing to use it on computers that are concerned about security.
As long as a user can go to a website, and information can be sent transparently over the Internet regarding what a user is doing, then these security concerns will exist.
For example, I could have a Firefox plugin that appears to be useful, but, it can do possibly send unwanted info to a website.

Because it shifts load from the server to the client and there is no way to control to what extent.
I work with Javascript every day and respectfully acknowledge what it has made possible, but sometimes when I browse a very simple page, and the interface reacts lightning fast because there is nothing to render but pure, simple HTML, I think that that used to be the original purpose the purpose of the internet. You can, and I am exaggerating only little, browse these pages with a 600 MhZ Pentium with 128 megabytes of RAM without problems. While for a Javascript-heavy, effectful "rich" website, you need massive resources on the client side for a halfway smooth experience, and you need to update your equipent almost as often as gamers do.
Also, I generally feel some, not hostility, but slight annoyance towards Javascript because it massively increased development costs by adding a host of incompatible target platforms, version, obscurities and specialties to cater for, as well as a generally bug-prone, hard to debug and volatile environment to work in.
That said, I think the industry owes the creators of JQuery, Prototype and the likes big, big thanks, among many others.

JavaScript, as the inventor of JSON called it, is the virtual machine for the world. It's where billions of people are. This great exposure comes with some dangers other languages do not have to face.
Example. Write a site that just 'redirects' you to another site, where you can sign in. If you are not completely in control of your browser/URL etc. some JavaScript just could have loaded the page content from another site and will log your keystrokes. This could be achieved with a few lines of JavaScript. It's not really the fault (if it's a fault at all) of JavaScript, but all the components (browser, HTML, and this vast space, we call Internet).

Why is javascript allowed to be
disabled in the browser? (i.e. Why is
it considered bad?)
Because browsers are not prefect! And Its give you the way to safe yourself when you need it.
When security risk found out, they will just post in their home page
Please disable javascript until its fixed
Like this, (I dont have offical page right now, so googled from somewhere)
http://browsers.about.com/b/2009/07/16/firefox-3-5-users-should-take-action-immediately.htm
However, until a fix is released, I
recommend that you either disable
JavaScript completely or use another
browser.

There are a few rare instances where JavaScript can be dangerous (but so can anything, including the massively ubiquitous Flash). The reason users actually do disable it or use addons like NoScript is largely unjustified paranoia.
In the end, users don't stick with behavior that breaks the websites they want to experience. So, I wouldn't expect JavaScript paranoia to be a long-term issue as only more and more sites depend on it (like this one).
It's similar to the hype we saw around cookies several years ago.

It can crash the browser, or do annoying things to users.
However, now a days Javascript has become such an integrated part of the internet (Gmail, bill paying for many companies sites, ect) that if you did disable it then browsing could arguably be difficult for you unless you had exceptions.

JavaScript has some very "odd" language features, like the handling of missing semicolons at statement endings by just ignoring the parse error ("semicolon insertion") or the behaviour of the typeof operator (array is an object).
You really need to know the language to know which things you should do and which are bad.
But there are also really good points about the language, like that it fully supports functional programming.

It is bad only you visit questionable sites. Without javascript you won't have apps like gmail, yahoo finance, etc.

Why is JavaScript allowed to be disabled in the browser?
Perhaps because computers are tools that serve humans? Computers speaking to computers via a protocol can mandate specific behaviour. Developers writing software for users have no such luxury.
It would be pointless for browser vendors to mandate that JavaScript "must" be enabled, since there are plenty of people who can't or don't want it. Especially since 90% of the time it's just being used by some spotty hipster to animate a cat picture.

Is using an obfuscator enough to secure my JavaScript code?

I'm working on building a development tool that is written in JavaScript.
This will not be an open source project and will be sold (hopefully) as a commercial product.
I'm looking for the best way to protect my investment. Is using an obfuscator (code mangler) enough to reasonably secure the code?
Are there other alternatives that I am not aware of?
(I'm not sure if obfuscator is the right word, it's one of the apps that takes your code and makes it very unreadable.)

I'm going to tell you a secret. Once you understand it, you'll feel a lot better about the fact that Javascript obfuscation is only really useful for saving bandwidth when sending scripts over the wire.
Your source-code is not worth stealing.
I know this comes as a shock to the ego, but I can say this confidently without ever having seen a line of code you've written because outside the very few realms of development where serious magic happens, it's true of all source-code.
Say, tomorrow, someone dumped a pile of DVDs on your doorstep containing the source code for Windows Vista. What would you be able to do with it? Sure, you could compile it and give away copies, but that's just one step more effort than copying the retail version. You could painstakingly find and remove the license-checking code, but that's something some bright kid has already done to the binaries. Replace the logo and graphics, pretend you wrote it yourself and market it as "Vicrosoft Mista"? You'll get caught.
You could spend an enormous amount of time reading the code, trying to understand it and truly "stealing the intellectual property" that Microsoft invested in developing the product. But you'd be disappointed. You'd find the code was a long series of mundane decisions, made one after the other. Some would be smarter than you could think of. Some would leave you shaking your head wondering what kind of monkeys they're hiring over there. Most would just make you shrug and say "yeah, that's how you do that."
In the process you'll learn a lot about writing operating systems, but that's not going to hurt Microsoft.
Replace "Vista" with "Leopard" and the above paragraphs don't change one bit. It's not Microsoft, it's software. Half the people on this site could probably develop a Stack Overflow clone, with or without looking at the source of this site. They just haven't. The source-code of Firefox and WebKit are out there for anyone to read. Now go write your own browser from scratch. See you in a few years.
Software development is an investment of time. It's utter hubris to imagine that what you're doing is so special that nobody could clone it without looking at your source, or even that it would make their job that much easier without an actionable (and easily detectable) amount of cut and paste.

I deeply disagree with most answers above.
It's true that every software can be stolen despite of obfuscation but, at least, it makes harder to extract and reuse individual parts of the software and that is the point.
Maybe it's cheaper and less risky to use an obfuscation than leaving the code open and fighting at court after somebody stole the best parts of our software and made dangerous concurrency.
Unobfuscated code whispers:
Come on, analyze me, reuse me. Maybe you could make a better software using me.
Obfuscated code says:
Go away dude. It's cheaper to use your own ideas than trying to crack me.

You are going to be fighting a losing battle if you try to obfuscate your code in the hopes of someone not stealing it. You may stop the casual browser from getting at it, but someone dedicated would almost certainly be able to overcome any measure you use.
In the past I have seen people do several things:
Paste a lot of whitespace at the top of the page with a message telling people that the code is unavailable, when in actuality you just need to scroll down a few pages to get at it.
Running it through an encoder of some kind, this is so so useful as it can just be run through the decoder.
Another method is to reduce variable names to one character and remove whitespace (this is also an efficiency thing).
There are many other methods.
In the end, your efforts are only likely to stop the casual browser from seeing your stuff. If someone dedicated comes along then there is not much you will be able to do. You will have to live with this.
My advice would be to make a really awesome product that attracts the most people and beat off any competition by having the best product/service/community and not the most obfuscated code.

You're always faced with the fact that any user that comes to your webpage will download some working version of your Javascript source. They will have the source code. Obfuscating it may make it very difficult to be reused by someone with the intent to steal your hard work. However, in many cases someone can even reuse the obfuscated source! Or in the worst case they can unravel it by hand and eventually comprehend it.
An example of a situation like yours might be Google Maps. The Javascript source is clearly obfuscated. However, for really private/sensitive logic they push the data to the server and have the server process that information using XMLHttpRequests (AJAX). With this design you have the important parts on the server side, much more tightly controlled.

That's probably about the best you can do. Just be aware that anybody with enough dedication, can probably de-obfuscate your program. Just make sure you're comfortable with that before embarking on your project. I think the biggest problem with this would be to control who's using it on their site. If somebody goes to a site with your code on it, and likes what it does, it doesn't matter that they don't understand what the code does, or can't read it, when they can just copy the code, and use it on their own site.

A obfuscator won't help you at all if someone wants to figure out the code. The code still exists on the client machine and they can grab a copy of it and study it at their leisure.
There is simply no way to hide code written in Javascript since the source code has to be handed to the browser for execution.
If you want to hide your code, you have the following options:
1) Use an environment where compiled code (not source) is downloaded to the client, e.g. Flash or Silverlight. I'm not even sure that's foolproof, but it's certainly much better than Javascript.
2) Have a back end on the server side that does the work and a thin client that just makes requests to the server.

I'd say yes, it's enough if you also make sure than you compress the code as well using a tool like Dean Edward's Packer or similar. If you think about what is possible with tools like .NET Reflector in terms of reverse engineering compiled code / IL in .NET, you realize that there's nothing you can do to completely protect your investment.
On the other hand, remember that folks who release their source code also seem to make do quite nicely anyway - it's their experience that people want more than their intellectual property.

code obfuscator is enough for something that needs minimal protection, but I think it will definitely not enough to really protect you. if you are patient you can realy de-mangle the whole thing.. and i'm sure there are programs to do it for you.
That being said, you can't stop anyone from pirating your stuff because they'll eventually will break any kind of protection you create anyway. and it is espcially easy in scripted language where the code is not compiled.
If you are using some other language, maybe java or .NET, You can try doing things like "calling home" to verify that a license number matches a given url. Which works if you your app is some sort of online app that is going to be connected online all the time. But having access to the source, people can easily bypass that part.
In short, javascript is a poor choice for what you are doing.
A step up from what you are doing is maybe using a webservice backend to get your data. Let the webservice handle the authentication/verification process. Requires a bit of work to make sure it is bulletproof, but it might work

If this is for a website, which by its very nature puts viewing of its code one menu click away, is there really any reason to hide anything? If someone wants to steal your code they will most likely go through the effort of making even the most mangled code human readable. Look at commercial websites, they don't obfuscate their code, and no one goes out and steals code from the google apps. If you are really worried about code theft, I would argue for writing it in some other compiled language. (which does of course destroy the whole webapp thing...) Even then, you aren't totally safe, there are many de-compilers out there.
So really, there is no way to do what you want in the face of anyone with sufficient motivation.