By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,131 Members | 1,560 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,131 IT Pros & Developers. It's quick & easy.

invisible javascript

P: n/a
Hello,
Can I make my java script code be invisible to other people who enter into
my site by IE browser ? - How ?

Thanks :)
Jul 20 '05 #1
Share this Question
Share on Google+
41 Replies


P: n/a
"Mr. x" wrote on 13/11/2003:
Hello,
Can I make my java script code be invisible to other people who enter into my site by IE browser ? - How ?


No-one can see your code, only its affects, just by entering your
web-site, so it's already invisible. You obviously mean something
else. Could you explain further?

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)
Jul 20 '05 #2

P: n/a
> Can I make my java script code be invisible to other people who enter into
my site by IE browser ? - How ?


No, you can't. Anyone who tells you different is either misinformed or lying.
Jul 20 '05 #3

P: n/a
Douglas Crockford wrote on 14 nov 2003 in comp.lang.javascript:
Can I make my java script code be invisible to other people who enter
into my site by IE browser ? - How ?


No, you can't. Anyone who tells you different is either misinformed or
lying.


Yes, you can.

Use Serverside ASP javascript.

Sorry, that is not what you ment, I suppose. ;-}

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 20 '05 #4

P: n/a
I see that if I do :
<html>
....
<script language = "javascript>
... here is my code
</script>
</html>

If I open the html source - I see the java-script code.
I want also to use the java-script on the client side,
but I don't know how.
Please, help.

Thanks :)

"Evertjan." <ex**************@interxnl.net> wrote in message
news:Xn********************@194.109.133.29...
Douglas Crockford wrote on 14 nov 2003 in comp.lang.javascript:
Can I make my java script code be invisible to other people who enter
into my site by IE browser ? - How ?


No, you can't. Anyone who tells you different is either misinformed or
lying.


Yes, you can.

Use Serverside ASP javascript.

Sorry, that is not what you ment, I suppose. ;-}

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Jul 20 '05 #5

P: n/a
"Mr. x" <a@b.com> schrieb im Newsbeitrag news:3f********@news.012.net.il...
Hello,
Can I make my java script code be invisible to other people who enter into
my site by IE browser ? - How ?

Thanks :)


You ask the community to help you for free in this forum - and your scripts
are what you can give back to the community ;-)

I had a look at your site and played some of your games. If you coded that
all by yourself it's impressing. But some of these games are also available
for free download in script archives. So even if you re-invented them on
your own, if somebody wants to get them he/she will anyway.

As you have to deliver the code to the user agent for playing, there's no
way to hide it. You can disable the right click button but you can't disable
the view source command, and even if you could you would not be able to
prevent somebody from opening the file in a text editor.

Just go on writing nice stuff and have fun with it.

--
Markus
Jul 20 '05 #6

P: n/a
In article <3f********@news.012.net.il>, a@b.com enlightened us with...
Hello,
Can I make my java script code be invisible to other people who enter into
my site by IE browser ? - How ?

Thanks :)


You can use an obfuscator, but anyone who actually knows script enough
to know what that is will go find a deobfuscator.
It discourages idiots from copying, though.

Other than that, if the browser can see it, so can I.

--
~kaeli~
A lot of money is tainted - It taint yours and it taint mine.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 20 '05 #7

P: n/a
Scripts are indeed not mine (only on the games ...),
I did some minor changes to translate them to Hebrew.
The other forums are all made by myself.

If I cannot hide my own java scripts, so I cannot - I'll live with that...

Thanks anyway :)
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote in message
news:3f**********************@news.easynet.ch...
"Mr. x" <a@b.com> schrieb im Newsbeitrag news:3f********@news.012.net.il...
Hello,
Can I make my java script code be invisible to other people who enter into my site by IE browser ? - How ?

Thanks :)


You ask the community to help you for free in this forum - and your

scripts are what you can give back to the community ;-)

I had a look at your site and played some of your games. If you coded that
all by yourself it's impressing. But some of these games are also available for free download in script archives. So even if you re-invented them on
your own, if somebody wants to get them he/she will anyway.

As you have to deliver the code to the user agent for playing, there's no
way to hide it. You can disable the right click button but you can't disable the view source command, and even if you could you would not be able to
prevent somebody from opening the file in a text editor.

Just go on writing nice stuff and have fun with it.

--
Markus

Jul 20 '05 #8

P: n/a

"kaeli" <ti******@NOSPAM.comcast.net> wrote in message
news:MP************************@nntp.lucent.com...
In article <3f********@news.012.net.il>, a@b.com enlightened us with...
Can I make my java script code be invisible to other people who enter into my site by IE browser ? - How ?


You can use an obfuscator, but anyone who actually knows script enough
to know what that is will go find a deobfuscator.

Other than that, if the browser can see it, so can I.


You mean, you could "encode" it with an encoder,
for which you can find a decoder.

If the script is actually obfuscated (e.g., names scrambled,
comments removed), yes, if the browser
can see it, so can you. But you can't find an automatic
program to deobfuscate it. It *is* possible to
"reverse engineer" such code by hand, but if
it is fair size, only idiots will try. It will still
run, and it will still be copyable, just darn
hard to understand or change.

See http://www.semdesigns.com/Products/O...bfuscator.html

--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 20 '05 #9

P: n/a
In article <3f********@giga.realtime.net>, "Ira Baxter"
<id******@semdesigns.com> writes:

<snip>
Other than that, if the browser can see it, so can I.
You mean, you could "encode" it with an encoder,
for which you can find a decoder.


No, he meant "obfuscate" it.
If the script is actually obfuscated (e.g., names scrambled,
comments removed), yes, if the browser
can see it, so can you. But you can't find an automatic
program to deobfuscate it. It *is* possible to
"reverse engineer" such code by hand, but if
it is fair size, only idiots will try. It will still
run, and it will still be copyable, just darn
hard to understand or change.
Doesn't matter if its "obfuscated" or "encoded". The fact remains that for the
browser to execute it, it *must* send the code. And getting the original is
trivial from there. To sell an obfuscator and advertise it as "foolproof"
should be illegal in civilized countries as false advertising.
See http://www.semdesigns.com/Products/O...bfuscator.html


Why? Its a waste of time to try to stop it.
--
Randy
Jul 20 '05 #10

P: n/a
> >If the script is actually obfuscated (e.g., names scrambled,
comments removed), yes, if the browser
can see it, so can you. But you can't find an automatic
program to deobfuscate it. It *is* possible to
"reverse engineer" such code by hand, but if
it is fair size, only idiots will try. It will still
run, and it will still be copyable, just darn
hard to understand or change.
Doesn't matter if its "obfuscated" or "encoded". The fact remains that for the
browser to execute it, it *must* send the code. And getting the original is
trivial from there. To sell an obfuscator and advertise it as "foolproof"
should be illegal in civilized countries as false advertising.


Randy is exactly right on this. Obfuscation does not protect secrets.

Jul 20 '05 #11

P: n/a
"HikksNotAtHome" <hi************@aol.com> wrote in message
news:20***************************@mb-m17.aol.com...
<snip>
... . To sell an obfuscator and advertise it as "foolproof"
should be illegal in civilized countries as false advertising.

<snip>

It often seems to me that advertisers get away with making statements
that might reasonably be interpreted as untrue by using forms of words
that could be subject to alternative and contradictory interpretation.
In this case, for example, it could be argued that "foolproof" would be
intended to mean "proof against fools", a much lower standard that is
almost trivial to comply with.

I am reminded of ELF's UK petrol (gasoline) retailing outlets displaying
a large banner with the legend "hyper-low prices", which, as hyper is a
Greek prefix meaning "above", literally means "above low prices" or "not
cheap". Clearly that was not the interpretation that the readers of the
banner were expected to make, but ELF was complying with the UK
advertising laws by making no untrue claims (just demonstrating a
contempt for their customers).

I have to agree that obfuscating client-side scripts is a waste of time.
The only part of the process that cannot be reversed by freely available
software is the modification of the global and local variable
identifiers and, while meaningful identifier names make scripts easier
to understand, cryptic identifier names hardly hinder understanding.
Interpreting the behaviour of a client-side script is almost entirely
down to looking at the script's DOM interaction and the DOM property
names cannot be obfuscated or the script won't work.

Richard.
Jul 20 '05 #12

P: n/a
I am confused... all anyone has to do is view source in a web browser
and wah-lah there's the JS code.

-Charlene

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
news:P9*********************@news-text.cableinet.net...
"Mr. x" wrote on 13/11/2003:
Hello,
Can I make my java script code be invisible to other people who

enter into
my site by IE browser ? - How ?


No-one can see your code, only its affects, just by entering your
web-site, so it's already invisible. You obviously mean something
else. Could you explain further?

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

Jul 20 '05 #13

P: n/a
Charlene Russ wrote on 17 nov 2003 in comp.lang.javascript:
"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
news:P9*********************@news-text.cableinet.net...
"Mr. x" wrote on 13/11/2003:
> Hello,
> Can I make my java script code be invisible to other people who

enter into
> my site by IE browser ? - How ?


No-one can see your code, only its affects, just by entering your
web-site, so it's already invisible. You obviously mean something
else. Could you explain further?

I am confused... all anyone has to do is view source in a web browser
and wah-lah there's the JS code.


Don't be, all you have to do is put 35 returns on the top of your html page
and 50% of the view-sorcerers will think that they have an empty page.

Additional measures increase this percentage, but you cannot fool the very
experienced readers of this NG anytime.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 20 '05 #14

P: n/a
> Don't be, all you have to do is put 35 returns on the top of your html page
and 50% of the view-sorcerers will think that they have an empty page.

Additional measures increase this percentage, but you cannot fool the very
experienced readers of this NG anytime.


That's just silly.
Jul 20 '05 #15

P: n/a
Douglas Crockford wrote on 17 nov 2003 in comp.lang.javascript:
Don't be, all you have to do is put 35 returns on the top of your
html page and 50% of the view-sorcerers will think that they have an
empty page.

Additional measures increase this percentage, but you cannot fool the
very experienced readers of this NG anytime.


That's just silly.


So you can be fooled? Sorry, I did not expect that.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 20 '05 #16

P: n/a
Evertjan. wrote:
Douglas Crockford wrote on 17 nov 2003 in comp.lang.javascript:
Don't be, all you have to do is put 35 returns on the top of your
html page and 50% of the view-sorcerers will think that they have an
empty page.

Additional measures increase this percentage, but you cannot fool the
very experienced readers of this NG anytime.


That's just silly.


So you can be fooled? Sorry, I did not expect that.


What Douglas probably meant is that it is silly to assume that the average
user is unable to note the scrollbars he is used to especially in the
`view-source:' window. All you do by those CR/LF is to increase document
size, thus increase loading time, and display yourselves to nothing else
than a scriptkiddie to the average user or programmer.
PointedEars
Jul 20 '05 #17

P: n/a
Thomas 'PointedEars' Lahn wrote on 18 nov 2003 in comp.lang.javascript:
All you do by those CR/LF is to increase document
size, thus increase loading time


Yes, sure,
by 70 bytes,
so by 10 milliseconds at 7kB/s,
or 100 microseconds at 700kB/s.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 20 '05 #18

P: n/a
"HikksNotAtHome" <hi************@aol.com> wrote in message
news:20***************************@mb-m17.aol.com...
In article <3f********@giga.realtime.net>, "Ira Baxter"
<id******@semdesigns.com> writes:
Other than that, if the browser can see it, so can I.
You mean, you could "encode" it with an encoder,
for which you can find a decoder.


No, he meant "obfuscate" it.
If the script is actually obfuscated (e.g., names scrambled,
comments removed), yes, if the browser
can see it, so can you. But you can't find an automatic
program to deobfuscate it. It *is* possible to
"reverse engineer" such code by hand, but if
it is fair size, only idiots will try. It will still
run, and it will still be copyable, just darn
hard to understand or change.


Doesn't matter if its "obfuscated" or "encoded". The fact remains that for

the browser to execute it, it *must* send the code. And getting the original is trivial from there.
That's an arguable point.
To sell an obfuscator and advertise it as "foolproof"
should be illegal in civilized countries as false advertising.


I don't say where I said anything about foolproof.
I think I was pretty clear about the limits.

Misquoting people seems like a shameful way to have a discusssion.

-- IDB


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 20 '05 #19

P: n/a
> > To sell an obfuscator and advertise it as "foolproof"
should be illegal in civilized countries as false advertising.


I don't say where I said anything about foolproof.
I think I was pretty clear about the limits.

Misquoting people seems like a shameful way to have a discusssion.


I'm not sure who is doing the misquoting here. Let me state some Principles of
Security.

Security is not obtained by obfuscation. Security is not obtained by obscurity.
Security is obtained from solid design, and the diligent management of as few
secrets as possible.

False security (obfuscation, for example) is worse than no security. False
security increases misplaced confidence and reduces vigilance and diligence.
False security leads to bad decision making and increased vulnerability.

The specific question here is "Can a script in a page be completely hidden?" A
"yes" answer must provide a demonstration in the form of a URL to a page with a
hidden script. A "yes" answer without such a demonstration is ultimately
dishonest.

Similarly, weakening the criteria to "Can a script in a page be hidden from the
incompetent?" is misleading and shameful.

http://www.crockford.com

Jul 20 '05 #20

P: n/a
Evertjan. wrote:
Thomas 'PointedEars' Lahn wrote on 18 nov 2003 in comp.lang.javascript:
All you do by those CR/LF is to increase document
size, thus increase loading time
Yes, sure,
by 70 bytes,


Depends on how many CR/LF you include.
so by 10 milliseconds at 7kB/s,
or 100 microseconds at 700kB/s.


You should read my postings to the end
and learn how to quote (mark omissions).
PointedEars
Jul 20 '05 #21

P: n/a
Thomas 'PointedEars' Lahn wrote on 20 nov 2003 in comp.lang.javascript:
Evertjan. wrote:
Thomas 'PointedEars' Lahn wrote on 18 nov 2003 in comp.lang.javascript:
All you do by those CR/LF is to increase document
size, thus increase loading time


Yes, sure,
by 70 bytes,


Depends on how many CR/LF you include.
so by 10 milliseconds at 7kB/s,
or 100 microseconds at 700kB/s.


You should read my postings to the end
and learn how to quote (mark omissions).


Did I step on your ears, Thomas ?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 20 '05 #22

P: n/a
"Douglas Crockford" <no****@laserlink.net> wrote in message
news:1f***************************@msgid.meganewss ervers.com...
To sell an obfuscator and advertise it as "foolproof"
should be illegal in civilized countries as false advertising.
I don't s<ee> where I said anything about foolproof.
I think I was pretty clear about the limits.

Misquoting people seems like a shameful way to have a discusssion.


I'm not sure who is doing the misquoting here.


Where's the quote in question?
Let me state some Principles of Security.

Security is not obtained by obfuscation. Security is not obtained by obscurity.

No? Why are you encouraged to choose passwords that aren't
the same as your name? Maybe the answer isn't black and white.
Security is obtained from solid design, and the diligent management of as few secrets as possible.

False security (obfuscation, for example) is worse than no security. False
security increases misplaced confidence and reduces vigilance and diligence. False security leads to bad decision making and increased vulnerability.
*No* security leads to increased vulnerability, too.
The specific question here is "Can a script in a page be completely hidden?" A "yes" answer must provide a demonstration in the form of a URL to a page with a hidden script. A "yes" answer without such a demonstration is ultimately
dishonest.
I agreed that source text of some kind must be provided to the browser.
I'd read that as a "NO" answer to the "Can script be hidden?" as a literal
question.

But if you wish to be helpful, after you have told somebody that they
cannot do what they literally wish to do, one might offer them viable
alternatives.
Similarly, weakening the criteria to "Can a script in a page be hidden from the incompetent?" is misleading and shameful.
If I asked, "Can I store my valuables safely in my house?"
the literal answer is NO. But while that is the FIRST answer,
it isn't a very helpful one. You can respond, "There are standard methods
for locking houses that discourage most thieves". As far as I can
tell, virtually everybody in Western civilization have "weak locks"
on their front door. Anybody with any determination (e.g,
a willingness to give a door one really good hard kick) can
overcome these locks. If we followed your line of reasoning,
nobody would buy locks, yet they are pretty popular. Wonder why?

Rejecting such solutions because they aren't absolutely perfect
leaves you with no solutions at all.

You use a doctor, right?
I know my doctor's solutions aren't perfect.
But I'm a lot happier to use his partial solutions
than to have no doctors at all.

Most engineering solutions are compromises. Some accept the compromises.
Some don't. You are welcome to your opinions about whether
the compromise works for you. And I think it fine that you should explain
to others why it does not work for you, so they can make a reasoned choice.

But I don't you should treat this as black and white,
"either you are secure or you are not".
http://www.crockford.com

--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 20 '05 #23

P: n/a
Anonymous <Nobody> writes:
"Douglas Crockford" <no****@laserlink.net> wrote in message
news:1f***************************@msgid.meganewss ervers.com...
Let me state some Principles of Security.

Security is not obtained by obfuscation. Security is not obtained by

obscurity.

No? Why are you encouraged to choose passwords that aren't
the same as your name? Maybe the answer isn't black and white.


There is a big difference between obfuscation/obscurity and secrecy.

Your password is a secret. It is known only to you. That is not
obscurity.

The password verification algorithm is public knowledge, or should be
assumed to be - if not now, them probably later. If the security of
the algorithm depends on people not knowing it, it is not secure.
Trying to keep the *algorithm* "secure" by keeping it secret, is
"security through obscurity", a concept that makes people working with
security very cautious.

If you reveal your password, your password is compromised. Youthen cut
your losses and make a new password.

If you reveal an algorithm kept sacure by obscurity, *everybody*'s
passwords are compromised, and they can't just pick new passwords
either.
Security is obtained from solid design, and the diligent management of as

few
secrets as possible.


Your newclient have broken this line incorrectly. It looks like "few" is
written by you and not a quote. Please fix this, it's highly annyoing.

.... But if you wish to be helpful, after you have told somebody that they
cannot do what they literally wish to do, one might offer them viable
alternatives.
The viable alternative to obfuscating your web page is ... not to do
it.

I have a bookmarklet:
---
javascript:(document.documentElement||document.bod y).innerHTML.replace(/&/g,"&amp;").replace(/</g,"&lt;").replace(/\n/g,"<br>")
---
It reveals the actual running HTML code of a page, no matter how many
levels of encryption it was hidden in originally.

[locks on doors] Rejecting such solutions because they aren't absolutely perfect
leaves you with no solutions at all.
It is a reasonable comparison. The difference is that with locks, the
threat model is known. You can talk about "most normal thieves" and
not be totally wrong.

I have yet to see someone who knows *who* they are trying to protect
their web page source code from, and more importantly *why*? What
is the threat? If burglars steal your valuables, you know what you
have lost (it's theft, so you lose something). If they rip off your
HTML code, it's at most copyright infringement, and the worst they
can do is ... to use it themselves.

For that you want to make your page Javascript dependent and prone to
failure?
You use a doctor, right?
I know my doctor's solutions aren't perfect.
But I'm a lot happier to use his partial solutions
than to have no doctors at all.
That's a bad analogy. Security is hard to compare to other areas.

Still, if you do compare them, in this case, Douglas Crockford is the
doctor. He is an expert in the field of browsers and Javascript. He is
telling you what he believes is the best solution to your problem
(don't bother). You disagree because there are quacks out there that
claim that their snake oil will help you.

Until ou tell us *exactly* what you want to prevent (who should not be
allowed to do what), we can't give you anything but general solutions.
Most engineering solutions are compromises. Some accept the compromises.
Some don't. You are welcome to your opinions about whether
the compromise works for you. And I think it fine that you should explain
to others why it does not work for you, so they can make a reasoned choice.


Most engineering solutions are solutions to a specific problem.
Please state the problem exactly :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #24

P: n/a
> > Similarly, weakening the criteria to "Can a script in a page be hidden
from the incompetent?" is misleading and shameful.
Rejecting such solutions because they aren't absolutely perfect
leaves you with no solutions at all.

Half measures are not always better than nothing. Futile gestures on The Net are
not effective.
You use a doctor, right?
I know my doctor's solutions aren't perfect.
But I'm a lot happier to use his partial solutions
than to have no doctors at all.


Being attended to by blood-letting butchers can be worse than having no doctors
at all. In the case of computer security, only perfect security works. If an
attach is possible, and if the attack has some sort of payoff, you should expect
that an attack will happen.

Protecting the privacy of scripts on public pages is impossible. I repeat,
anyone who is differently is either misinformed or lying. Obfuscation will not
prevent a competent programming from reading and using your scripts. Obfuscators
are bogus. Obfuscation does not work.

There are benefits to removing comments and whitespace. For example, JSMIN
(http://www.crockford.com/javascript/jsmin.html) does exactly that, and is
completely free and open source. It can reduce download time. It does not claim
to protect scripts from copying. Such a claim would be dishonest.

For example, if a company is considering a web-based business, but the business
only works if scripts are kept secret, then my advice to them is to rethink the
business because the plan is based on a false assumption.

Jul 20 '05 #25

P: n/a
> The password verification algorithm is public knowledge, or should be
assumed to be - if not now, them probably later. If the security of
the algorithm depends on people not knowing it, it is not secure.
Trying to keep the *algorithm* "secure" by keeping it secret, is
"security through obscurity", a concept that makes people working with
security very cautious.
Obfuscated source has *one* secret:
the map between the original names and the obfuscated names.

The *algorithm* for generating that map can be made
public without comprimising that secret.
Security is obtained from solid design, and the diligent management of
as few
secrets as possible.
Your newclient have broken this line incorrectly. It looks like "few" is
written by you and not a quote. Please fix this, it's highly annyoing.


Complain to Microsoft. Maybe that will help.
But if you wish to be helpful, after you have told somebody that they
cannot do what they literally wish to do, one might offer them viable
alternatives.


The viable alternative to obfuscating your web page is ... not to do
it.


That's *an* alternative. Other people may have other opinions.
But it takes us back the original argument: you can leave
your front door unlocked. It is a choice, sure.
I have a bookmarklet:
---
javascript:(document.documentElement||document.bod y).innerHTML.replace(/&/g,
"&amp;").replace(/</g,"&lt;").replace(/\n/g,"<br>") ---
It reveals the actual running HTML code of a page, no matter how many
levels of encryption it was hidden in originally.
I don't know how we got onto this "encryption" topic.
I thought we we talking about obfuscation, in which the code
executed by the browser is visible (as we all agree,
it must be).
[locks on doors]
Rejecting such solutions because they aren't absolutely perfect
leaves you with no solutions at all.
It is a reasonable comparison. The difference is that with locks, the
threat model is known. You can talk about "most normal thieves" and
not be totally wrong.

I have yet to see someone who knows *who* they are trying to protect
their web page source code from, and more importantly *why*? What
is the threat? If burglars steal your valuables, you know what you
have lost (it's theft, so you lose something). If they rip off your
HTML code, it's at most copyright infringement, and the worst they
can do is ... to use it themselves.

For that you want to make your page Javascript dependent and prone to
failure?


Eh? If you have client side, by absence of any other viable choices,
you page is already JavaScript dependent. It may consequently
be subject to failure (although I don't know why you think
JavaScript is any more subject to failure than the HTML
or the browser or whatever), but you are stuck with
the dependency.
You use a doctor, right?
I know my doctor's solutions aren't perfect.
But I'm a lot happier to use his partial solutions
than to have no doctors at all.


That's a bad analogy. Security is hard to compare to other areas.


Claiming that "Security is different" isn't an argument.
Still, if you do compare them, in this case, Douglas Crockford is the
doctor. He is an expert in the field of browsers and Javascript. He is
telling you what he believes is the best solution to your problem
(don't bother). You disagree because there are quacks out there that
claim that their snake oil will help you.
I'm surprised you didn't accuse me being the quack, since my
company offers one of the "snake oil" solutions.

I repeat,
Obfuscation won't prevent theft of code. I've never claimed otherwise.
(There are other obfuscator tool vendors that *do* claim
otherwise, and I agree with that is an unreasonable claim).

Security is always about making it harder for the "other guy"
to compromise what you wish to secure. It is never
absolute. So one must decide how much security one
can afford, and how to implement that.
Until ou tell us *exactly* what you want to prevent (who should not be
allowed to do what), we can't give you anything but general solutions.
People interested in obfuscators seem to have a pretty clear goal.
They are shipping code they wrote at some cost to the public.
They'd prefer not to have that code used by a competitor easily.
Copyright is one method that helps. Compiling is another
(can't do it for JavaScript). Obfuscation is a third.
Most engineering solutions are compromises. Some accept the compromises. Some don't. You are welcome to your opinions about whether
the compromise works for you. And I think it fine that you should explain to others why it does not work for you, so they can make a reasoned

choice.
Most engineering solutions are solutions to a specific problem.
Please state the problem exactly :)


As above.

-- IDB


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 20 '05 #26

P: n/a

"Douglas Crockford" <no****@covad.net> wrote in message
news:e3**************************@msgid.meganewsse rvers.com...
Similarly, weakening the criteria to "Can a script in a page be hidden
from the incompetent?" is misleading and shameful.
Rejecting such solutions because they aren't absolutely perfect
leaves you with no solutions at all.
Half measures are not always better than nothing. Futile gestures on The

Net are not effective.
This isn't going anywhere. I use a spam detector to filter junk.
It is futile. But still useful.
You use a doctor, right?
I know my doctor's solutions aren't perfect.
But I'm a lot happier to use his partial solutions
than to have no doctors at all.


Being attended to by blood-letting butchers can be worse than having no

doctors at all.
Using an amateur doctor when you have need and nothing else is available
is smarter than not using a doctor at all.

One can choose to use pejorative adjectives, but they don't make an
argument.
In the case of computer security, only perfect security works. If an
attach is possible, and if the attack has some sort of payoff, you should expect that an attack will happen.
There isn't any such thing as perfect security. Every scheme has holes.
So your proposal is to use no scheme at all?
Protecting the privacy privacy of scripts on public pages is impossible.
Privacy? I thought we were talking about making source code
harder to understand.
I repeat, anyone who is differently is either misinformed or lying.
I don't think I'm misinformed.
I don't think I'm lying.
(Thank for attributing these properties to me, though).
Such attacks are inflammatory but not helpful.
Obfuscation will not
prevent a competent programming from reading and using your scripts.
Nobody ever said that you could stop a determined person.

However, when the cost of "undoing" obfuscation seems to exceed
the cost of simply doing it from scratch, reasonable people
won't bother doing the reverse engineering.
Even *competent* people won't bother in this case.
Obfuscators are bogus. Obfuscation does not work.


OK, we're back to opinions. You are welcome to yours.

I'm not going to repeat my position, I think it is clear.
I think yours is clear too and isn't going to change.

--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 20 '05 #27

P: n/a
Ira Baxter wrote:

Please include an attribute line (like the above one) so one can see who
is quoted at each quoting level.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Your newclient have broken this line incorrectly. It looks like "few" is
written by you and not a quote. Please fix this, it's highly annyoing.
Complain to Microsoft.


Nobody is forced to use borken software, but one should not use such
or at least try to workaround the most important of its bugs in
appreciation of their readers and of the advice they provide.
Maybe that will help.


Unlikely. Many have complained over the years, but M$ had long refused
to do anything about the bugs in this particular software. Instead,
they are still telling plain lies on their service website about why a
bug must occur that does not occur in other mail/news software.

A service pack had been released recently to fix some issues at last,
yet some important issues that make the Usenet less readable, including
borken quotes due to missing quote characters on line-break, remain.
Ask our friend Google for details.

There is software out there to fix this, though, e.g.:

http://home.in.tum.de/~jain/software/oe-quotefix/
http://www.morver.de/english.htm

Or instead one could simply admit that there is software better of
quality and support out there and make a change. Alas, that is highly
unlikely, too, since I from a group of many netizen have observed that
there is a tendency in OjE users to develop an attitude where they blame
others for their own faults, surprisingly often the people who point the
problems out to them.
F'up2 poster (notice that your b0rken OjE will also post to the
newsgroup although the standards state that, if unchanged, replies
should then be sent only via e-mail. Use View, Show All Headers
[or similar] to see this confirmed [and please remove the
Newsgroups header then if you reply].)
PointedEars
Jul 20 '05 #28

P: n/a
"Ira Baxter" <id******@semdesigns.com> writes:
Obfuscated source has *one* secret:
the map between the original names and the obfuscated names.
The problem is that you don't need the map to use the page.
You can make your own map. It might even be better.

So as a *secret*, it's not impressive, and gives no security, only
obscurity.
Complain to Microsoft. Maybe that will help.
No. I'll complain to you. You are solely responsible for everything
you post. You seem to be using Outlook Express. There are programs to
fix its quoting, I believe this is one:
<URL:http://www.webattack.com/get/oequotefix.html>
That's *an* alternative. Other people may have other opinions.
But it takes us back the original argument: you can leave
your front door unlocked. It is a choice, sure.
In comparison, obfuscation corresponds to hanging a sign on the door
saying "this door is locked". That's a choice too, and it will probably
even discourage some people (although "the dog bits" is probably better).
I don't know how we got onto this "encryption" topic.
I thought we we talking about obfuscation, in which the code
executed by the browser is visible (as we all agree,
it must be).
There are several levels of obfuscation. The simplest is just renaming
variables. AFter that, you can encode the page or scripts in different
ways, and use Javascript to decode it. The point was that it's still
only obfuscation, not security.
Eh? If you have client side, by absence of any other viable choices,
you page is already JavaScript dependent. It may consequently
be subject to failure (although I don't know why you think
JavaScript is any more subject to failure than the HTML
or the browser or whatever),
Because statistcs say that 10% of users browser with Javascript turned
off. A browser that doesn't understand HTML is lost. A browser that
doesn't understand Javascript (or choses not to) can still use most
pages.

In this group, the general recommendation is to use Javascript to
*enhance* a page, but make sure it still works without Javascript.
Graceful degredation.
but you are stuck with the dependency.
If your page really *needs* Javascript, yes. Few pages do. Even
the ubiquitous form validation is only a service to the user:
It saves a roundtrip to the server when there are errors in the
form. The form still works without Javascript, you just have to
wait to get a response back, if you make an error.

If you use Javascript to encode the HTML of the page, then the
*entire* page depends on Javascript, and 10% of the potential
users will see nothing. That's bad design.
I'm surprised you didn't accuse me being the quack, since my
company offers one of the "snake oil" solutions.
I didn't know :)
I repeat,
Obfuscation won't prevent theft of code. I've never claimed otherwise.
(There are other obfuscator tool vendors that *do* claim
otherwise, and I agree with that is an unreasonable claim).
Good. That is my stand too.
Security is always about making it harder for the "other guy"
to compromise what you wish to secure. It is never
absolute.
Correct. Security is based on a threat model. You decide how likely
each threat is, how much damage it can cause, and consequently, how
many ressources you should use to prevent it (or repair, if the damage
is done). Somebody nuking your datastore is a threat, but unlikely and
impossible to protect against. Network based intrusion is easier to
do, but also easier to monitor and prevent, because you control the
access route.

You can make absolute security against some attacks.
So one must decide how much security one can afford, and how to
implement that.
First one must decide what to protect against. Skipping that step
will only give you an unknown amount of security.
People interested in obfuscators seem to have a pretty clear goal.
I don't think so. They *think* they do, but the goal includes vague
terms like "competitors", or just "other people".

I haven't studied the market. You probably have. My impression is
based on the people I see in this group (and other similar groups)
who want to "protect their pages against thieves". Only very rarely
do they have anything but a feeling that "other people" shouldn't
be able to benefit freely from their hard work.
They are shipping code they wrote at some cost to the public.
They'd prefer not to have that code used by a competitor easily.
The keyword here is probably "easily". How easy the obfuscation is to
counter depende *entirely* on the competitor. If the competition is
people like me, "not easily" is quite hard.

The code that I have seen obfuscated wasn't worth stealing anyway :)
Copyright is one method that helps.
That's the one I would use. It only takes two lines of comments to say
that it's your code and that infringers will be prosecuted, and it's a
hell of a lot scarier than any Javascript based obfuscation.
Compiling is another (can't do it for JavaScript). Obfuscation is a
third.


Definitly. And even compiling is not security against people learning
how the code works. It's just a lot more work to reproduce than simpler
obfuscation.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #29

P: n/a
"Ira Baxter" <id******@semdesigns.com> wrote in message
news:3f********@giga.realtime.net...
<snip>
Security is always about making it harder for the "other
guy" to compromise what you wish to secure. It is never
absolute. So one must decide how much security one
can afford, and how to implement that.


Harder is a relative term. On the desk in front of me there is a cup and
sitting next to it there is one of those large computer programming
manuals. If I wanted to make it harder for someone to take the cup away
I could pick the manual up and rest it on the cup. It is now harder to
take the cup, but not so hard as to make it worth my effort to even
consider picking the book up (and certainly not paying anyone else to do
so).

We are all agreed that anyone (at least anyone with enough knowledge to
be able to do anything with the results) is capable of getting at
client-side JavaScript source code, obfuscated or not. And there should
be no argument that having acquired the source text there is software
that will re-format it into normally formatted JavaScript source
(indented blocks, statements on separate lines and so on) and reversing
the escape encoding of string literals is also easily automated
(possibly available as part of the same process). So it is the fully
formatted source code displayed in a syntax highlighting text editor
that is available to the interested viewer at little effort. (Syntax
highlighting of course reverses the effect of using initial lower case
"l" and upper case "O" characters followed by decimal digit sequences as
obfuscated identifiers so that they superficially resemble numbers, as
it makes those identifiers distinct from source code numbers by coloring
them differently.)

The obfuscator cannot modify the property names used in DOM interaction,
they are all still there so the only difference for the reader is that
what may have been meaningful identifier names in the original code are
now just distinct character sequences that convey no additional meaning.
But that is not a bar to understanding the code. The identifiers still
have the required relationship, searching the document for an identifier
used in a function call will still locate the corresponding function
definition, variables can still be recognised and there use tracked. And
with client side scripts it is the DOM interaction that tells most about
what is going on.

Meaningful identifiers may be an aid to human understanding, but that
doesn't make meaningless identifiers a bar to it. And this group has
frequently provided example of how insignificant identifier names are as
its international nature means that code is frequently posted with
identifier names that (hopefully) are meaningful in the posters native
language but mean nothing to me. That doesn't stop me form understanding
the code, spotting errors and posting corrections. It isn't necessary to
know what the identifiers used are intended to mean to work on source
code, all of the important information is in there distinctness as
identifiers, the operations performed on and with them and the related
DOM interactions (and the block structure expressed by the formatting).

Indeed, around the work there must be thousands of non-English
speaking/reading programmes who have not only managed to learn
client-side programming with examples who's identifiers were commonly in
English but also happily interact with a browser DOM in which all the
property names are all in English. That may make it harder for them, but
it doesn't seem to prevent them form achieving anything. The
distinctness of the identifiers must be sufficient and obfuscation
cannot take that away.

So, does obfuscating make understanding client-side source code harder
for the "other guy"? Probably yes, but not really any more than placing
a large book on top of a cup makes taking the cup away harder.
Until ou tell us *exactly* what you want to prevent (who
should not be allowed to do what), we can't give you
anything but general solutions.


People interested in obfuscators seem to have a pretty clear
goal. They are shipping code they wrote at some cost to the
public. They'd prefer not to have that code used by a
competitor easily. Copyright is one method that helps.
Compiling is another (can't do it for JavaScript). Obfuscation
is a third.


The argument (currently, as I notice that the site has been considerably
modified over the last week) proposed on your web site and in other
posts is that once obfuscated nobody will go to the effort of trying to
understand the code. But, as the effort is not really that great, the
willingness of any competitor to go to the effort must be related to the
perceived value of the code under consideration. Leaving a relationship
of; if the code is worth understanding it is worth putting in the effort
to understand it (so no real protection as obfuscation does not prevent
understanding) and if it is not worth putting the effort into it didn't
need protecting in the first place.

So if the originators of the code perceive it as having sufficient value
that there competitors are likely to steal it then it doesn't make sense
for them to squander their resources on a process that will do no more
than make that slightly harder. They would be better of clearly stating
their intellectual rights and their willingness to inforce them and
spending the resources talking to legal experts on the best strategy for
achieving regress in they event that they perceive there rights to have
been violated in the future.

And if it turned out that legal regress was not achievable then they are
no worse off because meaningful protection was never achievable either.

Richard.
Jul 20 '05 #30

P: n/a
"Ira Baxter" <id******@semdesigns.com> wrote in message
news:3f********@giga.realtime.net...
<snip>
You use a doctor, right?
I know my doctor's solutions aren't perfect.
But I'm a lot happier to use his partial solutions
than to have no doctors at all.


Being attended to by blood-letting butchers can be worse
than having no doctors at all.


Using an amateur doctor when you have need and nothing else
is available is smarter than not using a doctor at all.


You think? With a burst appendix visiting the local homeopathist would
do nothing to influence your subsequent painful death. When an action is
futile (and possibly expensive) it is smarter not to bother.

Richard.
Jul 20 '05 #31

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
You think? With a burst appendix visiting the local homeopathist would
do nothing to influence your subsequent painful death. When an action is
futile (and possibly expensive) it is smarter not to bother.


Hmm, that's not a very good example. Both visiting the homeopathist and
doing nothing will end you up dead. Might as well have compagny :)
/L 'the road of excess leads to the palace of wisdom ... not!'
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #32

P: n/a
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:u1**********@hotpop.com...
You think? With a burst appendix visiting the local homeopathist
would do nothing to influence your subsequent painful death. When
an action is futile (and possibly expensive) it is smarter not to
bother.
Hmm, that's not a very good example. Both visiting the homeopathist
and doing nothing will end you up dead.
But that was my point. When action and inaction predictably have the
same outcome then inaction is probably smarter (especially if action
incurs expense).
Might as well have compagny :)


In my (fortunately limited) experience of extreme pain company has never
been a consideration. If it were homeopathists would be towards the end
of a list of people I would choose to spend time with (Though there may
be some hollow amusement to be gained from expiring on their premises).

Richard.
Jul 20 '05 #33

P: n/a
Lee
Ira Baxter said:
However, when the cost of "undoing" obfuscation seems to exceed
the cost of simply doing it from scratch, reasonable people
won't bother doing the reverse engineering.
Even *competent* people won't bother in this case.


If you're just trying to prevent somebody from using
your secret programming techniques, then, by all means,
amuse yourself with obfuscation, but don't recommend it in
public without making it clear to all that it must never
be used to protect anything really worth protecting, like
the method you use to retrieve my account information.

In that case, it doesn't matter that 99% of the people
won't bother with it. It only takes one.

Jul 20 '05 #34

P: n/a
JRS: In article <u1**********@hotpop.com>, seen in
news:comp.lang.javascript, Lasse Reichstein Nielsen <lr*@hotpop.com>
posted at Thu, 27 Nov 2003 02:31:33 :-
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
You think? With a burst appendix visiting the local homeopathist would
do nothing to influence your subsequent painful death. When an action is
futile (and possibly expensive) it is smarter not to bother.


Hmm, that's not a very good example. Both visiting the homeopathist and
doing nothing will end you up dead. Might as well have compagny :)


If you are expecting to end up dead, it is good to arrange that your
heirs have someone to sue about it.
My view differs from some of those stated.

Accepted that code put on the Net cannot be protected from
misappropriation by the reasonably skilled.

But there is a much larger number of substantially unskilled, and one
might reasonably wish and hope to prevent them from making use of one's
code. This can be done with little effort, if one has obfuscation
software. One should not, however, obfuscate all copyright statements.

There is an analogy. It is well-nigh impossible to use a motor-car and
be completely safe against theft of or from it. But the precaution of
locking it and not leaving the keys accessible does protect against many
forms of casual theft, if only by encouraging would-be thieves to choose
easier targets.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.
Jul 20 '05 #35

P: n/a
Dr John Stockton <sp**@merlyn.demon.co.uk> writes:
Accepted that code put on the Net cannot be protected from
misappropriation by the reasonably skilled.

But there is a much larger number of substantially unskilled, and one
might reasonably wish and hope to prevent them from making use of one's
code.
This is where my imagination fails me. What can these unskilled people
use your code for that will in any way hurt you? If the worst they can
do is use it without permission, then I don't think it's worth going
through any trouble for.

If you have specific competitors that should not be able to use your
code, watch their pages and hit them with the copyright law if they do.
There is an analogy. It is well-nigh impossible to use a motor-car and
be completely safe against theft of or from it. But the precaution of
locking it and not leaving the keys accessible does protect against many
forms of casual theft, if only by encouraging would-be thieves to choose
easier targets.


The problem with this analogy [1] is that theft of a car leaves you
without a car. That makes theft easy to spot. It also requires close
proximity to your car at a time where not too many people are watching.
This lowers the number of potential thieves quite a lot, and makes a
lock a usable precaution (breaking the window or using a crowbar is
hard to do unnoticed).

Compare this to using someone else's code. It can be done in complete
privacy by anybody, anywhere, and you have no way of finding out (also
meaning that you suffer no loss). How much is it *really* worth to
make it a little harder to use your code?

Copyright infringement is not theft! Comparing the two is like comparing
apples and anvils.

/L
[1] It seems to be the rule that all car analogies used on Usenet are flawed.
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #36

P: n/a
On Wed, 26 Nov 2003 23:54:26 +0100, Lasse Reichstein Nielsen
<lr*@hotpop.com> wrote:
That's a choice too, and it will probably
even discourage some people (although "the dog bits" is probably better).


Pinning up a picture of your dogs testicles will discourage people?
Cheers I'll have to try that, normally I just warn about them biting.
:-)
They are shipping code they wrote at some cost to the public.
They'd prefer not to have that code used by a competitor easily.


The keyword here is probably "easily". How easy the obfuscation is to
counter depende *entirely* on the competitor. If the competition is
people like me, "not easily" is quite hard.


The thing is, we are the only people that matter, muppets couldn't put
a non-obfuscated script modified to their needs in place, and anyone
else, we can change an obfuscated one almost as easily as a
non-obfuscated one - remember we only need to change the things that
matter to our theft.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #37

P: n/a
On Thu, 27 Nov 2003 00:13:26 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:
And there should
be no argument that having acquired the source text there is software
that will re-format it into normally formatted JavaScript source
(indented blocks, statements on separate lines and so on) and reversing
the escape encoding of string literals is also easily automated
(possibly available as part of the same process).


Recently I just took on some javascript hacking, there was a 200k
javascript source file, uncommented, poorly styled, not actively
obfuscated, but it might aswell have been, I needed to get this into a
state I could do something with it.

astyle and xemacs got it reflowed in seconds, a nice little lint
script from someone not too far away got it integrated into the build
process and now the other guys shouldn't go screwing anything else up
in future.

The tools are free, they were already on my desktop anyway, and they
do a great job of code formatting.

Cheers.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #38

P: n/a
Dr John Stockton <sp**@merlyn.demon.co.uk> writes:
They can, while leaving in the code a statement that I wrote it, make
unsound changes and release the code, after which I may receive the
complaints.
That is a problem. Not one I would solve with obfuscation, though.
More likely by adding a line next to the attribution saying either
"May not be republished without author's permission" or (more likely)
"don't trust this code if not downloaded from myhomepage.example.com".
One of the much-advertised Javascript sites has in fact taken my code
without permission and published it, but incompletely so that it is not
workable while still evidently originated by me; had it been obfuscated,
they might not have bothered with it.
Correct me if I'm wrong, but it seems that you are publishing your code
so that people can read it and learn from it. That makes obfuscation
unsuited.
(I almost never give permission for my material [text and/or code]
to be republished, although I allow it to be used, because I want
updating to have immediate effect on all legitimate public copies.)
Very reasonable.
Assuming a reliable and rapid obfuscator, one might wish to obfuscate
partially-developed code that was being made publicly visible for test.
That is more reasonable. It is code that is not intended for reading
or reuse. I would still add a line saying so ("use after October 2001
considered harmfull")
Remember, that which is a reasonable reason for an average scripter to
obfuscate may not be a good reason for you to do so.


True. But I haven't met an average scripter with a well thought out
argument for obfuscation. They might have one, but they sure don't
present it here :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #39

P: n/a
JRS: In article <ek**********@hotpop.com>, seen in
news:comp.lang.javascript, Lasse Reichstein Nielsen <lr*@hotpop.com>
posted at Fri, 28 Nov 2003 23:11:46 :-
Dr John Stockton <sp**@merlyn.demon.co.uk> writes:
They can, while leaving in the code a statement that I wrote it, make
unsound changes and release the code, after which I may receive the
complaints.


That is a problem. Not one I would solve with obfuscation, though.
More likely by adding a line next to the attribution saying either
"May not be republished without author's permission" or (more likely)
"don't trust this code if not downloaded from myhomepage.example.com".


But anyone can remove that; legal methods of recourse are often
impractical, and appeals to the morals of potential copiers are not
necessarily effective.
One of the much-advertised Javascript sites has in fact taken my code
without permission and published it, but incompletely so that it is not
workable while still evidently originated by me; had it been obfuscated,
they might not have bothered with it.


Correct me if I'm wrong, but it seems that you are publishing your code
so that people can read it and learn from it. That makes obfuscation
unsuited.


You are right; but it would be possible for my code to be written
without that intention, but still with the wish that it not be
republished.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.
Jul 20 '05 #40

P: n/a
To "obfuscate" your JS code, try this little utility:

http://utenti.lycos.it/ascii2hex/

It may help to confuse novices...
Jul 20 '05 #41

P: n/a
Google hu kiteb:
To "obfuscate" your JS code, try this little utility:

http://utenti.lycos.it/ascii2hex/

It may help to confuse novices...


Anyone so green that this would deter them is also too green to adjust
an unobfuscated script to meet their specific needs.

For me, I'd just c+p into sc unipad, then it is a single right mouse
click away from converting into more human-readable text.

--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

Jul 20 '05 #42

This discussion thread is closed

Replies have been disabled for this discussion.