E
Enzo
Hi Ng,
It's possible to protect the source code of
a js file? With PHP?
Thanks in advance!
Enzo
It's possible to protect the source code of
a js file? With PHP?
Thanks in advance!
Enzo
E
Enzo
Ok and thanks, Duncan and Micha!!!
Regards,
Enzo
Regards,
Enzo
H
Hywel Jenkins
In PHP:
unlink("filename.js");
I
Ira Baxter
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).
R
Richard Cornford
Ira said:
So your keep saying.
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.
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.
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.
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.
The premise that identifier names need to be meaningful for code to be
understood is utterly wrong.
Richard.
D
Douglas Crockford
We make such obfuscators. Yes, they remove comments/whitespace,
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
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
M
Matt Kruse
Douglas said:
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.
D
Douglas Crockford
There is a standing challenge in this group to people making claims
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
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
R
Richard Cornford
Matt Kruse wrote:
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.
Precisely. The vast majority of people don't understand any computer
code, obfuscated or not.
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.
For the vast majority obfuscation is an unnecessary step. They will not
understand the code anyway.
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.
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.
Precisely. The vast majority of people don't understand any computer
code, obfuscated or not.
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.
For the vast majority obfuscation is an unnecessary step. They will not
understand the code anyway.
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.
I
Ira Baxter
Richard Cornford said:
So we do.
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.
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.
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.
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.
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.
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.
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.
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
I
Ira Baxter
Douglas Crockford said:
I don't recall seeing such trials. You may have had them.
We haven't participated in such.
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.
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.
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...)
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
D
Douglas Crockford
There is a standing challenge in this group to people making claims
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
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
T
Thomas 'PointedEars' Lahn
Hywel said:
LOL
PointedEars, amused
R
Richard Cornford
Ira said:
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.
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?
A few seconds exposing the code to suitable re-formatting software.
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".
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.
Matt's comments hardly represented a defence of obfuscates (though that
may have been his intention, it's difficult to tell).
No, not in any sense.
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.
And we all get to weight the opinions of others and consider there real
worth.
"We all have our opinions": reasoned discussion, or the last defence of
a position that has been demonstrated as untenable?
You are exaggerating my interpretation of "just before", but that is
basically what you wrote.
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.
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?
But we may be trying to refute one.
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
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 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?
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.