invisible javascript

[Evertjan.]

Re: invisible javascript

Douglas Crockford wrote on 17 nov 2003 in comp.lang.javas cript:
[color=blue][color=green]
>> 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.[/color]
>
> That's just silly.[/color]

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

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

[Thomas 'PointedEars' Lahn]

Re: invisible javascript

Evertjan. wrote:
[color=blue]
> Douglas Crockford wrote on 17 nov 2003 in comp.lang.javas cript:[color=green][color=darkred]
>>> 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.[/color]
>>
>> That's just silly.[/color]
>
> So you can be fooled? Sorry, I did not expect that.[/color]

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

[Evertjan.]

Re: invisible javascript

Thomas 'PointedEars' Lahn wrote on 18 nov 2003 in comp.lang.javas cript:[color=blue]
> All you do by those CR/LF is to increase document
> size, thus increase loading time[/color]

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)

[Ira Baxter]

Re: invisible javascript

"HikksNotAtHome " <hikksnotathome @aol.com> wrote in message
news:2003111516 4849.22081.0000 1879@mb-m17.aol.com...[color=blue]
> In article <3fb67595$1@gig a.realtime.net> , "Ira Baxter"
> <idbaxter@semde signs.com> writes:
>[color=green][color=darkred]
> >> Other than that, if the browser can see it, so can I.[/color]
> >
> >You mean, you could "encode" it with an encoder,
> >for which you can find a decoder.[/color]
>
> No, he meant "obfuscate" it.
>[color=green]
> >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.[/color]
>
> Doesn't matter if its "obfuscated " or "encoded". The fact remains that for[/color]
the[color=blue]
> browser to execute it, it *must* send the code. And getting the original[/color]
is[color=blue]
> trivial from there.[/color]

That's an arguable point.
[color=blue]
> To sell an obfuscator and advertise it as "foolproof"
> should be illegal in civilized countries as false advertising.[/color]

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 =---

[Douglas Crockford]

Re: invisible javascript

> > To sell an obfuscator and advertise it as "foolproof"[color=blue][color=green]
> > should be illegal in civilized countries as false advertising.[/color]
>
> 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.[/color]

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

[Thomas 'PointedEars' Lahn]

Re: invisible javascript

Evertjan. wrote:
[color=blue]
> Thomas 'PointedEars' Lahn wrote on 18 nov 2003 in comp.lang.javas cript:[color=green]
>> All you do by those CR/LF is to increase document
>> size, thus increase loading time[/color]
>
> Yes, sure,
> by 70 bytes,[/color]

Depends on how many CR/LF you include.
[color=blue]
> so by 10 milliseconds at 7kB/s,
> or 100 microseconds at 700kB/s.[/color]

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


PointedEars

[Evertjan.]

Re: invisible javascript

Thomas 'PointedEars' Lahn wrote on 20 nov 2003 in comp.lang.javas cript:[color=blue]
> Evertjan. wrote:
>[color=green]
>> Thomas 'PointedEars' Lahn wrote on 18 nov 2003 in comp.lang.javas cript:[color=darkred]
>>> All you do by those CR/LF is to increase document
>>> size, thus increase loading time[/color]
>>
>> Yes, sure,
>> by 70 bytes,[/color]
>
> Depends on how many CR/LF you include.
>[color=green]
>> so by 10 milliseconds at 7kB/s,
>> or 100 microseconds at 700kB/s.[/color]
>
> You should read my postings to the end
> and learn how to quote (mark omissions).[/color]

Did I step on your ears, Thomas ?


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

[Anonymous]

Re: invisible javascript

"Douglas Crockford" <nospam@laserli nk.net> wrote in message
news:1f9ea$3fba bf38$44a4af1f$2 6015@msgid.mega newsservers.com ...[color=blue][color=green][color=darkred]
> > > To sell an obfuscator and advertise it as "foolproof"
> > > should be illegal in civilized countries as false advertising.[/color]
> >
> > 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.[/color]
>
> I'm not sure who is doing the misquoting here.[/color]

Where's the quote in question?
[color=blue]
> Let me state some Principles of Security.
>
> Security is not obtained by obfuscation. Security is not obtained by[/color]
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.
[color=blue]
> Security is obtained from solid design, and the diligent management of as[/color]
few[color=blue]
> secrets as possible.
>
> False security (obfuscation, for example) is worse than no security. False
> security increases misplaced confidence and reduces vigilance and[/color]
diligence.[color=blue]
> False security leads to bad decision making and increased vulnerability.[/color]

*No* security leads to increased vulnerability, too.
[color=blue]
> The specific question here is "Can a script in a page be completely[/color]
hidden?" A[color=blue]
> "yes" answer must provide a demonstration in the form of a URL to a page[/color]
with a[color=blue]
> hidden script. A "yes" answer without such a demonstration is ultimately
> dishonest.[/color]

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.
[color=blue]
> Similarly, weakening the criteria to "Can a script in a page be hidden[/color]
from the[color=blue]
> incompetent?" is misleading and shameful.[/color]

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".
[color=blue]
> http://www.crockford.com[/color]


--
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 =---

[Lasse Reichstein Nielsen]

Re: invisible javascript

Anonymous <Nobody> writes:
[color=blue]
> "Douglas Crockford" <nospam@laserli nk.net> wrote in message
> news:1f9ea$3fba bf38$44a4af1f$2 6015@msgid.mega newsservers.com ...[/color]
[color=blue][color=green]
>> Let me state some Principles of Security.
>>
>> Security is not obtained by obfuscation. Security is not obtained by[/color]
> 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.[/color]

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.
[color=blue][color=green]
>> Security is obtained from solid design, and the diligent management of as[/color]
> few[color=green]
>> secrets as possible.[/color][/color]

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.

....[color=blue]
> 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.[/color]

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

I have a bookmarklet:
---
javascript:(doc ument.documentE lement||documen t.body).innerHT ML.replace(/&/g,"&amp;").repl ace(/</g,"&lt;").repla ce(/\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][color=blue]
> Rejecting such solutions because they aren't absolutely perfect
> leaves you with no solutions at all.[/color]

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?
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Douglas Crockford]

Re: invisible javascript

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


Half measures are not always better than nothing. Futile gestures on The Net are
not effective.
[color=blue]
> 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.[/color]

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.

[Ira Baxter]

Re: invisible javascript

> The password verification algorithm is public knowledge, or should be[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
> >> Security is obtained from solid design, and the diligent management of[/color][/color][/color]
as[color=blue][color=green]
> > few[color=darkred]
> >> secrets as possible.[/color][/color]
>
> 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.[/color]

Complain to Microsoft. Maybe that will help.
[color=blue][color=green]
> > 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.[/color]
>
> The viable alternative to obfuscating your web page is ... not to do
> it.[/color]

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.
[color=blue]
> I have a bookmarklet:
> ---
>[/color]
javascript:(doc ument.documentE lement||documen t.body).innerHT ML.replace(/&/g,
"&amp;").replac e(/</g,"&lt;").repla ce(/\n/g,"<br>")[color=blue]
> ---
> It reveals the actual running HTML code of a page, no matter how many
> levels of encryption it was hidden in originally.[/color]

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).
[color=blue]
> [locks on doors][color=green]
> > Rejecting such solutions because they aren't absolutely perfect
> > leaves you with no solutions at all.[/color]
>
> 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?[/color]

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.
[color=blue][color=green]
> > 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.[/color]
>
> That's a bad analogy. Security is hard to compare to other areas.[/color]

Claiming that "Security is different" isn't an argument.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
> > Most engineering solutions are compromises. Some accept the[/color][/color]
compromises.[color=blue][color=green]
> > Some don't. You are welcome to your opinions about whether
> > the compromise works for you. And I think it fine that you should[/color][/color]
explain[color=blue][color=green]
> > to others why it does not work for you, so they can make a reasoned[/color][/color]
choice.[color=blue]
>
> Most engineering solutions are solutions to a specific problem.
> Please state the problem exactly :)[/color]

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 =---

[Ira Baxter]

Re: invisible javascript


"Douglas Crockford" <nospam@covad.n et> wrote in message
news:e3917$3fc1 3de9$44a4afcc$8 212@msgid.megan ewsservers.com. ..[color=blue][color=green][color=darkred]
> > > Similarly, weakening the criteria to "Can a script in a page be hidden
> > > from the incompetent?" is misleading and shameful.[/color][/color]
>[color=green]
> > Rejecting such solutions because they aren't absolutely perfect
> > leaves you with no solutions at all.[/color]
>
> Half measures are not always better than nothing. Futile gestures on The[/color]
Net are[color=blue]
> not effective.[/color]

This isn't going anywhere. I use a spam detector to filter junk.
It is futile. But still useful.
[color=blue][color=green]
> > 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.[/color]
>
> Being attended to by blood-letting butchers can be worse than having no[/color]
doctors[color=blue]
> at all.[/color]

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.
[color=blue]
> 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[/color]
expect[color=blue]
> that an attack will happen.[/color]

There isn't any such thing as perfect security. Every scheme has holes.
So your proposal is to use no scheme at all?
[color=blue]
> Protecting the privacy privacy of scripts on public pages is impossible.[/color]

Privacy? I thought we were talking about making source code
harder to understand.
[color=blue]
> I repeat, anyone who is differently is either misinformed or lying.[/color]

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.
[color=blue]
>Obfuscation will not
> prevent a competent programming from reading and using your scripts.[/color]

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.
[color=blue]
> Obfuscators are bogus. Obfuscation does not work.[/color]

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 =---

[Thomas 'PointedEars' Lahn]

[OT] Outlook (Express) bugs (was: invisible javascript)

Ira Baxter wrote:

Please include an attribute line (like the above one) so one can see who
is quoted at each quoting level.
vvvvvvvvvvvvvvv vvvvvvvvvvvvvvv vv[color=blue][color=green]
>> 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.[/color]
>
> Complain to Microsoft.[/color]

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.
[color=blue]
> Maybe that will help.[/color]

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

[Lasse Reichstein Nielsen]

Re: invisible javascript

"Ira Baxter" <idbaxter@semde signs.com> writes:
[color=blue]
> Obfuscated source has *one* secret:
> the map between the original names and the obfuscated names.[/color]

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.
[color=blue]
> Complain to Microsoft. Maybe that will help.[/color]

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.c om/get/oequotefix.html >
[color=blue]
> 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.[/color]

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).
[color=blue]
> 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).[/color]

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.
[color=blue]
> 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),[/color]

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.
[color=blue]
> but you are stuck with the dependency.[/color]

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.
[color=blue]
> I'm surprised you didn't accuse me being the quack, since my
> company offers one of the "snake oil" solutions.[/color]

I didn't know :)
[color=blue]
> 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).[/color]

Good. That is my stand too.
[color=blue]
> Security is always about making it harder for the "other guy"
> to compromise what you wish to secure. It is never
> absolute.[/color]

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.
[color=blue]
> So one must decide how much security one can afford, and how to
> implement that.[/color]

First one must decide what to protect against. Skipping that step
will only give you an unknown amount of security.
[color=blue]
> People interested in obfuscators seem to have a pretty clear goal.[/color]

I don't think so. They *think* they do, but the goal includes vague
terms like "competitor s", 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.
[color=blue]
> 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.[/color]

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 :)
[color=blue]
> Copyright is one method that helps.[/color]

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.
[color=blue]
> Compiling is another (can't do it for JavaScript). Obfuscation is a
> third.[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

Re: invisible javascript

"Ira Baxter" <idbaxter@semde signs.com> wrote in message
news:3fc4d66a$1 @giga.realtime. net...
<snip>[color=blue]
>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.[/color]

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.
[color=blue][color=green]
>>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.[/color]
>
>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.[/color]

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.