Yes, here. Not at the source, though.

I mean, seriously, do you ever hear antivirus vendors complaining about UPX and all the other executable compression techniques used? Well, except for Norton and a few others who, once upon a time, decided that all packed .exe’s were evil (and strained their telephone-support department as a result), most vendors accept that it’s just one more variable they have to deal with.

It’s up to the developer(s) of a software package to deliver a high quality product. In JavaScript terms, that also means that it should have a low footprint (as evidenced by tests that the cache isn’t nearly as much used as you would have liked).

Besides, the single most important reason JavaScript developers use a packer is not because of it’s packing techniques (it’s quite feasible to compress without packing; gzip anyone?) but for it’s obfuscation techniques. You don’t want some scriptkiddy mangling your code and posting the mangled code everywhere. Knowledgable people with (perhaps) ill-intent can de-obfuscate the code anyways. If they can do it in two or three steps, it shouldn’t be too hard to automate the process.

So no, packing code does not provide a security threat. In it’s most extreme form (eval), it does use extra processing power on the client. But that’s another discussion alltogether.

Cows eat grass, Grass is green, Therefore cows are green.

Malware authors use packer on JavaScript, Packer obfuscates JavaScript code, Therefore JavaScript code obfuscated with Packer is malware.

This article was just written to get a rise out of people. So to sum this all up:
If you can use mod_deflate or mod_gzip then do so. If you can use Packer, YUI Min, or JSMin in your caching engine or in your build scripts (i.e. Ant) then do so. Don’t let untrusted sources gain access to your client’s code repository. Happy coding!

 
These are the individual exploits, basically copy-and-pasted proof of RealPlayer / Yahoo! Messenger DLL proof of concept exploit code (open + save arbitrary URL to c:\, etc.), complete with comments and everything from the sites publishing them – the catch is that these are doubly-obfuscated. First, they are compessed with Packer or something similar, and then the eval()ed result of that is a large document.write(unescape(bigAssString)) call, where the latter is some concatenated thing of escaped characters.
 
This I believe was used in exploit code hosted on “uc8010″ (dot com), related discussion at sans.org. I wasn’t able to quickly find any sample code, sorry. ;)

If you use variables in a global scope you are asking to get burned.

Packer does not shorten variable names in the global scope. I doubt that the YUI compressor does either.

When producing a professional client-side we should be concerned with code footprint not readability. The average web user is not going to read the code, but will notice when a page takes longer to load or is unresponsive. The individual developer is responsible for releasing a separate open source or reader friendly version for developers that is not compressed or packed.

It is not needless if it reduces download time by 70% for large scripts. Now that gzip can be used more safely, base62 encoding is not usually required. But to say that it is needless misses the point a little.

Aggressive packers introduce needless complexity and the potential for nasty hidden bugs (due to js’s acceptance of implied ‘;’ at the end of some lines, programs break when you remove “extra” line breaks, variable/method name replacement and reduction greatly magnifies the chance of namespace collisions in the js global scope). Stripping comments and then applying gzip will give your users a small download size without potential side effects.

Additionally, packed code is difficult for others to read and understand. A big part of the rapid spread in advanced js techniques that we’ve seen over the past 3 years can be attributed to this informal channel for the distribution of programming knowledge.

Dean Edwards’ Packer 3 and other compressors can pack as well as obfuscate. If you use the “Shrink variable” option without the “Base 62 encode” option then the code has its whitespace removed and variables shortened but it is not obfuscated (no use of eval()).

The “Shrink variable” method combined with gzipping usually produces the smallest file size so there is no need to use obfuscated compression.

Also, I believe (http://javascriptcompressor.com) is a web port of Dean Edwards’ Packer 2.

Even if they could convince us to stop using packers, they are never going to convince the malware authors to stop so its a moot point.