FAQ Topic - How do I protect my javascript code?

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - How do I protect my javascript code?
-----------------------------------------------------------------------

With clientside Javascript you can't as your code is distributed
in source form and is easily readable. With JScript, there is the
Script Encoder (see MSDN), but this is nothing more than obfuscation.
Disabling the right mouse button also does nothing to protect
your script in a Web browser.

Your code is likely protected under copyright laws. See:

http://www.wipo.int/about-ip/en/copyright.html

http://webdesign.about.com/msubcopyright.htm


===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.

 

[marss]

-----------------------------------------------------------------------
FAQ Topic - How do I protect my javascript code?
-----------------------------------------------------------------------

With clientside Javascript you can't as your code is distributed
in source form and is easily readable. With JScript, there is the
Script Encoder (see MSDN), but this is nothing more than obfuscation.

Obfuscation is not so bad. Good obfuscator really hampers the reverse
engineering for the professionals and makes it practically impossible
for the javascript's newbies.
The problem is that the code worthy of the protection is a rarity.

Unless you want to obfuscate the weak code in order to not disgrace
yourself

 

[Randy Webb]

marss said the following on 2/6/2007 3:45 AM:

Obfuscation is not so bad.

Obfuscation of JS code is a total waste of time.

Good obfuscator really hampers the reverse engineering for the professionals

Huh? You think naming your variables different makes it any harder on a
"professional" than leaving them alone does?

and makes it practically impossible for the javascript's newbies.

Copy the obfuscated code, use it as is, who cares about it. No newbie
does, thats for sure.

The problem is that the code worthy of the protection is a rarity.
Unless you want to obfuscate the weak code in order to not disgrace
yourself

That is 99% of obfuscating codes purpose, in my opinion.

 

[getburl]

-----------------------------------------------------------------------
FAQ Topic - How do I protect my javascript code?
-----------------------------------------------------------------------

With clientside Javascript you can't as your code is distributed
in source form and is easily readable. With JScript, there is the
Script Encoder (see MSDN), but this is nothing more than obfuscation.
Disabling the right mouse button also does nothing to protect
your script in a Web browser.

Your code is likely protected under copyright laws. See:

http://www.wipo.int/about-ip/en/copyright.html

http://webdesign.about.com/msubcopyright.htm

===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is athttp://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.

Securely protecting Javascript in the browser is not possible. What is
possible is hampering the efforts of those attempting to access your
code. In the case of competitive advantage, one company may want to at
least delay the understanding of another competing company.
Obfuscation in cobmination with Server Referrer Checks can hamper the
time to understanding for a competing company. Server Referrer Checks
track from where calls to the javascript are made. This Server
Referrer Check can then disallow calls to the script from a server
outside of the domain of ownership. This will make it more difficult
for a person to call the script for viewing directly in the browser.
Again, this is not protection but a method for making script theft
more cumbersome.

 

[dd]

Obfuscation of JS code is a total waste of time.
Randy

I have to disagree on that one. Obfuscation dramatically
increases the effort involved in reverse engineering. Not
only that, it can decrease the file size by 50%. I know
how difficult it can make the code just from trying to
debug my own obfuscated code in a live environment.
Yes someone can just steal it and use it, but they run
the risk of copyright issues. By figuring out how someone
is achieving something and simply replicating the concept
using your own code is far less likely to cause copyright
problems. Making it difficult to figure out can help a lot.
Here's an obfuscated function, tell me how quickly you
can see what this object is useful for:

a.a0=y;
a.a1=q;
a.a2=x;
a.a3=q*(w-l);
a.a4=x*(h-t);
a.a5=f;
a.a6=s[y];

and compare it to the unobfuscated version:

div_to_position.initial_x_position = left_base_pos;
div_to_position.initial_y_position = top_base_pos;
div_to_position.current_x_position = left_base_pos * (width -
left_offset);
div_to_position.current_y_position = top_base_pos * (height -
top_offset);
div_to_position.initial_visibility = base_visibility;
div_to_position.current_visibility = start_visibility
[this_div_identifier_name];

It's clear from the unobfuscated code that this is dealing with
some div and it's initial position and visibility, and it's current
position and invisibility using some offsets. Tell me you saw
the same thing from the obfuscated code ;-) Also, the size
of the obfuscated code above is about 75 bytes. The size of
the obfuscated one is nearer to 600 bytes.

 

[Evertjan.]

dd wrote on 07 feb 2007 in comp.lang.javascript:

a.a0=y;
a.a1=q;
a.a2=x;
a.a3=q*(w-l);
a.a4=x*(h-t);
a.a5=f;
a.a6=s[y];

and compare it to the unobfuscated version:

div_to_position.initial_x_position = left_base_pos;
div_to_position.initial_y_position = top_base_pos;
div_to_position.current_x_position = left_base_pos * (width -
left_offset);
div_to_position.current_y_position = top_base_pos * (height -
top_offset);
div_to_position.initial_visibility = base_visibility;
div_to_position.current_visibility = start_visibility
[this_div_identifier_name];

I think the second version is just as unreadable and a good example for
code that does not need to be obfuscated, because it's value is zero.

Not only that, it can decrease the file size by 50%.

Since when is that important in this broadband age and more so is that a
valid a reason for obfuscation?

===============

No, obfuscation is only usefull to get the simpleminded and the hasty off
your back.

And to satisfy the need of [wrongly presumed] importance of one's work.

Using clientside script programming is publishing.

Selling a book with your idea's and keeping them secret at the same time
is a contradictio in terminis.

 

[marss]

Obfuscation of JS code is a total waste of time.

Yea and nay. Even if I write my own code I prefer to set meaningful
names for the variables and functions. I add some comment in the
complicated code. It's all I do to understand the code a month(year)
later.
To say nothing of another's uncommented code with meaningless
variables(functions)...
It is possible to understand it but hard. At least for me. Here I have
to compare waste of time with desired effect of a new knowledge
acquisition.
That is why many commercial products are selling with obfuscated
javascript code. For example, some products of Telerik. If code is
valuable it wastes to be obfuscated.

Copy the obfuscated code, use it as is, who cares about it. No newbie
does, thats for sure.

And then post in comp.lang.javascript a question like this:
"I have got some code here and some code there, put it together and it
did not work. Why? Help me plz!!!"

 

[marss]

I mean:
If code is valuable it is worth to be obfuscated.

Sorry for the slip in speaking My English leaves much to be desired.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected].

With clientside Javascript you can't as your code is distributed
in source form and is easily readable. With JScript, there is the
Script Encoder (see MSDN), but this is nothing more than obfuscation.
Disabling the right mouse button also does nothing to protect
your script in a Web browser.

If thought about carefully, none of that is *really* true.

Consider London, 1940/41 in particular. Many objects were falling from
the sky. As protection, those on duty (at least) were generally issued
with "tin hats". Those provided good protection against freely-falling
shrapnel, spent bullets, bits of brick, etc., but were no help against a
well-aimed 250lb bomb or a direct hit by a falling Heinkel.

Correspondingly, simple tricks such as menu-disabling or putting into an
include file can make it significantly harder for the average low-life
to read or copy code; one must just acknowledge that against the likes
of Jim there can be no defence.

 

[dd]

I think the second version is just as unreadable and a good example for
code that does not need to be obfuscated, because it's value is zero.

Well I'm not going to try and convince you. If a reduction in size of
80%
and making it more difficult to steal, isn't justification I don't
know what is.

Since when is that important in this broadband age and more so is that a
valid a reason for obfuscation?

Because only 50% of people have broadband, and how can it be better to
have a .JS file that's 100KB instead of an obfuscated one at 20KB?
It's
this kind of thinking that has led to the memory hogging applications
we
see these days. People who follow your argument would say that PC's
these days have a Gig or two of memory so don't worry about it. That's
exactly why we have things like a messenger application taking up 30MB
of memory, and Outlook hogs over 50MB. Internet Explorer is not averse
to using 100MB when it feels like it.

My employers, who pay for the bandwidth my JS files use when delivered
in web pages, were very happy when I obfuscated my code and cut their
costs in half by doing so. They're similarly happy that our
intellectual
property (the time we invested in making code that does what it does)
can
not be "EASILY" copied and enable some competitor to achieve what we
do, with no effort at all.

 

[getburl]

dd wrote on 07 feb 2007 in comp.lang.javascript:

a.a0=y;
a.a1=q;
a.a2=x;
a.a3=q*(w-l);
a.a4=x*(h-t);
a.a5=f;
a.a6=s[y];

and compare it to the unobfuscated version:

div_to_position.initial_x_position = left_base_pos;
div_to_position.initial_y_position = top_base_pos;
div_to_position.current_x_position = left_base_pos * (width -
left_offset);
div_to_position.current_y_position = top_base_pos * (height -
top_offset);
div_to_position.initial_visibility = base_visibility;
div_to_position.current_visibility = start_visibility
[this_div_identifier_name];

I think the second version is just as unreadable and a good example for
code that does not need to be obfuscated, because it's value is zero.

Not only that, it can decrease the file size by 50%.

Since when is that important in this broadband age and more so is that a
valid a reason for obfuscation?

===============

No, obfuscation is only usefull to get the simpleminded and the hasty off
your back.

And to satisfy the need of [wrongly presumed] importance of one's work.

Using clientside script programming is publishing.

Selling a book with your idea's and keeping them secret at the same time
is a contradictio in terminis.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)- Hide quoted text -

- Show quoted text -

This thread has gotten way off track. The question is 'how can a
person best protect their code?' The question is not, 'What are the
motives for code protection and do you agree that protection is
worthwhile?'

That being said. I would really love to hear more about methods for
Javascript code protection regardless of the motives or investment vs
benefit. Dialogue about methods for code protection currently
available and in the future, like Project Tamarin http://www.mozilla.org/projects/tamarin/
, could yeild invention if not innovation.

 

[Evertjan.]

dd wrote on 07 feb 2007 in comp.lang.javascript:

Well I'm not going to try and convince you. If a reduction in size of
80%
and making it more difficult to steal, isn't justification I don't
know what is.


Because only 50% of people have broadband, and how can it be better to
have a .JS file that's 100KB instead of an obfuscated one at 20KB?

-- You do not need to obfuscate to compress.
-- A 100kB js file is a crasy programming, you should then think about
splitting the job over multiple pages, or even better use serverside
programming.
-- It is not that important [if true] that only 50% has broadband,
because the 50% that has not lives in the third world and probably has
not the financial power to be so interesting to your emplyer as the other
halve, or has hardware that cannot cope with 100kB of clientside
scrripting code.

It's this kind of thinking that has led to the memory hogging
applications we see these days.

I do not follow you, if you stil want to have 100kB of clientside
scripting.

People who follow your argument would say that PC's
these days have a Gig or two of memory so don't worry about it. That's
exactly why we have things like a messenger application taking up 30MB
of memory, and Outlook hogs over 50MB. Internet Explorer is not averse
to using 100MB when it feels like it.

This sounds a bit aggressive. "People who follow your argument" also do
this and that, is not an argument at all. Are you at loss for real
arguments?

My employers, who pay for the bandwidth my JS files use when delivered
in web pages, were very happy when I obfuscated my code and cut their
costs in half by doing so. They're similarly happy that our
intellectual property (the time we invested in making code that does
what it does) can not be "EASILY" copied and enable some competitor to
achieve what we do, with no effort at all.

If you are the expert, you should be above pleasing your employer with
false arguments, even if they are their and not your arguments. That is
dishonest and unprofessional.

Serious competitors will not be deterred by your obfuscation, if the
programming is so special. "EASINESS" has nothing to do with that.

If they at present do not copy your "intelectual property", it is because
they can easily build their own better application.

100kB clientside code cannot possibly be the best choice of a web
application. convince your employer that serversided ant page-moduled
coding is far more robust, safe, speedy, cross browser applicable, etc.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>

Since when is that important in this broadband age and more so is that a
valid a reason for obfuscation?

Broadband is not yet available to all users at all times. I know it's
not practical in the outback of Australia, even in inhabited parts.

 

[dd]

dd wrote on 07 feb 2007 in comp.lang.javascript:

If you are the expert, you should be above pleasing your employer with
false arguments, even if they are their and not your arguments. That is
dishonest and unprofessional.

How can it be dishonest and unprofessional to look at the cost of
serving
a 20KB JS file to 1 billion people every week against serving a 40KB
or
a 60KB file to that many people. When you're paying for bandwidth,
it's
cheaper. How can you possibly disagree with this? It's like switching
to
a car that needs half as much fuel (yet all other costs remain the
same).

100kB clientside code cannot possibly be the best choice of a web
application. convince your employer that serversided ant page-moduled
coding is far more robust, safe, speedy, cross browser applicable, etc.

That's the point though. We don't have 100KB of clientside code. We
have
20KB of clientside code because it's compressed/obfuscated.

If you want to tell people that having 20KB of obfuscated code is a
bad
idea then I'm sure the GWT and Scriptaculous teams will be interested
to hear it. They're doing exactly the same thing. I listened to their
talk
on GWT on how obfuscation and compression made what otherwise
would have been too heavy a library, useable.

Server-side code isn't always the answer. Not all code exists just to
prepare HTML that will be deployed. Runtime libraries like GWT and
Scriptaculous have to be clientside.

 

[Randy Webb]

Dr J R Stockton said the following on 2/7/2007 9:23 AM:

In comp.lang.javascript message <[email protected].


If thought about carefully, none of that is *really* true.

All of it is "*really* true". Every word of it. To believe otherwise is
naive at best.

 

[Evertjan.]

Dr J R Stockton wrote on 07 feb 2007 in comp.lang.javascript:

In comp.lang.javascript message <[email protected]>


Broadband is not yet available to all users at all times. I know it's
not practical in the outback of Australia, even in inhabited parts.

.... which outback is important but not "that" important in this broadband
age, as an argument for the poster who specified a world of 50% non
broadband users.

Compressing can nicely be done without any willfull obfuscation.
That is gives some obfuscation,
is no reason to strive for obfuscation per se.

Methinks obfuscation gives a totally false sense of programme copying
safety and should be discouraged being used for that purpose,
especially by experts that should know that to satisfy their customers.

It is like selling faulty locks for a home,
telling your customer how safe they are,
when those locks only deter people under 5 years of age,
and the goods in the house are only interesting to grown ups.

 

[Randy Webb]

dd said the following on 2/7/2007 4:04 AM:

I have to disagree on that one. Obfuscation dramatically
increases the effort involved in reverse engineering.

Maybe so, but obfuscation is still a wasted effort. There is nothing on
the web that can't be duplicated. And, I dare say, there isn't much on
the web that hasn't been duplicated already.

Not only that, it can decrease the file size by 50%.

Obfuscation doesn't reach that goal, code minimizing does. You can
minimize code size without obfuscating it (or attempting to). They are
not the same thing.