Blog

Here's what's on the minds of our marketing and technology experts.

For more perspectives from Sundog, check out Sundog: The Podcast and our knowledge.

RSS Icon Subscribe to blog feed What's this?

Jason Gibb
Director – Application Development

Jason follows the latest developments in Web 2.0 applications.

More posts by this author

Full Post

The Hidden Danger of Proprietary JavaScript

Recently Richard Stallman, long-time proponent of free and open source software (FOSS), posted an article about the “dangers” of proprietary JavaScript code. The argument goes something like this: Unlike desktop software that is installed voluntarily (where, presumably, the user can review a licensing agreement in advance), licensed JavaScript code may run automatically in your browser without your knowledge any time you view a Web page or run a Web application.

Browsers don’t normally tell you when they load Javascript programs. Most browsers have a way to turn off Javascript entirely, but none of them can check for Javascript programs that are nontrivial and non-free. Even if you’re aware of this issue, it would take you considerable trouble to identify and then block those programs.

I must admit I have never been a big fan of Stallman’s all-or-nothing approach to software licensing. As someone who makes a living in the Web software field, I see the need for both open and closed source options. Companies need the flexibility to choose a licensing scheme that works for their business model, and that does not necessarily need to be FOSS.

On the other hand, I am as guilty as the next Web developer of viewing the source on Web sites and applications to learn some obscure JavaScript or CSS technique. The openness of the Web has allowed this knowledge sharing to flourish, and we all benefit with more powerful, usable, and interesting Web applications. However, knowledge sharing becomes more difficult as savvy developers figure out how to lock down their client-side code. Right now tools like Packer and Minifier are used primarily for performance optimization for client-side JavaScript, but they are also quite good at code obfuscation.

Frankly, I don’t see browser makers picking up Stallman’s suggestion to provide better mechanisms to identify the license on JavaScript code. The responsibility will ultimately fall to Web developers to tell users of their Web products whether or not they are running proprietary licensed code. Then it will be up to the users to decide whether they care.

Don't miss any posts! Subscribe to our blog feed or only posts by Jason Gibb.

Short URL: http://sundog.net/e/3345

Comments

dasickis's avatar dasickis Posted on: Apr 23, 2009 at 01:52 PM

I don’t understand the issue here, can’t you just use firebug & greasemonkey to get around these issues? Obfuscated code isn’t the problem of the webdeveloper who is constrained by bandwidth costs. If you want to read the code, there are ways of deobfuscating code*. Then Gresemonkey can be used to actually run custom javascript on top of the existing webapp.

*Note:
http://isc.sans.org/diary.html?storyid=2358
http://securitylabs.websense.com/content/Blogs/2625.aspx

dasickis's avatar dasickis Posted on: Apr 23, 2009 at 02:00 PM

Actually, for some scary javascript, which Google isn’t using but is mostly from malware authors & security analysts, check out: http://ha.ckers.org. Admittedly, analyzing this code is similar to disassembling programs and using a hex editor but most obfuscated code on legitimate sites aren’t this complicated and there’s easy ways to deobfuscate them.

Jason Gibb's avatar Posted on: Apr 23, 2009 at 02:16 PM

dasickis, good point about deobfuscation tools. I think Stallman would argue that even with Firebug and Greasemonkey, it is unnecessarily difficult to determine where JavaScript code comes from, who created it, and what it does without first running it in your browser.

I see obfuscation as the first step down a path toward locking down client-side code, which just reinforces Stallman’s fears. However, I don’t agree with him that protected code in any form (whether by obfuscation, compilation, or even just restricted licensing) is always a bad thing.

dasickis's avatar dasickis Posted on: Apr 23, 2009 at 06:39 PM

Agreed. But I don’t see any other ways of locking code in the current iterations of Javascript. His fears are similar to “The Sky Is Falling” (like a lot of the FSF ideology, which I’m going to post about shortly; however, I do think the FSF is important in ensuring balance, but they seem unjustified many times). But in that case “unnecessarily difficult” even means some OSS projects. Just take a look at the code base for FFMpeg and you’ll see what I’m talking about ;)

Leave A Comment

Please help us stop spam by typing the word you see in the image below:

Contact Us

Fill out and send the form below to learn about our refreshing approach to measureable marketing, or call 1.888.9.sundog.

     
Follow us on:
Twitter
Facebook
Flickr
Slideshare