By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,910 Members | 1,077 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,910 IT Pros & Developers. It's quick & easy.

The best way to protect javascript code?

P: n/a
if speed, size is not a matter, i just want to protect the code as much
as possible, any library or tools do you think is the best solution
right now?

i know there is not a perfect solution, but as good as it can be is
okay...

p.s. need to be cross brower

thanks.

Dec 9 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
howa wrote:
if speed, size is not a matter, i just want to protect the code as much
as possible, any library or tools do you think is the best solution
right now?

i know there is not a perfect solution, but as good as it can be is
okay...

p.s. need to be cross brower

There are zillions of obfusicators

google javascript obfuscation

Here is one but I don't know if it works well.
http://dean.edwards.name/packer/

There is always a risk of introducing bugs when obfusicating code and
the code won't be uncrackable.

http://yuiblog.com/blog/2006/03/06/m...v-obfuscation/

Peter

Dec 9 '06 #2

P: n/a
howa wrote on 09 dec 2006 in comp.lang.javascript:
if speed, size is not a matter, i just want to protect the code as much
as possible, any library or tools do you think is the best solution
right now?

i know there is not a perfect solution, but as good as it can be is
okay...

p.s. need to be cross brower
If your code is worth protecting, you will know alreadiy,
that protected JS can only be serverside JS.

If your clientside JS is worth being stolen,
no scheme will help you.

If your clientside JS is not worth being stolen,
why bother?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 9 '06 #3

P: n/a
You can make it a lot harder by using PHP or some sort of server side
language (PHP just happens to be my language of choice), and then
including the javascript and linking to it externally. In the PHP make
sure that the refferer is your site and if it isn't, dont print out the
page.

Dec 9 '06 #4

P: n/a
mo********@gmail.com wrote:
You can make it a lot harder by using PHP or some sort of server side
language (PHP just happens to be my language of choice), and then
including the javascript and linking to it externally. In the PHP make
sure that the refferer is your site and if it isn't, dont print out the
page.
The source has to be sent to the client. This technique does not make
it a lot harder to see the source. I am pretty darn sure it is still
visible with something like http://getfirebug.com

Peter

Dec 9 '06 #5

P: n/a
mo********@gmail.com wrote on 09 dec 2006 in comp.lang.javascript:
>
You can make it a lot harder by
Are you replying one something?

[please always quote on usenet]

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 9 '06 #6

P: n/a
Peter Michaux wrote:
mo********@gmail.com wrote:
>You can make it a lot harder by using PHP or some sort of
server side language (PHP just happens to be my language of
choice), and then including the javascript and linking to it
externally. In the PHP make sure that the refferer is your
site and if it isn't, dont print out the page.

The source has to be sent to the client. This technique does
not make it a lot harder to see the source. I am pretty darn
sure it is still visible with something like
http://getfirebug.com
There is no need get that complicated; view the files in the browser's
cache while the site is loaded and the external javascript files will be
there, regardless of whether they were dynamically greeted with
PHP/ASP/JSP or whatever, or just text files of JS source code.

The catch is always that the client-side code has to be sent the client,
and in a form that can be understood as javascript source code. As a
result the client will always have, at some point, the client-side code,
and in a form that can be understood.

For every code minimiser there is a code re-formatter or pretty printer
to turn the compacted code back into recognisably formatted/indented
code (with some of the browsers themselves being entirely adequate tools
for that job through the use of a little (publicly available and well
known) scripting). Then there is syntax highlighting to bring out the
distinctions between, for example, operators, keywords and Identifiers.

Which leaves the only potentially practical/productive aspect of
obfuscation the transformation of property names and Identifiers into
meaningless sequences of characters, which is not really a barrier to
understanding computer code. It may be true that meaningful
Identifiers/property names are an aid to (more quickly) understanding
source code but if their absence represented any real barrier the fact
that the vast bulk of example code (and all of the browser DOM property
names and language keywords) are in English must then make it near
impossible for non-English speakers to understand those examples (or the
DOM). This clearly is not the case. Obfuscation by Identifier scrambling
is of limited benefit because a word that is meaningful in a language
that the reader does not understand is no more or less meaningful to
them than any arbitrary sequence of characters that it may be replaced
with.

The pro-obfuscation position (and particularly those retailing
obfuscation software) will argue that obfuscation must make code harder
to understand. That is true, but the degree to which it is harder to
understand is so small (and so much not a real issue to the people who
could have understood the code directly if it were never obfuscated)
that the effort outweighs the benefits.

Plus, once obfuscated what are you going to do when a browser reports:-

Error: Line 1, character 5734, "I0O1I is null or not an object"

-?

Richard.
Dec 10 '06 #7

P: n/a
In comp.lang.javascript message
<el*******************@news.demon.co.uk>, Sun, 10 Dec 2006 03:41:20,
Richard Cornford <Ri*****@litotes.demon.co.ukwrote:
... ...
>Plus, once obfuscated what are you going to do when a browser reports:-

Error: Line 1, character 5734, "I0O1I is null or not an object"
A sane author will retain the unobfuscated code and can run that in the
same browser, expecting a corresponding result; then fixing the master
and publishing a re-obfuscated version.

You're rather naive in the interpretation of your knowledge.

There is perceived future benefit in being able to prevent others from
seeing or from understanding one's code. Generally, those others will
be, at least predominantly, those unable to code (in the perceiver's
opinion) as well as the perceiver - persons with less knowledge or
ability than those who want to hide their code.

Those who expect to be able to hide their code must believe it to be
probably possible to do so; so a substantial proportion of the less able
will believe it too, and so will not in fact read the code in question.

In other words, code hiding / obfuscation is partially effective. It
cannot hide code from, say, Jim Ley; but it can hide it from such as
Ja********@freemail.com. Also, if an expert believes that, because code
cannot be properly hidden, hidden code must be by an incompetent author,
he might well not bother to look - and the hider's aim is achieved.

Remember "The Purloined Letter"?

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Dec 10 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.