The best way to protect javascript code?

Discussion in 'Javascript' started by howa, Dec 9, 2006.

  1. howa

    howa Guest

    if speed, size is not a matter, i just want to protect the code as much
    as possible, any library or tools do you think is the best solution
    right now?

    i know there is not a perfect solution, but as good as it can be is

    p.s. need to be cross brower

    howa, Dec 9, 2006
    1. Advertisements

  2. There are zillions of obfusicators

    google javascript obfuscation

    Here is one but I don't know if it works well.

    There is always a risk of introducing bugs when obfusicating code and
    the code won't be uncrackable.

    Peter Michaux, Dec 9, 2006
    1. Advertisements

  3. howa

    Evertjan. Guest

    howa wrote on 09 dec 2006 in comp.lang.javascript:
    If your code is worth protecting, you will know alreadiy,
    that protected JS can only be serverside JS.

    If your clientside JS is worth being stolen,
    no scheme will help you.

    If your clientside JS is not worth being stolen,
    why bother?
    Evertjan., Dec 9, 2006
  4. howa

    mouseit101 Guest

    You can make it a lot harder by using PHP or some sort of server side
    language (PHP just happens to be my language of choice), and then
    including the javascript and linking to it externally. In the PHP make
    sure that the refferer is your site and if it isn't, dont print out the
    mouseit101, Dec 9, 2006
  5. The source has to be sent to the client. This technique does not make
    it a lot harder to see the source. I am pretty darn sure it is still
    visible with something like

    Peter Michaux, Dec 9, 2006
  6. howa

    Evertjan. Guest

    Are you replying one something?

    [please always quote on usenet]
    Evertjan., Dec 9, 2006
  7. There is no need get that complicated; view the files in the browser's
    cache while the site is loaded and the external javascript files will be
    there, regardless of whether they were dynamically greeted with
    PHP/ASP/JSP or whatever, or just text files of JS source code.

    The catch is always that the client-side code has to be sent the client,
    and in a form that can be understood as javascript source code. As a
    result the client will always have, at some point, the client-side code,
    and in a form that can be understood.

    For every code minimiser there is a code re-formatter or pretty printer
    to turn the compacted code back into recognisably formatted/indented
    code (with some of the browsers themselves being entirely adequate tools
    for that job through the use of a little (publicly available and well
    known) scripting). Then there is syntax highlighting to bring out the
    distinctions between, for example, operators, keywords and Identifiers.

    Which leaves the only potentially practical/productive aspect of
    obfuscation the transformation of property names and Identifiers into
    meaningless sequences of characters, which is not really a barrier to
    understanding computer code. It may be true that meaningful
    Identifiers/property names are an aid to (more quickly) understanding
    source code but if their absence represented any real barrier the fact
    that the vast bulk of example code (and all of the browser DOM property
    names and language keywords) are in English must then make it near
    impossible for non-English speakers to understand those examples (or the
    DOM). This clearly is not the case. Obfuscation by Identifier scrambling
    is of limited benefit because a word that is meaningful in a language
    that the reader does not understand is no more or less meaningful to
    them than any arbitrary sequence of characters that it may be replaced

    The pro-obfuscation position (and particularly those retailing
    obfuscation software) will argue that obfuscation must make code harder
    to understand. That is true, but the degree to which it is harder to
    understand is so small (and so much not a real issue to the people who
    could have understood the code directly if it were never obfuscated)
    that the effort outweighs the benefits.

    Plus, once obfuscated what are you going to do when a browser reports:-

    Error: Line 1, character 5734, "I0O1I is null or not an object"


    Richard Cornford, Dec 10, 2006
  8. In comp.lang.javascript message
    A sane author will retain the unobfuscated code and can run that in the
    same browser, expecting a corresponding result; then fixing the master
    and publishing a re-obfuscated version.

    You're rather naive in the interpretation of your knowledge.

    There is perceived future benefit in being able to prevent others from
    seeing or from understanding one's code. Generally, those others will
    be, at least predominantly, those unable to code (in the perceiver's
    opinion) as well as the perceiver - persons with less knowledge or
    ability than those who want to hide their code.

    Those who expect to be able to hide their code must believe it to be
    probably possible to do so; so a substantial proportion of the less able
    will believe it too, and so will not in fact read the code in question.

    In other words, code hiding / obfuscation is partially effective. It
    cannot hide code from, say, Jim Ley; but it can hide it from such as
    . Also, if an expert believes that, because code
    cannot be properly hidden, hidden code must be by an incompetent author,
    he might well not bother to look - and the hider's aim is achieved.

    Remember "The Purloined Letter"?
    Dr J R Stockton, Dec 10, 2006
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.