Hide source code

Discussion in 'Javascript' started by Enzo, Apr 25, 2005.

  1. Enzo

    Enzo Guest

    Hi Ng,

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

    Thanks in advance!

    Enzo
    Enzo, Apr 25, 2005
    #1
    1. Advertising

  2. Enzo

    Enzo Guest

    Ok and thanks, Duncan and Micha!!!

    Regards,

    Enzo
    Enzo, Apr 25, 2005
    #2
    1. Advertising

  3. In article <nl2be.136205$>,
    says...
    > Hi Ng,
    >
    > It's possible to protect the source code of
    > a js file? With PHP?


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

    --
    Hywel
    Hywel Jenkins, Apr 25, 2005
    #3
  4. Enzo

    Ira Baxter Guest

    "Duncan Booth" <> 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
    Ira Baxter, Apr 30, 2005
    #4
  5. 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.
    Richard Cornford, Apr 30, 2005
    #5
  6. > 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
    Douglas Crockford, Apr 30, 2005
    #6
  7. Enzo

    Matt Kruse Guest

    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
    Matt Kruse, Apr 30, 2005
    #7
  8. >>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
    Douglas Crockford, Apr 30, 2005
    #8
  9. 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.
    Richard Cornford, Apr 30, 2005
    #9
  10. Enzo

    Ira Baxter Guest

    "Richard Cornford" <> wrote in message
    news:d50h1a$o0m$1$...
    > 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.
    >
    >
    Ira Baxter, May 7, 2005
    #10
  11. Enzo

    Ira Baxter Guest

    "Douglas Crockford" <> wrote in message
    news:c6552$4273d623$436562f7$...
    > > [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
    Ira Baxter, May 7, 2005
    #11
  12. >>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
    Douglas Crockford, May 8, 2005
    #12
  13. Hywel Jenkins wrote:

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

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


    LOL


    PointedEars, amused
    Thomas 'PointedEars' Lahn, May 8, 2005
    #13
  14. 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.
    Richard Cornford, May 8, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ross

    hide my source code/

    ross, Jun 27, 2003, in forum: HTML
    Replies:
    17
    Views:
    4,098
    Daniel Doman
    Jun 28, 2003
  2. Replies:
    41
    Views:
    2,292
    Samuel van Laere
    Jun 1, 2007
  3. Replies:
    1
    Views:
    362
    Steve C. Orr [MCSD, MVP, CSM, ASP Insider]
    Jun 20, 2008
  4. Immortal Nephi

    How to hide your source code?

    Immortal Nephi, Aug 10, 2009, in forum: C++
    Replies:
    1
    Views:
    475
    Marcel Müller
    Aug 10, 2009
  5. Replies:
    5
    Views:
    159
    Ferd Berfle
    Sep 7, 2005
Loading...

Share This Page