JavaScript in Password Protected Folder?

[xmp333]

Hi All,
I am trying to hide my JavaScript source. The method I chose was to
keep all the important source in a password protected folder, and then
use a SRC="folder/script.js" to include it in my code. This way, the
script will run, but the user will be unable to view the included
code. Or so I think :).

I have tried this method, and it seems to work. However, I would like
to know if you can see any problems with this. For instance, can you
think of a way to bypass this and get at script.js? Can you foresee
any problems that would arise as a result of keeping scripts behind
password protected folders? Any other security concerns?
Thanks in advance.

[xmp333]

Hi All,
Thanks for the rapid and definitive responses. It looks like I cannot
use JavaScript for any proprietary coding (only things that I don't
mind being open source).

This helps with making decisions about this project.
Thanks again!

[Brian Genisio]

xm****@yahoo.co m wrote:

Hi All,
Thanks for the rapid and definitive responses. It looks like I cannot
use JavaScript for any proprietary coding (only things that I don't
mind being open source).

This helps with making decisions about this project.
Thanks again!

Well, you are correct, and incorrect. You do not have to make your
JavaScript code open source... you simply have no method for hiding your
code... this is true. Open Source means something different than making
your code publically readable. You can put strinct copyrights in your
code, making it obvious that it is illegal to use your code in any
way... that is about all you can do.

There is one hotly contested method, called something like obfuscation,
where you run the code through a program that will mangle all of the
variables, and remove white-space, making it harder to read.

While this is a method for making it harder for someone to read your
code, it in no way hides it. If someone wants to put effort forward,
they can still read the code... it is just more difficult to do.

If you need to hide your code, you might consider Java, or server-side
scripting. In both cases, the user never has access to your source code.

Brian

[Randy Webb]

Richard Cornford wrote:

"Randy Webb" <hi************ @aol.com> wrote in message
news:Zp******** ************@co mcast.com...
<snip>
On the plus side both of our newsreaders have followed RFC 1036 to the
letter. (I assume you noticed the organisation originating this latest
nonsense; another great contribution to the Usenet community.)

Actually, I hadn't paid attention to it until you mentioned it. But
knowing that, they also stopped adding the generated signature lines to
there posted posts.

It won't slip by me again though :)

I have to figure out how to make Mozilla quote the way I want it to and
show more than "so and so wrote" :-(

Ahh, the joys of learning :)
--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[xmp333]

[My Misuse of the Term "Open Source"]

Well, you are correct, and incorrect. You do not have to make your
JavaScript code open source... you simply have no method for hiding your
code... this is true. Open Source means something different than making
your code publically readable. You can put strinct copyrights in your
code, making it obvious that it is illegal to use your code in any
way... that is about all you can do.
True, I should have been more careful with my language. Thanks for
the correction.
There is one hotly contested method, called something like obfuscation,
where you run the code through a program that will mangle all of the
variables, and remove white-space, making it harder to read.

While this is a method for making it harder for someone to read your
code, it in no way hides it. If someone wants to put effort forward,
they can still read the code... it is just more difficult to do.
I read about that, but it wasn't enough protection for my tastes, I
think I encountered a few pages like that as a matter of fact. I gave
up on them because I figured I could find other pages that were
properly formatted, but had I wanted to, I could have figured out the
contents. Normally, I wouldn't think of hiding source since I would
like people to be able to examine my work and (hopefully) learn from
it, as I have done with other pages. However, since this is
intellectual property for my employer the situation is much different.

If you need to hide your code, you might consider Java, or server-side
scripting. In both cases, the user never has access to your source code.
I have used server side scripting, and while it's the safest "platform
independent" technique, it is also lacking in interactivity and
responsiveness.

Java is the only other possibility that I can see, but I have no idea
of its future -- especially on the Windows platform. Furthermore,
since this application is targeted towards end users, I don't want
people to have to go through any hassle to run it -- and this includes
installing additional components.

Oh well, if it weren't a challenge, it wouldn't be fun :D
Brian

Thanks.

[Richard Cornford]

<xm****@yahoo.c om> wrote in message
news:4a******** *************** ***@posting.goo gle.com...
<snip>

I am trying to hide my JavaScript source.

Why?

Because the organization wishes to protect its source code,
since it is proprietary and may reveal internal details that
we prefer to keep secret.

Client-side code (including Java, which may be decompiled) should
not contain internal details that can be exploited. You don't keep
secrets by distributing them to people you can't trust to keep
them for you.

Richard.

[xmp333]

> >Because the organization wishes to protect its source code,

since it is proprietary and may reveal internal details that
we prefer to keep secret.
Client-side code (including Java, which may be decompiled) should
not contain internal details that can be exploited. You don't keep
secrets by distributing them to people you can't trust to keep
them for you.

Well, the secrets aren't critical, so a "moderate" level of protection
is enough for us. Sure, they can decompile, but that would require a
lot of effort (and knowledge) on their part. It isn't a casual effort
like browsing JavaScript source. Also, if you are going to go through
that level of effort, there has to be a motivation. Casual browsing
can be done without serious motivation. All this leads to a "good
enough" level of protection.

Also, the issue isn't trust. As a matter of course, anything intended
for commercial use is to be regarded as intellectual property and kept
secret. This includes source code, and since there's no way (that I
know of) to conveniently distribute a program without opening up the
possibility of decompilation, then compilation is the best way of
doing it.

Lastly, the intended audience is the general public, or at least
certain members thereof. This is basically a "shrink-wrapped"
application, and as such, we don't have things like NDAs, etc...

Richard.

Thanks.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

[top posting fixed]

xm****@yahoo. com wrote: <snip>

I am trying to hide my JavaScript source. ... <snip>
"StanD" <St**********@m ail.forum4desig ners.com> wrote in message
news:St******** **@mail.forum4d esigners.com...

By all means, please shorten your attribution(s).
JavaScript is a client side script, ...

<snip>

Pleas do not top-post to comp.lang.javas cript. The group FAQ outlines
acceptable posting style in section 2.3 paragraph 5 and references the
applicable standard.

Full ACK
Your posting software appears to exhibiting faulty behaviour in its
handling of the "References " header in your postings.
Nonsense.
It has sent (split across lines at the location of spaces to avoid
uncontrolled wrapping):-

References: <4a************ **************@ posting.google. com>
<c0************ *******@news.de mon.co.uk>
<40************ *********@news. xs4all.nl>
<Ao************ ********@comcas t.com>

This is perfectly OK according to the standards. RFC 1036 (which is
BTW not even on the Standards Track) is an extension to RFC 822, and
later RFC 2822 (which is on the Standards Track). It does not
redefine the format of header lines, neither does the part of the RFC
you have quoted. *Your* news client software is simply incapable and
it is *your* software which disobeys the standards also in this regard.

WFM. Mozilla Thunderbird 0.5+ (20040220).

You should get a working client or workaround this bug with
additional software. See <http://insideoe.tomste rdam.com/>
HTH

PointedEars

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote: <snip>

Your posting software appears to exhibiting faulty behaviour in its
handling of the "References " header in your postings.

Nonsense.

It has sent (split across lines at the location of spaces to avoid
uncontrolle d wrapping):-

References: <4a************ **************@ posting.google. com>
<c0********** *********@news. demon.co.uk>
<40********** ***********@new s.xs4all.nl>
<Ao********** **********@comc ast.com>

This is perfectly OK according to the standards. RFC 1036 (which is
BTW not even on the Standards Track) is an extension to RFC 822, and
later RFC 2822 (which is on the Standards Track). It does not
redefine the format of header lines, neither does the part of the RFC
you have quoted. *Your* news client software is simply incapable and
it is *your* software which disobeys the standards also in this
regard.

<snip>

If you don't believe that RFC 1036 (Standard for Interchange of USENET
Messages) is applicable to Usenet posts how about:-

| RFC 977 Network News Transfer Protocol February 1986
|
| 1.4. A Central News Server
| ...
| NNTP is modelled upon the news article specifications in RFC 850,
| which describes the USENET news system. However, NNTP makes few
| demands upon the structure, content, or storage of news articles,
| and thus we believe it easily can be adapted to other non-USENET
| news systems.
| ...
| 3.10.1. POST
| ...
| If posting is permitted, the article should be presented in the
| format specified by RFC850, and should include all required
| header lines. ...
| ...

- which is a standards track document and directly employs:-

| RFC 850 Standard for Interchange of USENET Messages June 1983
|
| 2.2.6 References This field lists the message ID's of
| any articles prompting the submission of this article. It
| is required for all follow-up articles, and forbidden when
| a new subject is raised. Implementations should provide a
| follow-up command, which allows a user to post a follow-up
| article. This command should generate a Subject line
| which is the same as the original article, except that if
| the original subject does not begin with "Re: " or "re: ",
| the four characters "Re: " are inserted before the
| subject. If there is no References line on the original
| header, the References line should contain the message ID
| of the original article (including the angle brackets).
| If the original article does have a References line, the
| followup article should have a References line containing
| the text of the original References line, a blank, and the
| message ID of the original article.
| ...

- which RFC 1036 updates an replaces (without any change to the
definition of the References header).

But even then:-

| RFC 2822 Internet Message Format April 2001
|
| 3.6.4. Identification fields
| ...
| The "References :" field will contain the contents of the parent's
| "References :" field (if any) followed by the contents of the parent's
| "Message-ID:" field (if any). If the parent message does not contain
| a "References :" field but does have an "In-Reply-To:" field
| containing a single message identifier, then the "References :" field
| will contain the contents of the parent's "In-Reply-To:" field
| followed by the contents of the parent's "Message-ID:" field (if
| any). If the parent has none of the "References :", "In-Reply-To:",
| or "Message-ID:" fields, then the new message will have no
| "References :" field.
| ...

The only pertinent differences between RFC 2822 and 850/1036 (and
thus, by implication 977) is in providing more detail of what
should happen if the message responded to does not have References,
Message-ID and/or In-Reply-To fields. The References header in the
message I was responding to still couldn't be validly constructed
in response to any of the preceding messages in this thread. That
is, it is impossible to take the References header (or the lack of
it in the original post) and append the Message-ID field to come
up with the References field in that response.
You should get a working client or workaround this bug with
additional software. See <http://insideoe.tomste rdam.com/>

What bug? My software didn't build the References header in the
message I was responding to, and it did a fairly reasonable job of
interpreting information that was incorrect to start with.

Richard.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote:

Your posting software appears to exhibiting faulty behaviour in its
handling of the "References " header in your postings.
Nonsense.

It has sent (split across lines at the location of spaces to avoid
uncontroll ed wrapping):-

References : <4a************ **************@ posting.google. com>
<c0********* **********@news .demon.co.uk>
<40********* ************@ne ws.xs4all.nl>
<Ao********* ***********@com cast.com>

This is perfectly OK according to the standards. RFC 1036 (which is
BTW not even on the Standards Track) is an extension to RFC 822, and
later RFC 2822 (which is on the Standards Track). It does not
redefine the format of header lines, neither does the part of the RFC
you have quoted. *Your* news client software is simply incapable and
it is *your* software which disobeys the standards also in this
regard.

<snip>

If you don't believe that RFC 1036 (Standard for Interchange of USENET
Messages) is applicable to Usenet posts

I have never stated that. But you have, again, nothing quoted that
states that wrapped References are not OK according to any standard.
[...]

You should get a working client or workaround this bug with
additional software. See <http://insideoe.tomste rdam.com/>
What bug? My software didn't build the References header in the
message I was responding to, and it did a fairly reasonable job of
interpreting information

No, it did not, it failed.
that was incorrect to start with.

It was not incorrect.
PointedEars

[Richard Cornford]

Thomas 'PointedEars' Lahn <Po*********@we b.de> wrote in message news:<40******* *******@Pointed Ears.de>...
<snip>

If you don't believe that RFC 1036 (Standard for Interchange
of USENET Messages) is applicable to Usenet posts
I have never stated that.

You stated that the header I quoted was "perfectly OK according
to the standards" when it is structurally incorrect according
to RFC 1036, which implied that you didn't believe that
RFC 1036 was a standard that should be applied to a Usenet post.
But you have, again, nothing quoted that states that
wrapped References are not OK according to any standard.

Why would I want to quote anything that stated that wrapped
References headers are not OK? That would have no baring on
the number and sequence of message IDs in the References
header that I was criticising.

You didn't by any chance not bother to read what I had
written (twice) and instead jump to an irrelevant conclusion
based on some preconception that you have? If you are going
to do that and then post statements like "Nonsense" based on
your irrelevant preconception the least you could do is go
on to state why you think something is nonsense so that it
would be clear that that you are thinking about something
unrelated and irrelevant.

<snip>

What bug? My software didn't build the References header
in the message I was responding to, and it did a fairly
reasonable job of interpreting information

No, it did not, it failed.

No it didn't, it associated the message with the message
baring the Message-ID that appeared last in the sequence of
message IDs in the References header. One of three equally
reasonable responses based on the data provided, but probably
the most common response by newsreaders as that would
normally be the ID of the message being responded to.

that was incorrect to start with.

It was not incorrect.

It is not possible to employ the procedure for building a
References header described in RFCs 850, 1036 and/or 2822
and come up with the References header that I was
commenting on. In context no References header could be built
with more than two message IDs and in a reply to the OP that
header should only contain one message ID, while the header
in question has 4. That is objectively incorrect and if you
had bothered to read what I said you would not have wasted
your time making irrelevant comments, my time responding to
those and everyone else's time reading a reiteration of an
argument that was correct to start with.

Richard.