423,818 Members | 2,250 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,818 IT Pros & Developers. It's quick & easy.

Hide source code

P: n/a
Hi Ng,

It's possible to protect the source code of
a js file? With PHP?

Thanks in advance!

Enzo
Jul 23 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Enzo wrote:
It's possible to protect the source code of
a js file? With PHP?

No, there is nothing which you can do to stop even moderately intelligent
users from seeing your js source code. Microsoft have an option to
'encrypt' js files but (a) this means your js will only ever run on IE, and
(b) 2 minutes with Google will find you a utility to unencrypt the js.

You can try using a javascript obfuscator to remove comments and whitespace
and replace meaningful variable names with shorter meaningless ones, but
the main benefit of this is that it reduces download times, and it does
make it more painful if you ever have to debug anything.
Jul 23 '05 #2

P: n/a

Enzo wrote:
Hi Ng,

It's possible to protect the source code of
a js file? With PHP?

Thanks in advance!

Enzo


not really.
the js file needs to be executed on the users computer, so the code has
to get there somehow. the browser must be able to read the code, and if
the browser can, so can the user.
php has got nothing to do with that at all, cause it runs on the
server, which is somewhere else at all.

micha

Jul 23 '05 #3

P: n/a
Ok and thanks, Duncan and Micha!!!

Regards,

Enzo
Jul 23 '05 #4

P: n/a
In article <nl*********************@telenews.teleline.es>,
va**@mierda.pais says...
Hi Ng,

It's possible to protect the source code of
a js file? With PHP?


In PHP:
unlink("filename.js");

--
Hywel
Jul 23 '05 #5

P: n/a

"Duncan Booth" <du**********@invalid.invalid> wrote in message
news:Xn***************************@127.0.0.1...
Enzo wrote:
It's possible to protect the source code of a js file?
No, there is nothing which you can do to stop even moderately intelligent
users from seeing your js source code. Microsoft have an option to
'encrypt' js files but (a) this means your js will only ever run on IE, and (b) 2 minutes with Google will find you a utility to unencrypt the js.

You can try using a javascript obfuscator to remove comments and whitespace and replace meaningful variable names with shorter meaningless ones, but
the main benefit of this is that it reduces download times, and it does
make it more painful if you ever have to debug anything.


We make such obfuscators. Yes, they remove comments/whitespace,
and make the names meaningless. Yes, this does benefit
download time, but it really does, in our opinion, make code
of any serious size very difficult to understand, which is where
you get your protection.

They have NO impact on development debugging.
You keep your source in cleartext, so you code and
debug it exactly as you have. You obfuscate the code
just before you go live with it in production, keeping
your cleartext for further development.

If you get an error report from the field, generated obfuscation maps
let you easily convert scrambled names back to the real ones.
(You customers of course don't get these generated maps,
only you do).

--
Ira D. Baxter, CTO 512-250-1018
Semantic Designs, Inc.
www.semdesigns.com/Products/Obfuscators
Jul 23 '05 #6

P: n/a
Ira Baxter wrote:
Duncan Booth wrote:
Enzo wrote:
> It's possible to protect the source code of a js file?
No, there is nothing which you can do to stop even
moderately intelligent users from seeing your js source
code. Microsoft have an option to 'encrypt' js files but
(a) this means your js will only ever run on IE, and (b)
2 minutes with Google will find you a utility to unencrypt
the js.

You can try using a javascript obfuscator to remove
comments and whitespace and replace meaningful variable
names with shorter meaningless ones, but the main benefit
of this is that it reduces download times, and it does
make it more painful if you ever have to debug anything.


We make such obfuscators.


So your keep saying.
Yes, they remove comments/whitespace,
and make the names meaningless.
But the removal of white space is not a contribution to obfuscation
because it is always possible to get a code formatter to put it back.
Yes, this does benefit download time,
It has been demonstrated many times that the compression facilities of
HTTP 1.1 will have an approximately equivalent effect in reducing
download time, and carry that effect on to HTML source.

But if the point of processing source code in a way that modified
identifier names is going to be to reduce the size of the resulting code
it would be better to use an obfuscator that transformed the names to
the shortest valid identifiers available in the pertinent scope.
but it really does, in our opinion, make code
of any serious size very difficult to understand,
which is where you get your protection.
Your opinion seems to be colored by a vested interest. You are yet to
get a single regular contributor to this group to agree with it.
They have NO impact on development debugging.
You keep your source in cleartext, so you code and
debug it exactly as you have. You obfuscate the code
just before you go live with it in production,
You absolutely do not obfuscate code just before you go live with it. If
you are going to obfuscate code you need to do so _before_ QA, and then
QA again each time your re-obfuscate the original source.

Of course it is possible that semdesigns.com don't do QA so you don't
realise the need for this.
keeping your cleartext for further development.

If you get an error report from the field, generated
obfuscation maps let you easily convert scrambled names
back to the real ones. (You customers of course don't get
these generated maps, only you do).


The premise that identifier names need to be meaningful for code to be
understood is utterly wrong.

Richard.
Jul 23 '05 #7

P: n/a
> We make such obfuscators. Yes, they remove comments/whitespace,
and make the names meaningless. Yes, this does benefit
download time, but it really does, in our opinion, make code
of any serious size very difficult to understand, which is where
you get your protection.

They have NO impact on development debugging.
You keep your source in cleartext, so you code and
debug it exactly as you have. You obfuscate the code
just before you go live with it in production, keeping
your cleartext for further development.

If you get an error report from the field, generated obfuscation maps
let you easily convert scrambled names back to the real ones.
(You customers of course don't get these generated maps,
only you do).


There is a standing challenge in this group to people making claims
about obfuscation and code hiding to prove their claims by giving us a
test case.

In previous trials, code was recovered and posted in the clear within
minutes.

Obfuscation is a waste of time. It does not work. It will not protect
secrets. It will increase development costs.

JSMin, which is free and open, can remove comments and whitespace. That,
followed by compression, can significantly reduce download times. It is
also as effective as obfuscation in keeping competent programmers from
seeing the source. That is why JSMin makes no such claims.

http://www.crockford.com/javascript/jsmin.html
Jul 23 '05 #8

P: n/a
Douglas Crockford wrote:
There is a standing challenge in this group to people making claims
about obfuscation and code hiding to prove their claims by giving us a
test case.
In previous trials, code was recovered and posted in the clear within
minutes.
Obfuscation is a waste of time. It does not work. It will not protect
secrets. It will increase development costs.


The goals of the obfuscation need to be made clear.

No amount of obfuscation will stop knowledgeable javascript coders from
gaining full readable access to your code. But, I don't think that's the
goal in most cases.

If the goal is to stop most web users - and probably most average javascript
coders - from duplicating your code and/or methods, then obfuscation
probably works just fine. Most people probably lack the knowledge or skill
to get anything useful from the obfuscated code. It should be made clear
that you will never protect your code from 100% of users. But if protecting
it from 80% (or whatever percent, I know you'll complain about random stats,
Richard) is acceptable and you think it is beneficial, then obfuscation
might achieve your goal.

Now, whether it's worth anyone's time to protected against a subset of all
internet users - that depends on the situation.

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #9

P: n/a
>>There is a standing challenge in this group to people making claims
about obfuscation and code hiding to prove their claims by giving us
a test case. In previous trials, code was recovered and posted in the
clear within minutes. Obfuscation is a waste of time. It does not work. It will not protect
secrets. It will increase development costs.
The goals of the obfuscation need to be made clear.

No amount of obfuscation will stop knowledgeable javascript coders from
gaining full readable access to your code. But, I don't think that's the
goal in most cases.

If the goal is to stop most web users - and probably most average javascript
coders - from duplicating your code and/or methods, then obfuscation
probably works just fine. Most people probably lack the knowledge or skill
to get anything useful from the obfuscated code. It should be made clear
that you will never protect your code from 100% of users. But if protecting
it from 80% (or whatever percent, I know you'll complain about random stats,
Richard) is acceptable and you think it is beneficial, then obfuscation
might achieve your goal.

Now, whether it's worth anyone's time to protected against a subset of all
internet users - that depends on the situation.


What commercial benefit is obtained from preventing unknowledgeable
coders from seeing your code? Accepting for a moment your statistic
that 80% of web developers are incompetent, it is the remaining 20%
that represent a competitive threat.

http://www.crockford.com/javascript
Jul 23 '05 #10

P: n/a
Matt Kruse wrote:
<snip>
No amount of obfuscation will stop knowledgeable javascript
coders from gaining full readable access to your code. But,
I don't think that's the goal in most cases.

If the goal is to stop most web users - and probably most
average javascript coders - from duplicating your code and/or
methods, then obfuscation probably works just fine.
Any action to protect code form 'most web users' is a total waste of
time and effort (and money if you pay for software to do it), they don't
understand computer code anyway.

It is not until people start to learn javascript that there is any point
in trying to conceal code from them. And for any individual script a
reader's ability to comprehend it will depend on the extent to which
their skills match those required to employ the techniques used in the
script. A newbee will be utterly baffled by an OO javascript, and
intermediate authors are often incapable of comprehending closure-based
code.

Ultimately the problem of obfuscation is that any script that is worth
protection only really needs protection from the one group against whom
there is no protection; the people who would actually understand the
source code in its plain form.
Most people probably lack the knowledge or skill
to get anything useful from the obfuscated code.
Precisely. The vast majority of people don't understand any computer
code, obfuscated or not.
It should be made clear that you will never protect
your code from 100% of users. But if protecting it from
80% (or whatever percent, I know you'll complain about
random stats, Richard)
Most don't need reminding that if its random it is not a statistic, just
a number.

You could try stating that these numbers you post are just your personal
baseless guesses, and everyone could assign then the weight they deserve
without the need for additional comment.
is acceptable and you think it is beneficial,
then obfuscation might achieve your goal.
For the vast majority obfuscation is an unnecessary step. They will not
understand the code anyway.
Now, whether it's worth anyone's time to protected against
a subset of all internet users - that depends on the situation.


For any given script there is a majority who wouldn't understand any of
it (in any form), a group that will understand some of it, but not
comprehend the totality, and a group that would fully comprehend the
script. No effort is needed to 'protect' a script against the first two
groups, and nobody is realistically claiming that obfuscation will be
effective against the third.

In short; obfuscation with the intention of providing 'protection' is
wasted effort.

Richard.
Jul 23 '05 #11

P: n/a

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:d5*******************@news.demon.co.uk...
Ira Baxter wrote:
Duncan Booth wrote:
Enzo wrote:
> It's possible to protect the source code of a js file?
You can try using a javascript obfuscator to remove
comments and whitespace and replace meaningful variable
names with shorter meaningless ones, but the main benefit
of this is that it reduces download times, and it does
make it more painful if you ever have to debug anything.


We make such obfuscators.


So you keep saying.


So we do.
Yes, they remove comments/whitespace,
and make the names meaningless.


But the removal of white space is not a contribution to obfuscation
because it is always possible to get a code formatter to put it back.


Sure. I repeat, once again that obfuscation (and any kind of
"protection") offers NO GUARANTEES. Obfuscation simply
provides a level of defense that requires effort on the part of
a thief. Once the economics from the theif's point of view
are poor, you've won.

Reformatting isn't particularly hard, granted.
Nontheless, the results still look scary (even if they aren't
in a technical sense), and that chases off some of the potential
thieves. No, don't repeat your argument about chasing off only
dumb theives, we've all heard it. Chasing off dumb theives is
still valuable, and this isn't the only defense.
Yes, this does benefit download time, It has been demonstrated many times that the compression facilities of
HTTP 1.1 will have an approximately equivalent effect in reducing
download time, and carry that effect on to HTML source.
Agreed. This isn't the point of obfuscation, merely an extra benefit.
Neither end has to actually set up the compression capabilities to get it
when you use obfuscation.
But if the point of processing source code in a way that modified
identifier names is going to be to reduce the size of the resulting code
it would be better to use an obfuscator that transformed the names to
the shortest valid identifiers available in the pertinent scope.
Sure. We could squeeze out an extra few percent if we went this
far, but nobody has told us that it matters. (I responded to a previous
post of yours that said we didn't produce the shortest possible
identifiers; true, but in practice we come pretty close).
Building products is about economics, too, and what
the obfuscator does seems to be reasonable without going
this far.
but it really does, in our opinion, make code
of any serious size very difficult to understand,
which is where you get your protection.


Your opinion seems to be colored by a vested interest.


I'll cheerfully agree SD has a vested interest. It got that way
because people asked us to build such obfuscators.
You are welcome to vote by not buying one.
You are yet to
get a single regular contributor to this group to agree with it.
I doubt if my customers want to spend a lot of time in
this kind of discussion. There have been several other
defenders of the utility of obfuscation involved in these
threads (Matt Kruse in this one). I don't know if
he is a "regular contributor", and I don't see why
"regular contributor" should carry specific weight.
We all have our opinions. Reasoned dicussions
seem fine.
They have NO impact on development debugging.
You keep your source in cleartext, so you code and
debug it exactly as you have. You obfuscate the code
just before you go live with it in production,

You absolutely do not obfuscate code just before you go live with it. If
you are going to obfuscate code you need to do so _before_ QA, and then
QA again each time your re-obfuscate the original source.
Yes, the way I stated could be interpreted as
"obuscate-then-ship-in-2-nanoseconds".
I meant it in "do your development, then finish up your usual way
(including test if you have any sense), and then ship."
If you didn't have your own point of view to push, I think
you reasonably might have interpreted this a bit more
loosely. We're not trying to prove theorems here.
Of course it is possible that semdesigns.com don't do QA so you don't
realise the need for this.
Yes, it is *possible*. It is *possible* you are an axe murderer.
Then again, perhaps we actually do QA, and you are not.
Ad hominem attacks don't contribute to this discussion.
The premise that identifier names need to be meaningful for code to be
understood is utterly wrong.
For small codes, sure. For larger codes... almost everybody on the planet
agrees that maintaining somebody else's code is difficult; see any software
engineering textbook. The usual recommendation is that an engineer(!)
design carefully, code carefully, choose meaningful names, and document
it all. The usual practice seems much worse, and almost all maintenance
is based on reading the existing code and praying the last guy at least
used sensible names. If he hasn't done that, then working out what the
code
does tends to be much harder.

Ira

Richard.

Jul 23 '05 #12

P: n/a
"Douglas Crockford" <no****@covad.net> wrote in message
news:c6***************************@msgid.meganewss ervers.com...
[Baxter wrote]
We make such obfuscators. Yes, they remove comments/whitespace,
and make the names meaningless. Yes, this does benefit
download time, but it really does, in our opinion, make code
of any serious size very difficult to understand, which is where
you get your protection.

They have NO impact on development debugging.
You keep your source in cleartext, so you code and
debug it exactly as you have. You obfuscate the code
just before you go live with it in production, keeping
your cleartext for further development.

If you get an error report from the field, generated obfuscation maps
let you easily convert scrambled names back to the real ones.
(You customers of course don't get these generated maps,
only you do).
There is a standing challenge in this group to people making claims
about obfuscation and code hiding to prove their claims by giving us a
test case.

In previous trials, code was recovered and posted in the clear within
minutes.


I don't recall seeing such trials. You may have had them.

We haven't participated in such.
Obfuscation is a waste of time. It does not work. It will not protect
secrets.
In an absolute sense, sure. In an absolute sense, nothing works
perfectly. Practical solutions have their limits, and are usable
within those limits. Whether you think the limits are reasonable
is a matter of judgement. Some others judge differently than you.
It will increase development costs.
Yes, yes, its true! One can actually spend *an entire afternoon*
setting up obfuscation for typical JavaScript stuff.
(Many cases related to obfuscating JS for IE take only a few
minutes). But the increment is miniscule.
JSMin, which is free and open, can remove comments and whitespace. That,
followed by compression, can significantly reduce download times.
A previous post said this was wasted effort, since HTTP 1.1 handles it
better;
I assume you leave *all* the identifiers in place, intact..
However, I agree with you that doing this has some value since you can't
always know that both parties support HTTP 1.1. compression.
(Hard to believe how old some browser out there running are...)
It is also as effective as obfuscation in keeping competent programmers from seeing the source. That is why JSMin makes no such claims.


I disagree about its ability to make the source difficult to decode.
Garbled identifiers in larger codes make them harder to figure out.

However, you are welcome to not use any obfuscation tools.

Ira

Jul 23 '05 #13

P: n/a
>>There is a standing challenge in this group to people making claims
about obfuscation and code hiding to prove their claims by giving us a
test case.

In previous trials, code was recovered and posted in the clear within
minutes.
I don't recall seeing such trials. You may have had them.

We haven't participated in such.


You are not the only person to have made bogus claims about the value
of obfuscation. If you are unwilling to put your claims to a public
test, that is, as they say, your business.

http://www.crockford.com/javascript/jsmin.html
Jul 23 '05 #14

P: n/a
Hywel Jenkins wrote:
va**@mierda.pais says...
It's possible to protect the source code of
a js file? With PHP?


In PHP:
unlink("filename.js");


LOL
PointedEars, amused
Jul 23 '05 #15

P: n/a
Ira Baxter wrote:
Richard Cornford wrote: <snip> Sure. I repeat, once again that obfuscation (and any kind of
"protection") offers NO GUARANTEES. Obfuscation simply
provides a level of defense that requires effort on the part of
a thief.
If I go to google groups and view this thread google's clever
advertising software notices the subject and puts up an advert that
reads:-

<quote cite=" www.semanticdesigns.com advertisement on
groups.google.com, 2005-05-06">
Protect JavaScript code
Prevent reverse engineering scripts
Works with HTML, XML, ASP, JSP, PHP
www.semanticdesigns.com
</quote>

While it may be argued that "protection" is a relative term, "prevent"
certainly is not. You either can prevent reverse engineering or you can
not, and you can not. If even you are admitting that your company's own
advertising if making a false statement you can hardly be surprised if
we find your vested interest and repeated baseless assertions highly
suspect.
Once the economics from the theif's point of view
are poor, you've won.
Economics? How do the economics pan out when you spend money on software
that claims to "prevent reverse engineering" but does no such thing?
Haven't you lost before the game has even started?
Reformatting isn't particularly hard, granted.
A few seconds exposing the code to suitable re-formatting software.
Nontheless, the results still look scary (even if they
aren't in a technical sense), and that chases off some
of the potential thieves. No, don't repeat your argument
about chasing off only dumb theives, we've all heard it.
Chasing off dumb theives is still valuable, and this isn't
the only defense.
Why not repeat it, you appear to have missed the point. Which is that
these "dumb thieves" are not thieves at all. They may want to be
thieves, they may have an intention to steal, but if they are not
capable of comprehending the source code they intend to steal, even in
its original form, they cannot do anything with it. So they are just
people who download scripts from the internet, and are no more harmful
than anyone else who visits a web page and downloads its accompanying
scripts as part of the process.

Being in possession of copyrighted script source code is not theft (else
every Internet user would be a thief), to be a thief the culprit must do
something with that script (without the permission of the copyright
holder). And with a non-trivial script they must understand it in order
to do something with it. (And to reverse engineer it they certainly are
going to need to fully comprehend it).

So I repeat: effort and expense would be squandered in pursuit of
protection against "dumb thieves".

<snip>
You are yet to get a single regular
contributor to this group to agree with it.


I doubt if my customers want to spend a lot of
time in this kind of discussion.


And I doubt you want your customers to be aware that the issue is
debated at all. Which makes me wonder why you persist in trying to
promoting you dubious product on comp.lang.javascirpt at all.
There have been several other defenders of
the utility of obfuscation involved in these
threads (Matt Kruse in this one).
Matt's comments hardly represented a defence of obfuscates (though that
may have been his intention, it's difficult to tell).
I don't know if he is a "regular contributor",
No, not in any sense.
and I don't see why "regular
contributor" should carry specific weight.
Surprising as you may find the notion, regular contributors to technical
Usenet newsgroups represent considerable expertise in the group's
subject. They have little choice because Usenet is traditionally a harsh
and critical environment, so if you hang around contributing to these
groups for any length of time you either have the expertise to start
with, or pick it up pretty quickly, because errors mistakes and
misconceptions will be pointed out, very publicly. And any contributor
to this group reads 30,000+ posts per year, exposing themselves to a
range of knowledge, options, problems, situations and questions that
they could not experience in a single work situation.

So the opinions of regular contributors matter because if you cannot
persuade any of the experts in a subject that a particular cause of
action is a good idea (by reasoned argument, demonstration or even
rhetoric) then it probably isn't a good idea. And being able to persuade
any number of people who don't know any better that it is a good idea
doesn't change that.
We all have our opinions.
And we all get to weight the opinions of others and consider there real
worth.
Reasoned dicussions seem fine.
"We all have our opinions": reasoned discussion, or the last defence of
a position that has been demonstrated as untenable?

<snip>
... . You obfuscate the code
just before you go live with it in production,
You absolutely do not obfuscate code just before you go
live with it. ...

<snip>
Yes, the way I stated could be interpreted as
"obuscate-then-ship-in-2-nanoseconds".
You are exaggerating my interpretation of "just before", but that is
basically what you wrote.
I meant it in "do your development, then finish up your
usual way (including test if you have any sense), and
then ship."
So this time the code never gets obfuscated? Why don't you just write
down how the obfuscation stage should be integrated into development?
Perhaps because doing so would make it obvious that Douglas Crockford's
"It will increase development costs" hit the nail on the head.
If you didn't have your own point of view to push,
I think you reasonably might have interpreted this
a bit more loosely.
I read a proposal that lies somewhere between a bad idea and
catastrophically harmful and you want me to let it propagate around the
world uncommented?
We're not trying to prove theorems here.
But we may be trying to refute one.
Of course it is possible that semdesigns.com don't do QA
so you don't realise the need for this.


Yes, it is *possible*. It is *possible* you are an axe
murderer. Then again, perhaps we actually do QA, and you
are not. Ad hominem attacks don't contribute to this
discussion.


If you propose a cause of actions that is self evidently stupid I don't
see why I shouldn't speculate on the reasons that prevent you from
seeing that it was a stupid suggestion, or seeing the stupidity propose
it anyway.

(Oh, and sensible behaviour for axe murderers is never to admit it, or
comment upon it, in public ;)
The premise that identifier names need to be meaningful for
code to be understood is utterly wrong.


For small codes, sure. For larger codes... almost everybody
on the planet agrees that maintaining somebody else's code
is difficult; see any software engineering textbook.
The usual recommendation is that an engineer(!) design carefully,
code carefully, choose meaningful names, and document it all.


Yes, meaningful identifier names, in the readers native language (or a
language in which they are fluent) make life easier. And good
documentation also helps a great deal, but our prospective thief was
never going to get access to the documentation anyway.
The usual practice seems much worse, and almost all
maintenance is based on reading the existing code and
praying the last guy at least used sensible names.
The usual practice is worse, the code is badly and inconstantly
formatted, the original author was French, or German, or Indian, and
identifier names that are in English don't quite correspond with their
conceptual role in the program, or are personal abbreviations, or
whatever. And yet we cope. We cope because while meaningful identifier
names are obviously helpful they are ultimately arbitrary; distinct
slots into which values are placed. In the perception of an experienced
programmer an identifier name that conveys no additional meaning is in
no way a barrier to understanding the behaviour of the code that uses
it. If it were how would anyone cope with assembly language programming?
If he hasn't done that, then
working out what the code
does tends to be much harder.


You cannot persuade any javascript experts that there is any value in
obfuscation by saying "much harder" and "looks scary" because that is
not their perception of the situation. You can mangle the identifier
names any way you like but whatever you do they must remain distinct.
That distinctness is all the experienced programmer needs, and so the
results will only be _slightly_ harder to undersigned than they would
have been before. And it won't "look scary" at all, because those
meaningless identifier names are surrounded by self-evident operators,
expressions, statements, function calls, DOM property accessors, etc,
etc (and all syntax highlighted to exaggerate their role in the code).
It is an open book once you know how to read it.

You may perceive that transformation as rendering code much harder to
comprehend and looking impressively scary, and there may be many
thousands (even hundreds of thousands) of others with a similar
perception, but they were never a threat to start with. The threat comes
(and always will come) from individuals who are not at all put off by a
task that has been rendered just slightly harder.

There is a reason that ex-hackers (in the 'breaking into computer
systems' sense) easily find legitimate employment as network security
experts; sensible people seek the opinions of those who understand the
reality.

Richard.
Jul 23 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.