Post by J. FrancisPost by CanopyCoPost by J. FrancisI think that we are talking about two different things when we say "bug".
Your perception of the term "bug" is every bit as broken as your
perceptions of what it means to write consumer software. I'm not trying
to be a prick either, it's just a fact. Sorry.
Just using the definition that was taught to me by my COBOL instructor
back in the 80's.
Back in the 80's what you described was in fact the bulk of what COBOL
programmers would have encountered as "bugs". Dennis Ritchie and his
followers would have had a completely different view of things, even
then. A quarter of a century later and a lifetime of programming paradigms
away, the examples have expanded to include a considerable number of more
"modern" mishaps.
The fact that your perceptions have been broken by time doesn't make them
any less broken. Any unintended behavior in any sort of code (or even most
hardware and firmware for that matter) can be described as a "bug". A
vulnerability is, in general terms, a type of bug that facilitates some
sort of undesirable or unplanned control over a system.
It appears your communication skills are as broken as my using 80's
definitions when talking to a 06 person. ;-)
I get the bases of our communication problem now.
For me, now and always, when I say "bug" I mean that it was a coding
error.
When I say "vulnerability", I mean that it is capable of being forked
up by some jackass doing something that they were not supposed to just
trying to fork things up. That can be anything from dumping coffee down
the vent to writing malware.
Were on the same page now.
Sorry for my part in us not getting there sooner.
I can easily see where vulnerabilities would be difficult if not
impossible to totally do away with.
Microsoft's coding errors, other wise known as random features, however
are an entirely different matter.
And that is what started my thoughts down the trail that I tool.
Post by J. FrancisPost by CanopyCoPost by J. FrancisWindows 95 never "locked up while sitting there". No operating system
will execute any function at rest, and if nothing is being done it will
not change states from "sitting there" to "locked up". Those
unexplained lockups have definable causes. They're errors in some
process that you simply aren't aware of.
Those errors are obvious.
One of them is that the PC will not take any inputs at all. And those
Yes, and that sort of behavior isn't the result of an operating system
that locks up "just sitting there". It may *appear* to you to be doing
nothing, but behind the scenes it's still processing data, lighting those
pixels you're so fond of, allocating and deallocating memory, ticking
off time, writing/reading storage space and memory locations, etc...
etc... etc...
Actually, I did not think that "it" was doing nothing.
I know, for example, that it has to refresh the screen, and check for
inputs, and do other chores, so it is doing something.
Just not what it was supposed to be doing, otherwise I could have used
the PC instead of being forced to reboot it.
It was just doing nothing that I had told it to do.
It was not running anything extra (beyond the operating system) that
could have locked it up.
I was not clicking a million icons a second, or trying to open 50
documents at once.
It was just setting there minding its own business.
Post by J. FrancisIronically enough, most unexplained "lockups when the computer's just
sitting there" can be attributed to graphics/GDI problems. Yes, that
simple "lighting of pixels". It's one of the most bug prone facets of
modern PC's. Those lockups that can't be traced to display issues are most
frequently hardware and "heat" problems.
Well, the PC locked up running win 95, but that same PC did not lock up
running Win 3.11 and DOS 6.22, so that sounds like a coding error to
me.
The fact that they made an error in coding the display portion of there
software is interesting, but did not install any more faith in
Microsoft's ability to sell me a product that actually did what it was
paid to do.
And as to heat problems, we ran into them too.
But that is not what I am talking about here.
These were totally software related problems.
Even if it was that the software would not run on our commonly used
chips, it is still a software problem, considering that Microsoft
refused to sell us the operating system that he already had and forced
us to buy one that commonly locked up.
Post by J. FrancisPost by CanopyCoerrors were due to the software writer not doing his job correctly and
getting all of what I call bugs out of his software. They were not due
An impossible goal. The concept of completely bug free code is a pipe
dream. Wishful thinking. It's simply not humanly or physically possible
given any significant piece of programming. And if you would happen to
come close, the display drivers on one machine running your code could
walk all over it, and on another it might encounter an odd BIOS
incompatibility because it's so "rigid" it can't deal with some screwy
environment issue that translates drive geometry in one of the 10 billion
ways you didn't think of.
Apparently, you have already forgot what I call a bug.
Remember, bug is coding errors.
Coders cannot go back and fix there typos?
Cannot fix there math?
Cannot fix the improper use of code when doing a job?
We are not talking about vulnerabilities here.
Post by J. FrancisPost by CanopyCoto viruses, or any other software running on the PC. They were inherent
in the Win 95 edition 1 software. I know this from tests that I ran
using various PC that did nothing but set there with nothing on them
that did not come on the Win 95 disk.
That's completely irrelevant. That certain versions of a software have
their own "quirks" is given. What you're failing to understand is that
those problem have causes, and those causes are usually called... bugs.
You must work for Microsoft, or are one of the type of computer people
that are giving computer people a bad name.
Microsoft changed something, and now it does not work.
And that is not there fault?
They are called coding errors when the new version has them and the old
one does not.
They changed something, and now it did not work.
That is a coding error, introduced with the change.
You could call them an introduced vulnerability, but that would make
them no more desirable then calling them coding errors.
And they would be able to fix them by simply coding that portion the
same way they did it the last time, instead of changing it so that it
now had problems.
If it is not broken, and is working just fine, then don't fix it, and
obviously don't break it.
Post by J. FrancisPost by CanopyCoPost by J. FrancisAgain your drastically over simplified view of reality has lead you to
a completely erroneous presumption.
Ok, look here, "lock up", to anyone but you, means that when I push a
button or move the mouse, nothing happens. No matter how long I wate, or
what buttens I push, I can not get any use out of my PC untill I reboot
it.
That's the effect, not the cause. That's what you see, not what made it
happen.
What made it happen is that I quit using an operating system that
worked, called Win 3.1 and DOS 6.22, and started using an operating
system that had coding errors in it called Win 95 edition 1.
Post by J. FrancisPost by CanopyCoAnd win 95 edition 1 did lock up quite regulairly. I was selling PC at
that time, and sold quite a few coppies of win 3.11 and DOS 6.22 becouse
they came back complaining about just exactly that.
I remember the era well myself. Doing the exact same thing. Downgrading an
entire law firm in fact, after their "experiment" with early versions of
95 caused them so many problems.
What can I say... I tried to warn them off being on the bleeding edge but
Boss Suit was a self proclaimed technophile. The invoice reflected my
dissatisfaction with his denial that I knew best, as well the weekend it
took me to rebuild all their workstations behind his self imposed
"upgrade". Fortunately, God and I favored them by having designed their
network around NT servers, centralized data storage, and overly
cautious backup routines. ;-)
We are on the same page there.
When Win 95 came out, I could not imagine that a company could legally
get away with selling something that was clearly faulty and not get
sued for the damage it caused.
That is when Microsoft came out with there fancy contract that made
them not responsible for anything that they did.
My costumers had the same problem that I did at first.
They could not believe that such a big company would intentionally sell
a product that would create so much ill will toward it. :-/
Post by J. FrancisPost by CanopyCoIf you do not know what "locked up" means, then your abilities are
definitly is question.
I'll match my ability and experience against yours ANY day.
In programing or tech support?
You may be a programing God, but your communication abilities to the
common man is not God like. ;-)
Post by J. FrancisPost by CanopyCoYou ever do any customer support?
Geee lemme think.... I designed and built the county wide library network
in my home state, built and sold the hardware and maintained the network
at the local courthouse law library and Judge's chambers, built/supported
a considerable amount of hardware for three area hospitals, Built and
administered the network for a moderate sized international law firm,
built and administered the network for a large medical support group
comprised of about a dozen area physicians and their staff, built,
supported, and trained all the employees in the use of the new equipment
and software at a printing house that produced a bi-weekly "shiny sheet"
type newspaper (among other things), built and supported standalone
machines and small "networks" to probably thousands of people and
businesses over the course of the almost two decades I was in that
business, sold my services as nothing *but* a trainer and consultant to
many hundreds more, and even built some of the equipment and consulted on
my home town's first public ISP, then sold accounts and supported it from
the storefront I worked.
Support? *laugh* I could solve problems over the phone in my head by
visualizing the Windows menus and configuration screens while was
troubleshooting a CAD machine for a local machine shop and hammering
together a new machine for the hospital. Which at one time I could do in
less than 9 minutes from a pile of parts to an assembled box happily
accepting its operating system. :)
I spent 8 years coding 65c02 ASM language for embedded medical equipment
applications, where code quality was absolutely critical and examined by
government auditors on a regular basis. I coded a couple rather less than
significant utilities for BBS SysOps in C ages ago, and wrote a couple
"Door" games that became quite popular on the select BBS's I donated them
to. In fact my first experience with "grownup" coding issues inherited
from others was with the TriDoor library. I've designed and built a number
of significant commercial web sites from the ground up, including a custom
shopping cart written from scratch with a PHP front end and a back end in
Python (I love Python). I have (checking...) 17,921 lines of custom code
on this machine alone that I'm using or have used just as "problem
solving" crap for my own purposes, and I'm currently involved in a
collective coding project relating to, imagine this... computer security
and user privacy.
And that's just the fraction of my more or less professional experience I
recalled off the top of my head for your benefit. My resume is
considerably more impressive than that. On the civilian side I also ran a
BBS for a good number of years and dealt with all those questions. I
hosted/ran one computer user group and participated as a "guru" in
another. Presently I'm semi-retired building and selling Linux boxes
basically at cost to retirees and shut-ins in my area, and training them
on how to use their nicely customized, secure, and stable machines to see
those pictures of the grandkids.
IOW, I'm that "computer guy" with the brain everyone always wants to
pick, and it's been that way for a very, very long time...
Wow!
All that experience, and you still not only cannot communicate with me
well, but are constantly incapable of recognizing the experience that I
have in the field.
You must be getting rusty in the field of talking to those that are not
computer gods. ;-)
Post by J. FrancisPost by CanopyCoIf so, how, when you do not know what "locked up" means?
I know exactly what you're talking about. You're confused about why they
happen. I'm anything but.
Nonsense, I know exactly where the problem lies.
It lies in the programer changing something in the operating system,
form a method that worked to one that did not.
Post by J. FrancisPost by CanopyCoPost by J. Francisalso when I write a peace of software that is designed to put out a
report doing math, and the report shows incorrect math.
I thought you claimed you *never* made a mistake...?
Oooops... :)
I clamed that I never let a peace of software get to the costumer phase
with a mistake in it.
That you're aware of or will admit to anyway. ;)
I don't give customers software that is not fully tested and working
properly.
And yes, I do check back to see if there is even anything that they
would just like changed, even though it is working just fine as it is.
Like maybe screen 3 and screen 5 combined instead of separate.
Or the order of data entry questions, or anything at all that they
noticed that they would like changed.
I am not Microsoft. :-)
Post by J. FrancisPost by CanopyCoI never clamed that everything I wrote compiled correctly the first
Compiling without errors and running perfectly under every condition in
every scenario are two completely different animals.
And our difference in word use is why you were not aware that I was
talking about zebras, and you were talking about black and white
horses.
Post by J. FrancisTo be brutally
honest, the sort of programming you're talking about is so limited in
scope that the chances of you making less than obvious mistakes were nil.
:-p
Go suck a hard boiled pickled egg.
:-)
I consider the PC locking up while just setting there to be a pretty
obvious mistake.
And yet big shot programers like Microsoft could not catch that before
it hit the market.
Eh, I do what I can, and I take pride in my work.
Too bad that there are so many computer people out there now days like
Microsoft that don't.
And no, I am not saying that you are one.
After all, I have never ran any of your software, so I have no idea
what quality of work you put out to market.
Post by J. FrancisStill, I'm surprised that you weren't aware of, and use to working around
the bugs that I remember popping up from time to time in various COBOL
compilers.
Never ran into any.
But then, as you said, I was a data processor and report generator.
Furnishing the local businesses with the type of software that the
majority of business use every day.
Like video stores, so that they can keep track of there inventory and
customers.
Or nursing homes and disabled work shops, so that they can keep track
of there clients and print out the government reports without a bunch
of hassle.
Or ware houses so that they can keep track of inventory, shipping, and
receiving with ease.
It isn't as flashy as writing operating systems, but it was what was
needed by the common man who was being screwed over by the flashy
writers.
Post by J. FrancisPost by CanopyCotime. I also said that I kept at a peace of software until I got it
right, instead of selling it and claiming that it was impossible to fix
it.
You're being obtuse and childish again. I never said it was impossible to
fix an error, I said errors would occur. And that outside the realm of
trivial coding tasks it's humanly impossible to account for every
eventuality or scenario.
Not being obtuse.
Just demonstrating that previously noticed difference in word usage.
Remember?
Bug (when used by my) means coding error, not vulnerability.
And coding errors can be fixed, but not all vulnerabilities can be
addressed or even thought of before finding them in the users world.
Post by J. FrancisPost by CanopyCoPost by J. FrancisFact is, I restrained myself considerably because I believe that YOU
believe you're trying to solve some debate.
Basically, yes, I am trying to understand how things have changed from
the 80's when I wrote software to now, in such a manner that it is now
impossible to make things as dependable as they once were.
Nothing has changed. And after the wash out your perceptions were as
incorrect then as they are now. The only thing that's really changed is
the sheer size of the problem.
Post by CanopyCoYour inability to teach is in no way an indication of my inability to
learn.
Abilities have zero to do with it, you're aggressively fighting the
lesson... *shrug*
That can be just as much a problem with the teacher as it can be the
student.
Post by J. FrancisPost by CanopyCoYou simply have no intention of teaching. Just insulting.
I'm just stating facts. You apparently have absolutely no interest in even
the things that common sense should tell you without any help for anyone
at all. The "pixels on a screen" idiocy is a prime example. I've explained
to you now a couple times that it's a tad more involved than that, but you
keep singing the same old song like you never read a word of it.
Your missing my point.
If I can do a job in a simple way, then why make it more complicated?
But apparently, there is a need for the increased complication.
I don't know if there is or not.
And I can't count on you to say if there is or not either, sense you
obviously have a love for things being complicated.
Where I have a love for keeping things as simple as possible and still
get the job done.
It's a difference in how one looks at things.
I would use DOS and a simple BASIC or COBOL program for a local video
rental store.
You would use Win XP and Visual BASIC, and have to deal with all the
limitations and problems that came with the more complicated stuff.
But this is all off topic, really, sense what I was originally trying
to talk about is a simple chip reader. :-/
You're
Post by J. Francisactively avoiding even trying to learn anything from where I sit.
Combatively discarding what you dislike, and parroting your thread bare
misconceptions in spite of the compelling evidence that's right in front
of your face.
And you are ignoring the concept that there is no reason to make a
simple job complicated.
The fact that someone else has made a simple job complicated is no
indication that it could not have been done simply.
<Sniped a bunch of babble where what I was saying is not even remotely
what you were hearing>
Post by J. FrancisAbsolutely not.
First of all, we're not talking about a "JPG editor", we're talking about
myriads of programs that handle even more types of graphics files.
Not talking about a JPG editor?
Why the hell not?
I am talking about a JPG editor.
Why aren't you?
Just what part of JPG editor did you think mente myriad's of other
programs?
Maybe if you would just stay on the subject we could communicate
better.
Your throwing a fit and getting frustrated because you keep changing
the subject and I don't?
Post by J. FrancisSecond, the exact bug we were talking about earlier had nothing to do
with any specific "JPG editor", it was a flaw in what essentially boils
down to the operating system, that was "inherited" by various other
programs like web browsers, spread sheets, word processors, and yes...
even "JPG editors".
There we go.
Communication at last.
The problem was not with the editor, but the operating system that it
ran on.
I can understand that.
After all, Microsoft is full of things like that.
Vulnerabilities that get taken advantage of.
And no JPG editor writer can change that.
Because the problem is not in the editor, it is in the operating
system.
Why didn't you just say that in the first place?
See how simple that it?
No need to drag all that other crap into the subject.
Obviously no need to discuses the problems of myriad's of other
programs.
Post by J. FrancisThird, there is by no wild stretch of the imagination what you could call
even a small number of bugs that have been discovered in programs that, in
essence, only manipulate pretty pictures. They can generally be classified
into a small number of general types, but the individual bugs probably
number in the many thousands if you travel back through history. Some
are severe, some are minor, they all have their roots in some fairly basic
and undeniable principles, and they're all as different as the individual
coder who wrote them and the unpredictable machines that run said code.
I take it that you are talking about vulnerabilities again, not coding
errors?
In order to properly determine where the problem lies, one must make a
distinction between the two.
Post by J. FrancisPost by CanopyCoPost by J. FrancisOh, and by the way, several methods for including unwanted or
clandestine information within bar codes have already been developed
and implemented. And bar codes have been exploited for nefarious
purposes. So it's not completely beyond the stretches of imagination
that malware could be encoded in bar sequences. If a suitable bug in
the firmware running the bar code readers is discovered, anything is
possible.
[...]
Post by CanopyCoWhat are they doing, using a serial or parallel port to access the input
form the bar code readers now days instead of the reader having its own
memory chip?
What "memory chip"? You're reading information, and you have to do
something with it. That by *definition* means processor and at least
firmware. Whether it resides in the reader or externally is irrelevant. If
you're scrubbing data in the reader there's a processor there. If not,
it's passing the "whatever" it's reading.
Typically the wand itself is a "dumb" device that interfaces to a
terminal. The "cash register". That cash register runs <gasp> Point of
Sale software. That device in turn is almost always wired to some sort of
inventory control infrastructure back behind the swinging doors beside the
customer restrooms... or maybe even in a different state.
You didn't answer my question.
Is the information going directly to the computer and its operating
system?
Or did it pas threw its own storage system that would automatically
truncate it down to the proper size?
If it did not, it should, for that will solve this entire problem.
Once it is formatted to the proper size, and sent as a number, and
handled as a number, then there is no way for malware to do anything.
Just as when you type a number into a calculator, then connect the LED
output to an input for a spread sheet.
No matter what you hit on that calculators keyboard, it will just be
numbers.
And the spread sheet can except all those numbers, and will just do
math with them.
Post by J. FrancisPost by CanopyCoPost by J. FrancisMemory in a "digital" machine is allocated and accessed in segments.
It's a hardware limitation, impossible to circumvent completely. For
that matter, even completely analog processes have bounds and limits
that can be breached. It's really a limitation of the physical world,
in a sorta Zen-like way.
Exactly that limitation is what I am looking at. The input from the bar
code reader comes from the reader. It likely comes in as a parallel
input, sense the bar code is read as a single line.
Those readers are almost always serial devices in my experience, but
my experience is trivial and it's completely irrelevant in any case. The
shape of the data isn't important, the variability is.
Serial is even better.
The memory chip in TTL is loaded from one end with a 1 or 0, and that 1
or 0 is clocked to the next location as the new 1 or 0 is loaded.
Once the clock hits 8 ticks, it quits.
After all, the chip only has 8 locations for a 1 or 0 to be stored.
After that, it is sent to the PC for the software to use as a number.
No buffer over run possible, sense it will never receive anything but a
group of 8 1's and 0's.
If it is not done that way, then someone with a little knowledge of
hardware can make a simple "filter" that would totally do away with any
chance of malware entering the system threw the scanners.
Post by J. FrancisPost by CanopyCoFrom a RFID chip it would likely come in as a serial input.
No, actually it's a pulse modulated signal with data being read off the
trailing edge of the pulses. A series of signals are generated and the tag
"echos" in a certain way depending on what data it holds.
It isn't the old handshake type of thing?
Where the reader sends a "send me the data" signal, then the chip sends
a "here it comes" signal, followed by a series of 1's and 0's?
Post by J. FrancisPost by CanopyCoNow, if the reader had its own memory chip that captured and stored that
information until the software took the information and then reset the
chip, it would be immune to any form of bad ware input.
Irrelevant. At some point software picks up the data and the fun begins.
But that software is, or should be if properly written, capable of
handling any combination of 1's and 0's of the desired size and treat
them as nothing but a number that is cross-referenced to a database for
future activities.
Sending that software the number 10011001 should do nothing to it that
was not listed in the database, as it did not over run the buffer, due
the hardware memory chip not sending to fast, or to large.
Post by J. FrancisPost by CanopyCoDue to the
memory chip only holding the expected amount of digits. And they would
still only be 1's and 0's.
It's *ALL* only 1's and 0's. The data, the software diddling it, the drive
controller firmware on the storage device that archives your address for
future junk mailings... *ALL* of it.
Exactly.
And how one handles those 1's and 0's determines what happens.
If I run an ASCII program the same 1's and 0's becomes a "R".
If a run a math program, that series of 1's and 0's becomes a number.
The only way for malware to work is to get out of the program that
handled the 1's and 0's in the proper way, and into an area where it is
handled improperly.
That would be prevented if there was a hardware "filter" that prevented
the data from being to large or coming in to fast.
Then it would just be handled as the number that it was expected to be,
and nothing bad would happen that was not listed in the database that
the number cross referenced to in order to know what to do.
For example, if my database receives number 11000110, then decrease
inventory of item number Mo-123-xph by 1, display price of $5.95, and
add price of $5.95 to total at register. Go to check inventory for
reorder. Reorder; if total of item number Mo-123-xph < or = 25, then
send out order for restocking.
Nothing bad happened.
And there is a listing for every one of those possible combinations.
If not, then there is a line saying; If number input not found in
database, display "part not found" and go to next item.
Now, nothing bad can happen from anything that came from the RFID chip.
Because the software was properly written to handle all possible
combinations of 1's and 0's expected from the chip.
And nothing unexpected from the chip can get past the hardware
"filter".
If it is not done that way, it should be.
Post by J. FrancisPost by CanopyCoAnd as to overload from to much coming from the RFID chip, that can be
addressed this way.
The hand scanner sends out a signal, we will call it "give me the data".
At that point it starts receiving the data, likely in serial sense it is
a radio signal, and starts loading it into its memory chip. Now, once
that chip is full, it stops taking input. That is done with hardware. It
has a counter, and counts the number of inputs. When it get the right
number of inputs, it quits taking input. Doesn't matter if more is
coming, because it's memory chip is full and it has stopped taking
input.
That's essentially how it works *now* with a few exceptions, and it's been
proved vulnerable. The problem isn't taking a specific size of data off
the tag, it's processing that information. Your "preprocessing" theory is
fundamentally flawed because the data isn't consistent in length or
segmentation. You're describing a scenario that simply does not exist in
the real world. Sorry.
There is the problem
It is not consistent in length or segmentation.
It should be, so that this problem would be gone.
If it were always the same size, then the software would know what to
expect, and it could deal with it properly.
And there is no reason that it cannot be.
Just that it isn't.
Now that we have determined where the problem is located, maybe you
could make yourself some bucks by fixing the problem.
All you have to do is make your system use a set sized data, so that
the software is never exposed to a size larger then it can handle, nor
is it exposed to a series of 1's and 0's that it did not have a use
for.
Post by J. FrancisPost by CanopyCoNow you have a simple number.
It is the right size.
And it is handled as nothing more then a serial number. If it did not
Not possible. That would make RFID tags utterly useless. I believe at
current most RFID tags carry 128K of memory space. In that space you will
find APC, dates, manufacturer and retail location information, and
probably a lot of other garbage. It's all necessary for things like
letting you trundle through the exit with your new DVD copy of your
favorite movie without setting off the alarm, while still triggering that
same alarm when the guy right behind you tries to leave with the copy
of the exact same movie he shoved down his pants.
And *that's* just your local shopping mall RFID tag.
Don't forget they have medical and law enforcement applications too,
including things like having codes for your allergies and heart attack
history available for immediate retrieval, and contact information for a
lost pet's owner.
So, it is basically how the information is being used that is the
problem.
The over all system.
If they would use it as a number, instead of a generic memory device,
this problem would not exist.
And it does not have to be done that way.
Just that it is.
They could store a serial number on that chip, and use what ever came
off of it as a number.
Then that would solve all these problems.
So, it is not that they can't do it in a safe manner, just that they
aren't.
Maybe you could make yourself some bucks writing a program that used it
in the manner that I suggested, with the hardware filter that I
suggested, and market it as virus proof.
Post by J. FrancisAgain you've run into that over simplification wall head on. It's
obviously impossible to treat data stored on an RFID tag as "a simple
number".
Why?
If all I stored on it was a number, then why could I not treat it as a
number?
And doing it my way, the simple way, would totally do away with the
virus problems form now on with that product.
Post by J. FrancisFact is, it's cost prohibitive to design them in such a way that
they can only store a certain amount of numbers of a certain size, because
customer "A" will have different data requirements than customer "B". That
means leaving all 128K open for "flat" R/W and dealing with data field
sizes and quantities in software.
Hold it, they are allready only capible of holding a number of 128K in
size.
That is a set and knowen size of number.
You said it was imposible?
And by doing it my way, with it only being a number and being handled
as a number, you can fufill all those diferent needs.
Simply put diferent stuff in the database that you cross referenced
with that number.
Keeping track of your dog?
Number 1100110 crossrefferences to the Black Lab belonging to Bob
Barker on Pound Street.
Ok, I think I see the proublem now.
Number 1100110 in wallmart will crossreference in there database to be
a pack of penuts.
Hummm, still, they are allready all just getting 1's and 0's.
So why is this not happening anyway?
Are they formating the information as somthing comon like a TXT
document, so that all readers that open it is capible of reading it and
they just sort it out at that point based on the contents?
Like in the abouve, when they opened that document, the penuts chip
would say "Big Boy Penuts, 10 oz can", where the dog would say "Bob
Barkers Black Lab form Pound St"?
Is that what is going on?
They could allocate number groups to users, like they do frequencies
now.
That would solve that problem.
After all, a fake chip with fake prices in it is going to be a problem
no matter what.
But at least this method would stop someone form draining Walmart's
bank account.