Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Hide source code

Reply
Thread Tools

Hide source code

 
 
Enzo
Guest
Posts: n/a
 
      04-25-2005
Hi Ng,

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

Thanks in advance!

Enzo


 
Reply With Quote
 
 
 
 
Enzo
Guest
Posts: n/a
 
      04-25-2005
Ok and thanks, Duncan and Micha!!!

Regards,

Enzo


 
Reply With Quote
 
 
 
 
Hywel Jenkins
Guest
Posts: n/a
 
      04-25-2005
In article <nl2be.136205$(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...
> Hi Ng,
>
> It's possible to protect the source code of
> a js file? With PHP?


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

--
Hywel
 
Reply With Quote
 
Ira Baxter
Guest
Posts: n/a
 
      04-30-2005

"Duncan Booth" <(E-Mail Removed)> wrote in message
news:Xns96436BD60BFA7duncanrcpcouk@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


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      04-30-2005
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.


 
Reply With Quote
 
Douglas Crockford
Guest
Posts: n/a
 
      04-30-2005
> 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
 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      04-30-2005
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


 
Reply With Quote
 
Douglas Crockford
Guest
Posts: n/a
 
      04-30-2005
>>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
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      04-30-2005
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.


 
Reply With Quote
 
Ira Baxter
Guest
Posts: n/a
 
      05-07-2005

"Richard Cornford" <(E-Mail Removed)> wrote in message
news:d50h1a$o0m$1$(E-Mail Removed)...
> 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.
>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to hide your source code? Immortal Nephi C++ 1 08-10-2009 07:41 AM
Hide contents in source code mrajanikrishna@gmail.com ASP .Net 1 06-20-2008 05:49 PM
Hide HTML Source Code ad@albert-dominguez.de HTML 41 06-01-2007 09:52 PM
can we show the value in source code but hide it in the screen? jrefactors@hotmail.com ASP General 5 09-07-2005 04:02 AM
hide my source code/ ross HTML 17 06-28-2003 08:35 PM



Advertisments