Javascript on steroids!

[drclue]

Would you like to display the weather,
stocks,movie listings or perhaps send someone an
SMS text message or fax?

Did you think Google or Yahoo maps was cool?

No matter the back end or third-party resource ,
chances are I could glue it all together
with simple javascript running in your page.

Want to know how it works , want to contribute,
want a turn key? say something!

I've been coding the internet since 1994 and
programming in general since before the advent
of the "PC".

[runner7]

Ok, how do you programmatically send a particular keystroke to Firefox?
I do not mean detect a keystroke.

http://groups.google.com/group/comp....f185f19fb2d0f4

[petermichaux]

drclue wrote:

Would you like to display the weather,
stocks,movie listings or perhaps send someone an
SMS text message or fax?

Did you think Google or Yahoo maps was cool?

No matter the back end or third-party resource ,
chances are I could glue it all together
with simple javascript running in your page.

Want to know how it works , want to contribute,
want a turn key? say something!

I've been coding the internet since 1994 and
programming in general since before the advent
of the "PC".

It was only a couple days ago you left a similar promo for lampjack.

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/827b1d86a79f9a75>

You didn't leave a url then and now you are trying to build hype again
with mystery.

<URL: http://www.lampjack.com/>

You said your website is only in the development stage and works in
Firefox. Are you really ready for the onslaught of enthusiasm these
posts will generate?

Peter

[drclue]

pe**********@gmail.com wrote:

>
It was only a couple days ago you left a similar promo for lampjack.

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/827b1d86a79f9a75>

You didn't leave a url then and now you are trying to build hype again
with mystery.

<URL: http://www.lampjack.com/>

You said your website is only in the development stage and works in
Firefox. Are you really ready for the onslaught of enthusiasm these
posts will generate?

Actually , yes I am ready for what I'm asking for.

I could offer free sex in the NG's and only see a trickle
of responses, but heck if you or others have code they would
like to run cross domain , or who would like to be early adopters ,
I'm there. I'll take what few if any folks actually respond and use them
as my focus group in refining the service both for the WYSIWYG crowd
and the down and dirty coder with some cool script, or even
the coder who wishes javascript could run a database and I will grant
their wish.

I'm making all the server side stuff up for grabs as cross-domain
javascript. Googlemaps is nice , but I'm offering to broker that and
anything else. You write the javascript and I'll provide the server side
back end and proxy stuff

Anyone up for javascript o steroids?

[Richard Cornford]

pe**********@gmail.com wrote:
<snip>

... and now you are trying to build hype again
with mystery.

<snip>

Mystery is what should be expected, because any laying it on the line
about what the proposed system actual does in likely to elicit many
posts pointing out what a very bad idea it would be for any web site to
use the resulting system.

Google, a large organisation with some regard for its reputation, point
out that they may, at their own discretion, introduce advertising to
Google maps at any time (implying that those employing google maps but
not wanting the advertising will have to move to a commercial
alternative, also provided by Google). What might a less scrupulous
organisation do with centrally sourced script resources? Might they not
see financial advantage in including a speculative spyware installer in
say 1 in 1000 requests for a script? The odds of that being noticed
would be low, and an infected user would probably blame the web site
they were viewing rather than the originator of the scripts, if they
noticed at all. The same goes for a whole host of possible alternative
undesirable insertions. The risks in dynamically sourcing client-side
scripts from third parties are too great for any but the most reputable
sources to be considered.

Richard.

[drclue]

Richard Cornford wrote:

pe**********@gmail.com wrote:
<snip>

>... and now you are trying to build hype again
with mystery.

<snip>

Mystery is what should be expected, because any laying it on the line
about what the proposed system actual does in likely to elicit many
posts pointing out what a very bad idea it would be for any web site to
use the resulting system.

Laying it all on the line would probably get me the wrong
crowd. Not because it is a bad idea , but rather that it is a young
idea of significant worth that is best served by an initial group
of talented users that could both make the best use of the
infrastructure and make the wisest comments and contributions.

Google, a large organisation with some regard for its reputation, point
out that they may, at their own discretion, introduce advertising to
Google maps at any time (implying that those employing google maps but
not wanting the advertising will have to move to a commercial
alternative, also provided by Google).

I appreciate this concern and here will answer it most honestly.
Those using the infrastructure for free may see injected advertising
over time to afford the free services. Those opting to pay for
infrastructure will certainly not see ads in their pages.
It is our hope that the math will work out such that ads will only
be displayed for x number of uses

What might a less scrupulous
organisation do with centrally sourced script resources? Might they not
see financial advantage in including a speculative spyware installer in
say 1 in 1000 requests for a script?

That would be a rude thing to do, and since I am the only one who
totally understands the hand written server side , I will not allow it.
While I do afford a statistical product of user behavior , nothing about
a particular user is ever allowed to be a matter of commerce.

The odds of that being noticed
would be low, and an infected user would probably blame the web site
they were viewing rather than the originator of the scripts, if they
noticed at all. The same goes for a whole host of possible alternative
undesirable insertions. The risks in dynamically sourcing client-side
scripts from third parties are too great for any but the most reputable
sources to be considered.

My reputation , such as it is reaches back to ~1994 as related to the
internet and could never be associated with any harvesting or spamming
operation. Matter-O-Fact to the dismay of some, our SMTP system is
specifically designed to suppress any attempts at spamming and at the
same time affords a system of attribution for every email sent and soon
will include in each mails headers information that will allow us to
swiftly deal with those who might abuse the resources.

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>pe**********@gmail.com wrote:
<snip>

>>... and now you are trying to build hype again
with mystery.

<snip>

Mystery is what should be expected, because any laying
it on the line about what the proposed system actual
does in likely to elicit many posts pointing out what
a very bad idea it would be for any web site to use
the resulting system.

Laying it all on the line would probably get me the wrong
crowd. Not because it is a bad idea , but rather that it
is a young idea of significant worth that is best served
by an initial group of talented users that could both make
the best use of the infrastructure and make the wisest
comments and contributions.

Which does not stop it from still being a bad idea.

>Google, a large organisation with some regard for its
reputation, point out that they may, at their own
discretion, introduce advertising to Google maps at
any time (implying that those employing google maps
but not wanting the advertising will have to move to
a commercial alternative, also provided by Google).

I appreciate this concern and here will answer it most
honestly.

The Epimenides paradox.

Those using the infrastructure for free may see injected
advertising over time to afford the free services.

So there is no question that the system will facilitate script injection
beyond the control of the web sites using it.

Those opting to pay for infrastructure will certainly not
see ads in their pages.

And what the eye doesn't see ...

It is our hope that the math will work out such that ads
will only be displayed for x number of uses

Presumably these adds are provided by third parties and then injected by
your server scripts. Which introduces the potential for another layer of
unscrupulous script insertion originating with the advertisers.

>What might a less scrupulous organisation do with
centrally sourced script resources? Might they not
see financial advantage in including a speculative
spyware installer in say 1 in 1000 requests for a script?

That would be a rude thing to do, and since I am the only
one who totally understands the hand written server side,
I will not allow it.

Which, apart from assuming honesty on your part, assumes you have
control now and retain control indefinitely. However, profit motivated
commercial ventures do change hands both when they are successful and
when they approach failure.

While I do afford a statistical product of user behavior,
nothing about a particular user is ever allowed to be a
matter of commerce.

You are planning to monitor user's behaviour?

>The odds of that being noticed would be low, ...

<snip>

>The risks in dynamically sourcing client-side
scripts from third parties are too great for
any but the most reputable sources to be considered.

My reputation , such as it is reaches back to ~1994 as
related to the internet and could never be associated
with any harvesting or spamming operation.

It is significant that your self-proclaimed long experience of the
Internet leaves you proposing that people do something that I would
consider suicidally reckless.

Matter-O-Fact to the dismay of some, our SMTP system is
specifically designed to suppress any attempts at spamming
and at the same time affords a system of attribution for
every email sent and soon will include in each mails
headers information that will allow us to swiftly deal
with those who might abuse the resources.

Web site security is largely a matter of exercising and keeping control
where you have control, on your own servers. Letting a third party
inject scripts on the client is sufficiently risky to make loud
assertions of honesty, responsibility and safety made by the providers
of those scripts insufficient justification for using them.

Richard.

[drclue]

Richard Cornford wrote:

Web site security is largely a matter of exercising and keeping control
where you have control, on your own servers. Letting a third party
inject scripts on the client is sufficiently risky to make loud
assertions of honesty, responsibility and safety made by the providers
of those scripts insufficient justification for using them.

So let's all ditch our on-line banking , throw out the googlemaps, turn
off our javascript and join our friends huddled in an undisclosed
location, crying loudly about weapons of mass destruction. :)

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>Web site security is largely a matter of exercising and keeping
control where you have control, on your own servers. Letting a
third party inject scripts on the client is sufficiently risky to
make loud assertions of honesty, responsibility and safety
made by the providers of those scripts insufficient justification
for using them.

So let's all ditch our on-line banking , throw out the googlemaps,
turn off our javascript and join our friends huddled in an
undisclosed location, crying loudly about weapons of mass
destruction. :)

Why? Serving scripts from our own servers (and so being certain of what
will be in them) is hardly arduous.

Richard.

[drclue]

Richard Cornford wrote:

drclue wrote:

>Richard Cornford wrote:

>>Web site security is largely a matter of exercising and keeping
control where you have control, on your own servers. Letting a
third party inject scripts on the client is sufficiently risky to
make loud assertions of honesty, responsibility and safety
made by the providers of those scripts insufficient justification
for using them.

So let's all ditch our on-line banking , throw out the googlemaps,
turn off our javascript and join our friends huddled in an
undisclosed location, crying loudly about weapons of mass
destruction. :)

Why? Serving scripts from our own servers (and so being certain of what
will be in them) is hardly arduous.

It certainly would appear an arduous attitude
to jump out the box painting our efforts with such a broad brush.

All the scripts in LAMPjack are delivered from our LAMPjack servers
which makes a certified LAMPjack about as dangerous as a Googlemap.

In order to even develop, submit or use a LAMPjack script,
one has to have a verified account and the appropriate site and
session keys.

The target page would also have to cooperate by requesting
the infrastructure wLAMPjack.js and additionally
requesting specific functionality via class entry
<div class="wPoint_xxxx" /to even load a LAMPjack.

Any potential Ads would be injected in a fashion that precludes
cross domain scripting into the LAMPjack/Subscriber context,
as I agree that totally third party content needs to be caged.
Those third parties could also use LAMPjack, but only from their
own context, so those ads would only pose the same threat
as every other ad we see on the internet.

As to monitoring activities , even *YOUR* site logs every
request, right down to my IP address, so in order to avoid
log files we all need to give up using the internet at all
and/or hunker down in the dark nets and pay for fear by
the month, which still does not really protect anyone, but it sells.

As recent years demonstrate, fear sells well. ( A little Y2K anyone?)
Even 9/11 the horrific thing it was , has been abused
to sell hundred of billions of dollars in goods and services.
"commies" has been traded in for "terrorists" and
the lessons of McCarthyism have been forgotten as
the cost of 100% security is the 100% loss of freedom.

I give someone a news ticker , a googlesearch , perhaps
a membership tool , shopping basket or their local weather, and
suddenly we are talking global doom, so lets all hunker down
lock our doors and live in in abject fear, for the
quest of feeling totally secure.

Would a system not using LAMPjack be 100% secure? No.
The only system that comes close is one that's left in it's
shipping carton and never plugged in.

Even banks get hacked on an all to frequent basis,
so the idea is to make the security stiff enough
to exceed the value of the prize.

With a simple vise , a file , and a key, one can make
a master key for all locks of that type w/o ever seeing
the lock or the legitimate key, and so using your logic set
I could justify eliminating the benefit of doors , because
their locks can be opened by some high school kid

Was/Is security kept in mind? Of course.
Will there be challenges? Most certainly.
Are they insurmountable? Certainly not.

My belief is that cross-domain scripting can in conjunction
with server side tools provide a reasonably safe context
in which to conduct it's activities.

[petermichaux]

drclue wrote:

>
It certainly would appear an arduous attitude
to jump out the box painting our efforts with such a broad brush.

I think it would have been better to introduce LAMPJack with a brief
description of how the technology works overall: your server, my
server, client browser and all the communcation between them. Then
people would have some idea why LAMPJacks are so cool.

Peter

[drclue]

runner7 wrote:

Ok, how do you programmatically send a particular keystroke to Firefox?
I do not mean detect a keystroke.

http://groups.google.com/group/comp....f185f19fb2d0f4

LAMPjack does not add anything that would
enhance ones ability to mimic keystrokes.

On the other hand, LAMPjack could in some cases
be used to route data from one place to another
including a form submission.

Being as the LAMPjack infrastructure counts
transactions/frequencies/sequences and other things,
one would need to get special permission to
do a lot of them otherwise in some cases
the account to might be flagged or disabled
by the infrastructure.

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>drclue wrote:

>>Richard Cornford wrote:
Web site security is largely a matter of exercising and keeping
control where you have control, on your own servers. Letting a
third party inject scripts on the client is sufficiently risky to
make loud assertions of honesty, responsibility and safety
made by the providers of those scripts insufficient justification
for using them.

So let's all ditch our on-line banking , throw out the googlemaps,
turn off our javascript and join our friends huddled in an
undisclosed location, crying loudly about weapons of mass
destruction. :)

Why? Serving scripts from our own servers (and so being certain of
what will be in them) is hardly arduous.

It certainly would appear an arduous attitude
to jump out the box painting our efforts with such
a broad brush.

All I did was point out that in the hands of the unscrupulous a system
that asks sites to include client-side scripts originating on a remote
server could be used to inject arbitrary malicious scripts in a way that
was very difficult to observe, but may be seriously damaging for the
reputation of the web site's owners and the financial well being and
privacy of their users. That is just a fact, what can be done with
scripts injected on the client is anything that can be done by any
script on the page.

All the scripts in LAMPjack are delivered from our
LAMPjack servers which makes a certified LAMPjack
about as dangerous as a Googlemap.

Two things speak for the safety of google maps: 1. Google's reputation
(which you would hope they would not want to endanger), and 2. The
technical competence of google's developers. Given that google has a
long history of tolerating script injection the later is not much of a
reassurance, though as google will not be using Googlemaps to inject
malicious scripts (to preserve their reputation) no injections will be
possible until they start including advertising (and their developers do
appear to finally getting to grips with their script insertion
problems).

In order to even develop, submit or use a LAMPjack
script, one has to have a verified account and the
appropriate site and session keys.

Aren't the people who would be developing the scripts for your system
the ones creating the lures that will encourage the people who have web
sites to use the system? There is little significance in these two
groups having "verified accounts".

The target page would also have to cooperate

Yes, you cannot force alien client side scripts into a page, it has to
invite them in (a bit like vampires).

<snip>

Any potential Ads would be injected in a fashion
that precludes cross domain scripting into the
LAMPjack/Subscriber context,

Details?

as I agree that totally third party content needs
to be caged.

But you promise everyone that your position as a third party would never
be abused?

Those third parties could also use LAMPjack, but only
from their own context, so those ads would only pose
the same threat as every other ad we see on the internet.

As to monitoring activities , even *YOUR* site
logs every request, right down to my IP address,

And if I included a script that did it I could monitor every key stroke
the user made and broadcast it back to my server, speculatively test for
the ability to install software (and install things (read spyware) on
the client if the ability was exposed) and so on. Of course I have no
reason for monitoring password and reading credit card numbers as they,
if entered, are going to be sent to me anyway, but if a third party
could upload those scripts to sites I am responsible for then they may
see considerable value in what they could achieve.

so in order to avoid log files we all need to give
up using the internet at all and/or hunker down in
the dark nets and pay for fear by the month, which
still does not really protect anyone, but it sells.

That is a "slippery slope" argument that doesn't quite work.

<snip>

Would a system not using LAMPjack be 100%
secure? No. The only system that comes close
is one that's left in it's shipping carton and
never plugged in.

Are you saying that if you cannot be 100% secure you may as well be wide
open to anything?

The only system that comes close is one that's left in it's
shipping carton and never plugged in.

Even banks get hacked on an all to frequent basis,
so the idea is to make the security stiff enough
to exceed the value of the prize.

With a simple vise , a file , and a key, one can make
a master key for all locks of that type ...

<snip>

That is not at all true. A lock as simple as the Yale lock, for example,
has no master key at all, so no such object could be created.

My belief is that cross-domain scripting can in
conjunction with server side tools provide a reasonably
safe context in which to conduct it's activities.

Don't be ridicules. Your system is absolutely reliant on the owners of
web sites being willing in include scripts in their pages soured from a
third party server. At that moment client side security is already out
of the window. The only safety these web sites will have come from
exactly the same sources as Googlemap's; Your technical competence (and
you already know what I think of that), and your reputation (which is
not something I would hang a web site upon).

The problem here is that if your intentions were to exploit the gullible
and leach information form the user's of their web sties for your own
financial gain how would what you would then post in order to lure
people into using the system differ from what you have posted here?

Richard.

[drclue]

pe**********@gmail.com wrote:

drclue wrote:

>It certainly would appear an arduous attitude
to jump out the box painting our efforts with such a broad brush.

I think it would have been better to introduce LAMPJack with a brief
description of how the technology works overall: your server, my
server, client browser and all the communcation between them. Then
people would have some idea why LAMPJacks are so cool.

My experience has been that a year's worth of food is best eaten
a bit at a time. I generally don't read nor respond to messages
of the girth that would be required to express the last years
development effort in one meal.

[drclue]

Richard Cornford wrote:

>With a simple vise , a file , and a key, one can make
a master key for all locks of that type ...

<snip>

That is not at all true. A lock as simple as the Yale lock, for example,
has no master key at all, so no such object could be created.

Please feel free to search for "bumpkey" which among other links
should explains the the simple physics involved in making
master keys for almost any lock relying on pin tumblers.

If you like I think that YouTube.com has several fine
educational videos on the subject.

So I will file your latest *it can't be done* claim with your
other comments of similar quality.

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>>With a simple vise , a file , and a key, one can make
a master key for all locks of that type ...

<snip>

That is not at all true. A lock as simple as the Yale lock, for example,
has no master key at all, so no such object could be created.

Please feel free to search for "bumpkey" which among other links
should explains the the simple physics involved in making
master keys for almost any lock relying on pin tumblers.

<snip>

That device is not a master key it is a lock picking tool. I did not
say Yale locks were not easy to pick just that it is not possible to
make a master key for them. But if you need another example, how are
you going to make a master key for a 5 leaver Chubb lock?

Richard.

[drclue]

Richard Cornford wrote:

drclue wrote:

>Richard Cornford wrote:

>>>With a simple vise , a file , and a key, one can make
a master key for all locks of that type ...
<snip>

That is not at all true. A lock as simple as the Yale lock, for example,
has no master key at all, so no such object could be created.

Please feel free to search for "bumpkey" which among other links
should explains the the simple physics involved in making
master keys for almost any lock relying on pin tumblers.

<snip>

That device is not a master key it is a lock picking tool.

The Merriam-Webster Online Dictionary defines a "Master Key"
as "a key designed to open several different locks".
That's exactly what a bumpkey is.

I did not say Yale locks were not easy to pick just that it is not possible to
make a master key for them. But if you need another example, how are
you going to make a master key for a 5 leaver Chubb lock?

The Chubb looks to be a pin cylinder lock as opposed to
a pin tumbler lock. ( different animal ). If your interested
in such things I would direct you to a very entertaining resource
http://www.toool.nl/index-eng.php

The point is that security is more a deterrent than any kind
of guarantee, be it an internet service or your house's own
front door. The size and complexity of the lock or other
security mechanism needs to be inline with the item being protected,
which is why although most bathroom doors have a lock, they
are designed to the level of the prize ( Ones modesty ) in this case.

Likewise the various layers of LAMPjack security are aimed at
the level of the prize they protect, although most would be much
harder to bypass than the average house or businesses front door.

Even your local bank likely uses a plain old lock on the front door
as that guards the prize of the lobby, while a heavier security
is used on the vault where the actual money is.

In the LAMPjack system we defer things like credit card processing
to third parties like PayPal whose specialty is the bank vault side
of things. This allows us to keep the prize level down on LAMPjack
services while at the same time we are always looking for ways
to make LAMPjack security an ever increasing deterrent.

The API supports both sever encrypted site keys,
and sever encrypted session keys that can depending on the level
of deterrent required be unique for each transaction.

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>drclue wrote:

<snip>

>>Please feel free to search for "bumpkey" ...

<snip>

>>
That device is not a master key it is a lock picking tool.

The Merriam-Webster Online Dictionary defines a "Master Key"
as "a key designed to open several different locks".

A lock picking tool is not a key.

That's exactly what a bumpkey is.

It is a device for opening locks of a particular type, that does not, of
itself, make it a key.

>I did not say Yale locks were not easy to pick just that
it is not possible to make a master key for them. But
if you need another example, how are you going to make
a master key for a 5 leaver Chubb lock?

The Chubb looks to be a pin cylinder lock

The 5 leaver Chubb lock is a leaver lock (with 5 leavers, surprisingly
enough). No pins and no cylinders.

... If your interested in such things ...

<snip>

No, my interest does not go beyond testing the veracity of your claim
that "With a simple vise, a file, and a key, one can make a master key
for all locks of that type". As you have now started evading the
question I assume you have realised that it was a false statement, as I
asserted.

The point is that security is more a deterrent than
any kind of guarantee, ...

<snip>

With your proposed system the issues are not keeping people out but
instead the owners of web sites inviting third party scripts in, and
then having the problem of how they are going to police those third
party scripts to ensure that they do not attempt to do anything
malicious to the site's users. Verbal assurances from the source of
those third party scripts are of no value in answering the question as
the dishonest will tell lies to achieve their ends.

Richard.

[drclue]

Richard Cornford wrote:

With your proposed system the issues are not keeping people out but
instead the owners of web sites inviting third party scripts in, and
then having the problem of how they are going to police those third
party scripts to ensure that they do not attempt to do anything
malicious to the site's users. Verbal assurances from the source of
those third party scripts are of no value in answering the question as
the dishonest will tell lies to achieve their ends.

You mean in a fashion similar to your quoting tactics designed to
reverse the meaning of a quote by taking it out of context?

We have a business plan that is based upon providing
users with successful transactions at a
fraction of a penny each or ad exchange , in which
case an advertiser pays the transaction costs.

Each transaction is backed by LAMPjack server logs
which can be audited against the client's and/or
advertisers web logs to assure via a source independent
of LAMPjack , that the transactions are valid and
not "made up".

Each LAMPjack is by nature "open-source" , so you , the client,
the advertiser or anyone else can examine the code to
see if there is any deviousness afoot.

Even the main LAMPjack javascript infrastructure files
are again by their very nature open source.

In a LAMPjack or even LAMPjack infrastructure , there
is really no place to hide a bad deed in the javascript.

This basically leaves the data that flows through
the server side. Ones LAMPjack login , the inputs to
proxy services like the weather, geocoders, stock and
news tickers ,shopping baskets and other while cool
services, not exactly the basis for a scam. At least not one
that could not be achieved far easier via other means and
at far less cost.

For the moment I'll assume your quoting behavior was simply born
of haste. I'm more than willing to have a *productive*
discussion about the general security aspects of LAMPjack
or even gasp the productive things you can do with it, but
the broken record of fear mongering is likely to brand you a troll.

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

<snip>

>... . Verbal assurances from the source of those third
party scripts are of no value in answering the question as
the dishonest will tell lies to achieve their ends.

You mean in a fashion similar to your quoting tactics designed to
reverse the meaning of a quote by taking it out of context?

Others can judge that for themselves.

<snip>

Each LAMPjack is by nature "open-source" , so you , the client,
the advertiser or anyone else can examine the code to
see if there is any deviousness afoot.

Inevitably they can look at the source, but if malicious injections
were kept to lowish percentage of actual request (and not server to
repeated request from the same IP address (within a period of, say, one
day), which is what a site owner may decide to do in order to verify
that there were no intermittent malicious injections, even though they
would be paying for the privilege) then the odds of detection would be
low (as the onus to detect would mostly be on non-technically skilled
browser users).

And there is the question of whether someone who is employing third
party scripts is qualified to identify a malicious script form its
(potentially obfuscated and compacted) source code.

Even the main LAMPjack javascript infrastructure files
are again by their very nature open source.

In a LAMPjack or even LAMPjack infrastructure , there
is really no place to hide a bad deed in the javascript.

Hide from who? If you are the one doing the injecting then you can
insert anything from any hidden/personal source you like.
<snip>

For the moment I'll assume your quoting behavior was
simply born of haste. I'm more than willing to have a
*productive* discussion about the general security
aspects of LAMPjack

No you are not. You want to suggest that everything is safe an above
board but you cannot deal with the problem that you system has the
potential to inject arbitrary scripts into the web pages of any web
site that uses it, and your assurances that it is safe would not differ
if your intentions were dishonest. Indeed your unwillingness to admit
that your system should be regarded as a security issue by its
potential users (the web site owning users), and that they should
expect some sort of verified and underwritten guarantees of your good
intentions (with draconian and enforceable penalty clauses if you
transgress), at minimum, speaks against your trustworthiness. As do
your continued efforts to deflect attention from my comments with
irrelevancies and your resorting to personal comments.

or even gasp the productive things you can do with it, but
the broken record of fear mongering is likely to brand you
a troll.

The potential exists, you don't have Google's reputation (at all, or to
defend) and your assertions that there are no security issues is not
reassuring, and is even suspicious in itself.

Richard.

[drclue]

Richard Cornford wrote:

drclue wrote:

>Richard Cornford wrote:

<snip>

>Each LAMPjack is by nature "open-source" , so you , the client,
the advertiser or anyone else can examine the code to
see if there is any deviousness afoot.

Inevitably they can look at the source, but if malicious injections
were kept to lowish percentage of actual request (and not server to
repeated request from the same IP address (within a period of, say, one
day), which is what a site owner may decide to do in order to verify
that there were no intermittent malicious injections, even though they
would be paying for the privilege) then the odds of detection would be
low (as the onus to detect would mostly be on non-technically skilled
browser users).

Well, hopefully there will be plenty of savvy folks like yourself
to keep us honest. I think it will be important for folks to have
a reliable means to match their logs against our logs in a form that
can be verified by even third party software tools, at least as to
transactional honesty. To fake it enough to make the logs jive in one
way would leave a very loud trail in another way , even if one
spoofed their ass off.

And there is the question of whether someone who is employing third
party scripts is qualified to identify a malicious script form its
(potentially obfuscated and compacted) source code.

While I would agree that most LAMPjack clients would probably
not be savvy enough to read a log, or scrutinize code,
it's sorta like that sign on some of our front doors that says
"Premises protected by Smith & Wesson 3 days a week,
you guess which 3."

How would a LAMPjack know which
four days (sites) a week (log) would not get "Smith & Wesson"
(someone who can read logs)?

All LAMPjacks are uncompressed , formatted for readability
and pretty well documented too, so the Smith and Wesson rule
would come into play here as well.

>

>Even the main LAMPjack javascript infrastructure files
are again by their very nature open source.

In a LAMPjack or even LAMPjack infrastructure , there
is really no place to hide a bad deed in the javascript.

Hide from who? If you are the one doing the injecting then you can
insert anything from any hidden/personal source you like.

Not really , as the "Smith & Wesson" rule still applies.
Code like LAMPjack is bound by it's very nature to attract
view-source, DOM inspectors cache browsers and many other curious
onlookers and one would not get away with it long enough to make
it worthwhile.

The legitimate use of our technologies for even the .005 cent
services can realize over $8500/Week per half occupied machine,
and there are .05 cent jacks and even .50 cent jacks, so
what's the motivation for us to trade that in on something
that is sure to land us in deep shit for a far lessor possible
prize?

<snip>

>For the moment I'll assume your quoting behavior was
simply born of haste. I'm more than willing to have a
*productive* discussion about the general security
aspects of LAMPjack

No you are not. You want to suggest that everything is safe an above
board but you cannot deal with the problem that you system has the
potential to inject arbitrary scripts into the web pages of any web
site that uses it, and your assurances that it is safe would not differ
if your intentions were dishonest.

Then I guess your typing far more than you are reading,
as my intent in these couple of posts is to try and find
something you can hang your hat on that does not
require me to be an honest guy to demonstrate.

It is my opinion that you just whish to be contrary.

Indeed your unwillingness to admit
that your system should be regarded as a security issue by its
potential users (the web site owning users), and that they should
expect some sort of verified and underwritten guarantees of your good
intentions (with draconian and enforceable penalty clauses if you
transgress), at minimum, speaks against your trustworthiness. As do
your continued efforts to deflect attention from my comments with
irrelevancies and your resorting to personal comments.

I don't think you could that much more personal in the line of comments
than continuously implying that our hard work is nothing but a scam.

>or even gasp the productive things you can do with it, but
the broken record of fear mongering is likely to brand you
a troll.

The potential exists, you don't have Google's reputation (at all, or to
defend) and your assertions that there are no security issues is not
reassuring, and is even suspicious in itself.

I never said there are no security issues. Matter-o-fact at least one of
my responses to you included the fallowing

--drclue wrote: earlier in this thread
--Was/Is security kept in mind? Of course.
--Will there be challenges? Most certainly.
--Are they insurmountable? Certainly not.

I try to answer your questions but you seem to be typing more
than reading. Fixated on the idea that there is some scam afoot
that would be more worthwhile than the business model.

Sure I could inject a zillion malicious scripts, but riddle me this

1.) What possible prize is worth more than the business model?
2.) With everyone peeking at the scripts to figure out how
to build their own LAMPjack system , how would I get away with it?
3.) How does this scam happy logic set actually validate?

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>drclue wrote:

>>Richard Cornford wrote:

<snip>

>>Each LAMPjack is by nature "open-source" , so you , the
client, the advertiser or anyone else can examine the
code to see if there is any deviousness afoot.

Inevitably they can look at the source, but if malicious
injections were kept to lowish percentage of actual
request (and not server to repeated request from the
same IP address (within a period of, say, one day),
which is what a site owner may decide to do in order to
verify that there were no intermittent malicious injections,
even though they would be paying for the privilege) then
the odds of detection would be low (as the onus to detect
would mostly be on non-technically skilled browser users).

Well, hopefully there will be plenty of savvy folks
like yourself to keep us honest.

Where is the "keep"? And how could I "keep you honest"? I have no
ability to monitor thousands of consecutive requests form differing IP
addresses, and less willingness to do so.

I think it will be important for folks to have
a reliable means to match their logs against our logs
in a form that can be verified by even third party
software tools, at least as to transactional honesty.

That is fine for billing questions, it does not address the question of
potential malicious script insertions.

To fake it enough to make the logs jive in one
way would leave a very loud trail in another way ,
even if one spoofed their ass off.

>And there is the question of whether someone who is
employing third party scripts is qualified to identify
a malicious script form its (potentially obfuscated and
compacted) source code.

While I would agree that most LAMPjack clients would
probably not be savvy enough to read a log,

Reading logs is irrelevant, as they will not show what was actually
delivered (and even if they did could they be trusted to show the real
delivered script or just the scripts asked for.)

or scrutinize code,

No they probably will not be able to do that effectively.

it's sorta like that sign on some of our front doors
that says "Premises protected by Smith & Wesson 3 days
a week, you guess which 3."

That seems irrelevant to me.

How would a LAMPjack know which four days (sites) a week
(log) would not get "Smith & Wesson" (someone who can
read logs)?

What have logs (and who's logs) got to do with it.

All LAMPjacks are uncompressed , formatted for
readability and pretty well documented too, so
the Smith and Wesson rule would come into play
here as well.

What has that got to do with anything?

>Even the main LAMPjack javascript infrastructure files

>>are again by their very nature open source.

In a LAMPjack or even LAMPjack infrastructure , there
is really no place to hide a bad deed in the javascript.

Hide from who? If you are the one doing the injecting
then you can insert anything from any hidden/personal
source you like.

Not really ,

Yes really. Your system is designed to be the source of scripts from a
third party server, you control the server and wrote the server-side
code, you can do precisely what you like in terms of what gets sent to
the web page.

as the "Smith & Wesson" rule still applies.

In what way?

Code like LAMPjack is bound by it's very nature to
attract view-source, DOM inspectors cache browsers
and many other curious onlookers and one would not
get away with it long enough to make it worthwhile.

As the majority of web site visitors will not be doing any of those
things and only some of the people doing thing like viewing the source
will be able to work out what they are looking at/for, a relatively low
percentage of injections would leave most observers not seeing them. You
could get away with it for quite some time, and probably get away with
denying that anything was happening or making up excused for a couple of
years even if caught in the act.

The legitimate use of our technologies for even
the .005 cent services can realize over $8500/Week
per half occupied machine, and there are .05 cent
jacks and even .50 cent jacks, so what's the motivation
for us to trade that in on something that is sure to
land us in deep shit for a far lessor possible prize?

You mean why should you try for two or three types of income from the
system when you can have one?

><snip>

>>For the moment I'll assume your quoting behavior was
simply born of haste. I'm more than willing to have a
*productive* discussion about the general security
aspects of LAMPjack

No you are not. You want to suggest that everything is
safe an above board but you cannot deal with the problem
that you system has the potential to inject arbitrary
scripts into the web pages of any web site that uses it,
and your assurances that it is safe would not differ if
your intentions were dishonest.

Then I guess your typing far more than you are reading,
as my intent in these couple of posts is to try and find
something you can hang your hat on that does not
require me to be an honest guy to demonstrate.

Whatever your intent denying that your system is inherently capable of
injecting malicious scripts is suspicions because it clearly is. Talking
about logs, verified accounts, open source and user's viewing the code
delivered does not alter that, or represent any guarantee that no
malicious insertions will be made, indeed raising those issues may be
seen as an attempt to distract attention from the real issue.

It is my opinion that you just whish to be contrary.

Or you would like others to think that, as that would also distract them
from the real issue.

>Indeed your unwillingness to admit that your system
should be regarded as a security issue by its potential
users ... .

I don't think you could that much more personal in the
line of comments than continuously implying that our
hard work is nothing but a scam.

But your system could be nothing but a scam. That is the problem. If it
were a scam you would be expected to deny it (because scams don't work
if you admit that they are scams). The potential certainly is there in
the system you describe, and something promoted with hype rather than
technical detail is more a symptom of a scam than it is of a anything
else.

>>or even gasp the productive things you can do with it, but
the broken record of fear mongering is likely to brand you
a troll.

The potential exists, you don't have Google's reputation
(at all, or to defend) and your assertions that there are
no security issues is not reassuring, and is even
suspicious in itself.

I never said there are no security issues.

You have spent considerable effort suggesting that they were not
significant.

Matter-o-fact at least one
of my responses to you included the fallowing

--drclue wrote: earlier in this thread
--Was/Is security kept in mind? Of course.
--Will there be challenges? Most certainly.
--Are they insurmountable? Certainly not.

The last line implies that the web site owners using the system don't
have to worry about it, but does not mean anything of the sort.

I try to answer your questions but you seem to be
typing more than reading.

You did not answer the question: if you were dissonant how would your
posts differ from what you have posted?

Fixated on the idea that there is some scam afoot
that would be more worthwhile than the business model.

Sure I could inject a zillion malicious scripts,

Absolutely, and do so in a way that has very hard to observer or pin
down to you as a source.

but riddle me this

1.) What possible prize is worth more than the
business model?

What is the business model? What if it is to maximize return from a
venture intended to be inexpensive (you get others to provide the lure
scripts) and short lived,

2.) With everyone peeking at the scripts to figure
out how to build their own LAMPjack system , how
would I get away with it?

The people looking at the scripts to see how they could make their own
malicious script insertion system are unlikely to say anything about
malicious scripts they find, if they were lucky enough to be looking at
the moment one was sent.

3.) How does this scam happy logic set actually
validate?

If I read hype and zero substance, connected to a system that is
inherently dangerous, followed by attempts to direct attention away from
the fact that it is inherently dangerous then suspecting a scam is
reasonable. It is not as if scams do not exist.

It is best to forget the hype and examine the idea on its merits. The
potential it has for abuse is considerable, so what will prevent that
abuse. Where Googlemaps is concerned google's reputation is the
"guarantee" that they will not do anything malicious. You don't have
anything outside LAMPjack to hang on its credibility, and have no
reputation of your own to defend. So the web site owners who are
expected to use this system need some other sort of guarantees about the
system never being abused, and your words cannot provide them as if you
are dishonest you will not be telling the truth.

Richard.

[Dr John Stockton]

JRS: In article <11**********************@e63g2000cwd.googlegroups .com>,
dated Wed, 13 Sep 2006 02:58:52 remote, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.ukposted :

>That device is not a master key it is a lock picking tool. I did not
say Yale locks were not easy to pick just that it is not possible to
make a master key for them.

It is perfectly possible to design a set of Yale-type locks with a
master-key, such that for example locks 0..9 can only be opened by keys
0..9 respectively, but all can be opened by master-key X.

Even with access to all keys 0..9, it is not possible to deduce the
shape needed to be cut for master-key X - although if the set 0..9 is
badly-designed, a part of the cut of a master-key could be deduced.

It is obviously impossible to make a master-key for all Yale-type locks,
because the cross-sections of the keys differ.

--
© John Stockton, Surrey, UK. *@merlyn.demon.co.uk / ??*********@physics.org ©
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SoRFC1036)

[drclue]

Dr John Stockton wrote:

JRS: In article <11**********************@e63g2000cwd.googlegroups .com>,
dated Wed, 13 Sep 2006 02:58:52 remote, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.ukposted :

>That device is not a master key it is a lock picking tool. I did not
say Yale locks were not easy to pick just that it is not possible to
make a master key for them.

It is perfectly possible to design a set of Yale-type locks with a
master-key, such that for example locks 0..9 can only be opened by keys
0..9 respectively, but all can be opened by master-key X.

Even with access to all keys 0..9, it is not possible to deduce the
shape needed to be cut for master-key X - although if the set 0..9 is
badly-designed, a part of the cut of a master-key could be deduced.

It is obviously impossible to make a master-key for all Yale-type locks,
because the cross-sections of the keys differ.

Not for all Yale-type locks , but rather for all pin tumbler
locks of a particular type (key way), so you would need
to fashion a key for each Yale key way type you wanted to
support.

AFAIK , one sets all the cuts to "9", then after cutting
remove .25-.5 millimeters from both the shoulder and the tip of the
key, such that when the key is inserted fully into the key way
that the force of the pin springs pressing the pins against the now
slightly miss aligned valley walls provides a right angle force
that pushes the key back out about .25-.5 millimeters.

At this point you now have your master key.
It's use is fairly simple , sorta like a combination shot in pool

Give the the cue (key) a light but sharp inward stroke.

The walls of the valleys will bank shot the force to the lower pins
but like in pool the first struck ball (lower pin) will hit the
second ball (upper pin) causing all the motion of the first ball to
transfer to the second while stopping the first ball dead in it's
tracks. While the pins are in the air , turn the key as normal
and your done.

[Richard Cornford]

drclue wrote:
<snip>

>Richard Cornford posted :

>>That device is not a master key it is a lock
picking tool.

<snip>

At this point you now have your master key.
It's use is fairly simple , ...

Give the the cue (key) a light but sharp inward stroke.

<snip>

... . While the pins are in the air , turn the key
as normal and your done.

A master key would be operated in the same way as any other key for the
type of lock. These are not keys they are lock picking tools.

Richard.

[Richard Cornford]

Dr John Stockton wrote:

Richard Cornford posted :

>>That device is not a master key it is a lock picking tool. I did not
say Yale locks were not easy to pick just that it is not possible to
make a master key for them.

It is perfectly possible to design a set of Yale-type
locks with a master-key, such that for example locks
0..9 can only be opened by keys 0..9 respectively,
but all can be opened by master-key X.

Re-designing a Yale lock so that it was possible to make a master key is
irrelevant to whether it is possible to create a master keys for the
existing design of Yale type locks.

Even with access to all keys 0..9, it is not possible to
deduce the shape needed to be cut for master-key X -
although if the set 0..9 is badly-designed, a part of the
cut of a master-key could be deduced.

The master key could be deduced by examining the internal structure of
an example lock.

It is obviously impossible to make a master-key for all
Yale-type locks, because the cross-sections of the keys
differ.

The impossibility of opening an existing Yale type lock in the normal
way with the pins in more than one position makes creating a master key
for the existing design impossible, differing cross sections just
mitigate for the fact that Yale locks don't have that many permutations
of keys.

Richard.

[drclue]

Richard Cornford wrote:

drclue wrote:
<snip>

>>Richard Cornford posted :

That device is not a master key it is a lock
picking tool.

<snip>

>At this point you now have your master key.
It's use is fairly simple , ...

Give the the cue (key) a light but sharp inward stroke.

<snip>

>... . While the pins are in the air , turn the key
as normal and your done.

A master key would be operated in the same way as any other key for the
type of lock. These are not keys they are lock picking tools.

Richard , you are welcome to call these keys anything you want :).
I'll stick with the definition contained in the
Merriam Webster dictionary.

Main Entry : master key
Function : noun
Definition : A key designed to open several different locks

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>drclue wrote:
<snip>

>>>Richard Cornford posted :
That device is not a master key it is a lock
picking tool.

<snip>

>>At this point you now have your master key.
It's use is fairly simple , ...

Give the the cue (key) a light but sharp inward stroke.

<snip>

>>... . While the pins are in the air , turn the key
as normal and your done.

A master key would be operated in the same way as any
other key for the type of lock. These are not keys they
are lock picking tools.

Richard , you are welcome to call these keys anything you
want :).
I'll stick with the definition contained in the
Merriam Webster dictionary.

Main Entry : master key
Function : noun
Definition : A key designed to open several different locks

Have you seen those specially designed battering rams that the police
use to open locked doors when raiding buildings? That is "designed to
open several different locks", but it is not operated in the same way as
a key. You (and Webster) may call it a key, but I would maintain that a
master key for a Yale lock would be operated by putting it in the lock,
turning it and nothing else, just like any other key for the lock.

Richard.

[drclue]

Richard Cornford wrote:

drclue wrote:

>Richard Cornford wrote:

<snip>

>>A master key would be operated in the same way as any
other key for the type of lock. These are not keys they
are lock picking tools.

Richard , you are welcome to call these keys anything you
want :).
I'll stick with the definition contained in the
Merriam Webster dictionary.

Main Entry : master key
Function : noun
Definition : A key designed to open several different locks

Have you seen those specially designed battering rams that the police
use to open locked doors when raiding buildings? That is "designed to
open several different locks", but it is not operated in the same way as
a key. You (and Webster) may call it a key, but I would maintain that a
master key for a Yale lock would be operated by putting it in the lock,
turning it and nothing else, just like any other key for the lock.

So you've seen a battering ram , cut from a key blank
on a key machine and inserted into a key way to open a lock? Wow!

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

drclue wrote:

<snip>

Main Entry : master key
Function : noun
Definition : A key designed to open several different locks

Have you seen those specially designed battering rams that the police
use to open locked doors when raiding buildings? That is "designed to
open several different locks", but it is not operated in the same way as
a key. You (and Webster) may call it a key, but I would maintain that a
master key for a Yale lock would be operated by putting it in the lock,
turning it and nothing else, just like any other key for the lock.

So you've seen a battering ram , cut from a key blank
on a key machine and inserted into a key way to open a lock? Wow!

Your definition of a master key does not require the device to be made
from a key, how it is made or how it is operated. I would insist that a
master key be operated just like any other key for a lock, but your
suggested lock-picking device needs to be tapped into the lock to pop
the pins up, and then turned at the correct moment (before the pins
come down again). That is not operating like a key for the lock, it is
operating it like a lock pick.

Richard.

[drclue]

Richard Cornford wrote:

drclue wrote:

>Richard Cornford wrote:

>>drclue wrote:

<snip>

>>>Main Entry : master key
Function : noun
Definition : A key designed to open several different locks
Have you seen those specially designed battering rams that the police
use to open locked doors when raiding buildings? That is "designed to
open several different locks", but it is not operated in the same way as
a key. You (and Webster) may call it a key, but I would maintain that a
master key for a Yale lock would be operated by putting it in the lock,
turning it and nothing else, just like any other key for the lock.

So you've seen a battering ram , cut from a key blank
on a key machine and inserted into a key way to open a lock? Wow!

Your definition of a master key does not require the device to be made
from a key, how it is made or how it is operated.

Main Entry : master key
Function : noun
Definition : A *key* designed to open several different locks.

So I guess my definition *does* indeed require it to be a key.

I would insist that a
master key be operated just like any other key for a lock, but your
suggested lock-picking device needs to be tapped into the lock to pop
the pins up, and then turned at the correct moment (before the pins
come down again). That is not operating like a key for the lock, it is
operating it like a lock pick.

Take it up with Merriam Websters Dictionary,
maybe they will rewrite the definition of a
master key just for you.

[Richard Cornford]

drclue wrote:

Richard Cornford wrote:

>drclue wrote:

<snip>

>>So you've seen a battering ram , cut from a key
blank on a key machine and inserted into a key

way to open a lock? Wow!

Your definition of a master key does not require the
device to be made from a key, how it is made or how
it is operated.

Main Entry : master key
Function : noun
Definition : A *key* designed to open several different
locks.

So I guess my definition *does* indeed require it to be
a key.

<snip>

Wouldn't that depend entirely on how Webster defines "key"? The
dictionaries I have define a "key" as "a device for opening and closing
locks" and "a device for operating locks" respectively, and then go on
to discuss notions of inserting and rotating in order to accommodate
things like the keys for winding up clocks and opening cans.

Richard.