Hiding my javascript

[Simon Wigzell]

I have developed a javascript application that can be used by my clients just by inserting the following in one of their web pages:

<script>
document.write( '<iframe src="http://www.dynamicwebs itesystems.com/PGSampleTable.a sp"></iframe>')
</script>

Anyone looking at the page containing the above will only see the the above lines, not all the javascript source. Someone with a little more savy though could just paste http://www.dynamicwebsitesystems.com/PGSampleTable.asp into their browser and then they will see the javascript.

Is there some way that my PGSampleTable.a sp could know it has been called from outside the iframe and then just not serve the javascript?

Any other way to hide your javascript? (The above is only a prototype, it will eventually be a full costing system for the printing industry - I don't want anyone else to be able to steal it!)

[Richard Cornford]

Dr Clue wrote:
<snip>

<script>
var szSerialNo="SN" ;for(i in top){ee=eval("t op."+i);
if(typeof ee=='number')sz SerialNo+=ee+St ring(i).substri ng(0,1);}
document.locati on.href=documen t.location.href +"?"+szSeria lNo
</script>

This will result in a second call something like
http://www.dynamicwebsitesystems.com...asp?SN105s0l4s

Now depending on this value you can send back script for
your application or a fake script for the nozy to stare at.

The reason to have a fake script is to keep the curious
from realizing what exactly you did. <snip> There are more things you can do to verify the serial number
but the idea is not to let the nozy person know what your
looking for.

Given that pulling the files actually downloaded from the browser's
cache is a fairly normal strategy for examining complete 3rd party
scripts, this will be a less than successful strategy.

But since Simon Wigzell frequently asks trivial questions on this group
it is likely that his expectation of interest in his script greatly
exceeds reality, and that much of that script is not actually his own
work anyway.

Richard.

[Dr Clue]

Richard Cornford wrote:

Dr Clue wrote: <snip> Given that pulling the files actually downloaded from the browser's
cache is a fairly normal strategy for examining complete 3rd party
scripts, this will be a less than successful strategy.

I think the key word in my response was "Offiscatio n".
Of course one could do so even further by getting
the scripts via post , fiddling with the cache headers
and having faux versions of key functions that overlay
one another.

But heck , much of this stuff is like cheap bicycle locks,
in that they are meant to discourage theft, but can hardly prevent it.

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML, CSS,Javascript
--=<> http://resume.drclue.net <>=-- AJAX, SOAP, XML, HTTP
--=<> http://www.drclue.net <>=-- SERVLETS,TCP/IP, SQL
--.

[Richard Cornford]

Dr Clue wrote:

Richard Cornford wrote:

Dr Clue wrote: <snip>

Given that pulling the files actually downloaded from the
browser's cache is a fairly normal strategy for examining
complete 3rd party scripts, this will be a less than
successful strategy.

I think the key word in my response was "Offiscatio n".
Of course one could do so even further by getting
the scripts via post , fiddling with the cache headers

If it is in the browser it is in the browser's cache, so post requests
and fiddling with headers will make no difference (except that implied
need to repeatedly download the same script would represent a needless
(and pointless) performance hit).
and having faux versions of key functions that overlay
one another.
But given the full set of scripts and HTML (and images, etc) from the
cache it is not that difficult to work out what is going on.
But heck , much of this stuff is like cheap bicycle locks,
in that they are meant to discourage theft, but can hardly
prevent it.

If you use a cheep bicycle lock in London your bicycle _will_ be stolen,
no question about it (unless it is self evidently such a wreck that an
observer would not believe it was even functional).

The whole obfuscation business is protection against individuals who
don't know enough to actually have a use for any script they discover.
Once they have learnt to understand and use any script they may find
they have learnt enough to defeat any 'protection'. After all, the
ability to search with google is pretty much all that is required.

Richard.

[Dr Clue]

Richard Cornford wrote:

Dr Clue wrote:

<snip

But heck , much of this stuff is like cheap bicycle locks,
in that they are meant to discourage theft, but can hardly
prevent it.

If you use a cheep bicycle lock in London your bicycle _will_ be stolen,
no question about it (unless it is self evidently such a wreck that an
observer would not believe it was even functional).

Thats exactly why the asp script would return the
faux code (crappy bike).

This faux code would would have enough code to look genuine
perhaps having deliberately flawed yet running functions.

So as far as the person doing a view-source , is concerned
they've stolen my crappy bike, and have no reason to suspect
that the crappy bike is a sham that hides my good bike.
--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML, CSS,Javascript
--=<> http://resume.drclue.net <>=-- AJAX, SOAP, XML, HTTP
--=<> http://www.drclue.net <>=-- SERVLETS,TCP/IP, SQL
--.