List of Archived Posts

2007 Newsgroup Postings (01/18 - 01/27)

old discussion of disk controller chache

Decoding the encryption puzzle

some old network related discussion

"New Universal Man-in-the-Middle Phishing Kit" ?

"The Elements of Programming Style"

old productivity response time studies

Securing financial transactions a high priority for 2007

Miniature clusters

Securing financial transactions a high priority for 2007

Decoding the encryption puzzle

Securing financial transactions a high priority for 2007

Decoding the encryption puzzle

Special characters in passwords was Re: RACF - Password rules

(old) distributed 4341s

How many 36-bit Unix ports in the old days?

Securing financial transactions a high priority for 2007

How many 36-bit Unix ports in the old days?

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

How many 36-bit Unix ports in the old days?

Securing financial transactions a high priority for 2007

How many 36-bit Unix ports in the old days?

"The Elements of Programming Style"

Special characters in passwords was Re: RACF - Password rules

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Being "Open" (Was: Mainframe vs. "Server")

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

"The Elements of Programming Style"

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Point-of-Sale security

How many 36-bit Unix ports in the old days?

Keep VM 24X7 365 days

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

SVCs

Securing financial transactions a high priority for 2007

SVCs

EXTERNAL INTERRUPT and SAPL

SVCs

How many 36-bit Unix ports in the old days?

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

IBM URL of all available lists?

"The Elements of Programming Style"

SVCs

old discussion of disk controller chache

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: old discussion of disk controller chache
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 18:16:48 -0700

I had come up with the dup/no-dup strategy earlier for fixed-head
paging drums (2305), partially in conjunction with "SYSPAG" changes
a few past posts
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?

along with some enhancements to "page migration" ... that I originally
shipped in in the resource manager ... some collected posts
http://www.garlic.com/~lynn/subtopic.html#fairshare


From: wheeler
Date: 12/07/82  09:10:05
To: vm development group

re: 3880-11; IRONWOOD is too small to be effectively used for much of
anything. I've been to Tucson to meet with the IRONWOOD (& IRONWOOD
follow on) people. Best thing that could be done immediately for
IRONWOOD is to have two modes of operation. As long as the hit rate
was satisfactory, do basically the current code. When the hit rate
begins to drop off, switch algorithms. Problem is that IRONWOOD is
very small compared to real storage sizes.

If a page is read into core, it is then very likely to exist in both
IRONWOOD & real memory (this is referred to as duplicates). Assuming
an interactive environment, then that page will probably be stolen and
another page will be read in ... long before IRONWOOD replaces that
particular page in its private store. In a highly interactive
environment, it is possible that almost every page in the IRONWOOD is
a duplicate ... i.e. it exists in both real memory & IRONWOOD.

What are the implications of that???? If real memory takes a page
fault ... that means that the page isn't in real memory. The page will
have to be read in from IRONWOOD. What is the probability of the page
existing in the IRONWOOD ("hit"). The "hit" ratio is a function of the
size of the IRONWOOD and the locality of the code. A quick look at
IRONWOOD would indicate that it is an eight megabyte cache ... right?
Because of duplicates ... wrong. If there is seven megabytes of
duplicates ... what does that mean. That means that there are seven
megabytes of pages which are both in IRONWOOD and real storage. A page
fault in real storage indicates that the page that is desired is not
in real storage .... that means that 1) it is not one of the seven
megabytes of duplicate pages, 2) the IRONWOOD contains only one
megabyte of pages that it could possible be. Because of duplicates in
this situation ... the IRONWOOD isn't even an eight megabyte cache ...
it is effectively a one megabyte cache.

Mechanism to solve this problem is to get rid of duplicates. The
second mode of operation (which I referred to) is to do a READ/DISCARD
... which tells the IRONWOOD that as soon as the page is transferred
to real storage ... make the IRONWOOD slot available for other
data. Then VM will artificially have to force the STORAGE ALTERATION
flag ... so that the page will be written out if it is ever
stolen. The overhead in CP is increased because all pages that are
stolen, must be written out (rather than just changed pages) ... but
it drastically increases the effective cache size.

... snip ... top of post, old email index

IRONWOOD was a 8mbyte 4k-byte record cache added to the 3880 disk controller
(product referred to as "3880-11") and was done in Tucson.

following from Tucson engineer:


To: wheeler
Date: 01/06/83  09:09:05

Hi Lynn,

In our Ironwood testing we have noticed a problem when running both
drums and Ironwoods as primary paging. It appears that the ALLOC blocks
will fill to the level of the smallest blocks. This is hindering us in
trying to perform the complete set of configurations that we would like
to run. Your original response to this problem turns out not to be the
solution.... could you please get in contact with XXXXXX to pursue
this problem. Thanks.

... snip ... top of post, old email index

the is basically part of the genesis in past postings on "dup/no-dup"
strategy (i.e. duplicates or no duplicates)
http://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002f.html#26 Blade architectures
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#18 how much swap size did you take?
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor

Decoding the encryption puzzle

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decoding the encryption puzzle
Newsgroups: bit.listserv.ibm-main
Date: Thu, 18 Jan 2007 18:35:38 -0700

Hal Merritt wrote:

The encryption software starts before Windows. The software failed
with a blue screen of death.

My sense is that one or more critical files on the hard drive used by
the software became corrupt as PC files are known to do. But I don't
know.

But my point was the laptop was put out of service for several
days. Doesn't really matter why. This may be tolerable (or even
expected) with a PC. But on a mainframe?

The complete loss of mission critical data even for a few days could
be catastrophic to the company. One solution is to have backups that
aren't encrypted. But, then, what would be the point of encryption in
the first place? As I said, a puzzlement.

for a little drift ... another crypto related thread (FDE ... full
disk encryption)
http://www.garlic.com/~lynn/aadsm26.htm#23 It's a Presidential Mandate, Feds use it. How come you are not using FDE?

one of the things that was driving "key escrow" ... was that if the
data (at rest) was always encrypted ... then the backups would also be
encrypted. "key escrow" was required to satisfy "no single point of
failure" scenario (loosing the key) and disaster recovery.

There is a separate issue if a vulnerable laptop containing the only
copy of business/mission critical data ... this is again normally
dealt with as a disaster recovery and "no single point of failure"
scenario (regardless of what kind of availability standard any piece
of equipment might meet).

For a totally different rant ... there is a big effort to solve some
vulnerability problems using encryption ... which I claim would be
better addressed by eliminating risk associated with some forms of
data ... and eliminating requirement for other kinds of data
altogether. recent long-winded posts on the subject
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007

some old network related discussion

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: some old network related discussion
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 18:46:44 -0700

CJN corporate started to manage internal network configuration
(VNET) add/delete/changes. misc. collected posts mentioning internal
network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

I had done a program that automated some of the administrative
operations associated with the operations.

Note example of "MAPCHANGE UPDTxxx" files (format had been slightly
modified to meet my suggestion) can be seen here ... associated with
announcement of 1000th node in 1983
http://www.garlic.com/~lynn/internet.htm#22
http://www.garlic.com/~lynn/99.html#112


To: wheeler
Date: 12/06/82  15:42:01

Lynn,

I will try to alter the MAPCHANG UPDTxxx files so that your process
will work.  When you mentioned the name of your program it sounded
familiar.  I recalled that you had sent us a copy of it last February
(I think).  We were then, and still are, using a program called ROUTE
that also updates the RSCS directory.  However, after talking to
XXXXXX, my "senior partner" here, he informed me that your program
might be a good thing for us to use since it looks at the "connected
to" node when routing.  What all this rambling comes down to, is that
I was wondering if there is a later version of the program than the
one I received from you in February.  If so, could you please send it?
If there is any type of script file for it could you please send it
because I don't have any at all right now.  Thanks.

... snip ... top of post, old email index

and another old email with a network related subject ....

This would be networking code running in a virtual machine ...  the
issue is "EC-mode" virtual machines have more overhead simulation
(compared to "BC-mode" virtual machines). STNSM was an instruction
only simulated for "EC-mode" virtual machines ... the issue is how to
get the equivalent function while running in "BC-mode".


To: wheeler
Date: 12/14/82  18:43:23

Lynn:

I don't remember if you were the one who told me, but I gather there
is a way of simulating the function of STNSM, to allow one to restore
the system mask to the previous value when returning from a subsystem.
I think it involved performing some kind of SVC and then picking up
the old PSW from a storage location.  Could you help me refresh on
this, or point me to an example of how this is done?  The Wisconsin
joint CSNET project, which was the one that prompted the questions
about STNSM and EC mode in the first place, has decided that requiring
the user to specify EC mode just to be able to do STNSM seems like too
much trouble (especially if running with EC mode on incurs a
performance penalty), but would still like to simulate the function if
it is possible.

... snip ... top of post, old email index

CSNET was "computer science" network for educational institutions.
misc. past posts mentioning csnet:
http://www.garlic.com/~lynn/98.html#59 Ok Computer
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#37b Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#38c Internet and/or ARPANET?
http://www.garlic.com/~lynn/2000d.html#58 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#72 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000f.html#51 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001m.html#48 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001m.html#54 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#5 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#14 Security glossary available
http://www.garlic.com/~lynn/2002e.html#6 LISTSERV(r) on mainframes
http://www.garlic.com/~lynn/2002g.html#45 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#82 Al Gore and the Internet
http://www.garlic.com/~lynn/2002k.html#26 DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet (fwd)
http://www.garlic.com/~lynn/2002p.html#61 20th anniversary of the internet (fwd)
http://www.garlic.com/~lynn/2004g.html#31 network history
http://www.garlic.com/~lynn/2004l.html#0 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004o.html#47 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005e.html#46 Using the Cache to Change the Width of Memory
http://www.garlic.com/~lynn/2005n.html#16 Code density and performance?
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#12 Arpa address
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006q.html#25 garlic.com
http://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006v.html#35 What's a mainframe?
http://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network
http://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)

"New Universal Man-in-the-Middle Phishing Kit" ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "New Universal Man-in-the-Middle Phishing Kit"  ?
Newsgroups: comp.security.misc
Date: Thu, 18 Jan 2007 19:03:25 -0700

Barry Margolin <barmar@alum.mit.edu> writes:

Maybe.  But that's true of traditional phishing sites, it's nothing new
in this case.  The MitM attack simply adds the ability of the site to
display things on the page that supposedly only the real site can
display (such as your last ATM transaction).

or supposedly the latest online banking countermeasures for fraudulent
website (phishing) impostors ... recent discussion in another n.g.
http://www.garlic.com/~lynn/2007b.html#53 Forbidding Special characters in passwords
http://www.garlic.com/~lynn/2007b.html#54 Forbidding Special characters in passwords
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007

misc. past posts mentioning MITM-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 04:01:51 -0700

re:
http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism?
http://www.garlic.com/~lynn/2007b.html#57 "The Elements of Programming Style"

With An 80-Core Chip On The Way, Software Needs To Start Changing
http://www.informationweek.com/showArticle.jhtml?articleID=196901935

from above:

Intel is about a month away from unveiling the specs for a research
prototype of an 80-core chip that they've developed. That's right: Not
an 8-core; this is an 80-core chip. The microprocessor manufacturer
has jumped way ahead of the expected progression from dual-core to
quad-core to 8-core, etc., to delve into different ways to make
something as complicated as an 80-core chip actually work.

... snip ...

and for something a little bit older ...

DMKLOK had to do with SMP/multiprocessor lock operations. This email
talks about DUMPRX enhancement to do some amount of automated
diagnostic operations for failures related to SMP locking operations.


From: wheeler
Date: 12/16/82  11:45:15

I'm sending out a newer copy of DUMPRXE with additional support for
processing LOK abends. Code attempts to check if the R1 pointer to
lockword is contained in DMKLOK & then runs thru the list of various
known LOCKWORDS. Would appreciate testing against any dumps you
currently may have.

... snip ... top of post, old email index

misc. collected posts mentioning DUMPRX, problem analysis, failure
signatures, etc
http://www.garlic.com/~lynn/subtopic.html#dumprx

lots of collected posts mentioning multiprocessor operation and/or
compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

and misc. past posts mentioning an old 5-way SMP project from
1975
http://www.garlic.com/~lynn/subtopic.html#bounce

and some old email on ha/medusa that talks about scale-up in
cluster manner
http://www.garlic.com/~lynn/lhwemail.html#medusa

old productivity response time studies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: old productivity response time studies
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 04:57:58 -0700

from long ago and far away ...


From: wheeler
To: somebody in bldg. 14, disk engineering lab
Date: 01/21/83  11:38:34

re: response time; Also when I was in YKT last week, I got several
copies of new studies comparing productivity and response times. One
particular study compared engineers doing design work on graphics
devices. To minimize some of the external variances, they broke the
engineers into three categories; novice, general, experienced. With
one second response time, the experienced engineers were working only
slightly faster than novice engineers. At less than .25 second
response the experienced engineers were working over 10 times faster
than the novice engineers (and in fact their transaction rate went off
the end of the graf).

>From the 2nd 327x document i sent, the best case for the newest 3274
coming down the line is .18 second hardware response ... that time is
added to the system response time to come up with the total response
time ... i.e. with the best 3274 being planned, it is still practical
impossible to achieve less than .25 second response time.

... snip ... top of post, old email index

misc. past posts mentioning working with bldg. 14 engineers
http://www.garlic.com/~lynn/subtopic.html#disk

and misc. past posts mentioning sub-second response time studies ...
including some discussion with problems using 3274 controllers to
replace 3272 controllers
http://www.garlic.com/~lynn/2001k.html#30 3270 protocol
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2003e.html#43 IBM 3174
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003o.html#36 When nerds were nerds
http://www.garlic.com/~lynn/2004e.html#0 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#28 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 09:53:28 -0700

Andrew Swallow <am.swallow@btopenworld.com> writes:

Does the internal number, as used by the back office functions, need
to be the same as the account number entered by the user?

Conversion can be performed by table look up with only a very small
number of programs being authorized to read the table.  Back office,
internet access and id conversion can be performed on 3 different
computers.  Prevent hacking by using physical transference rather
than "email".  You can buy 2 giga-byte memory cards for $40 these days.
http://www.amazon.com/Kingston-CF-2GB-S-ElitePro-CompactFlash/dp/B00062WV86/sr=1-1/qid=1169215655/ref=sr_1_1/102-9048468-9856929?ie=UTF8&s=pc

there have been some attempts at things like that ... the issue is
that account numbers are actually used by a large number of business
processes spread all over the place. as a result there isn't a single
interface where they would translation occur (their are more like tens
of millions).

one of the most vulnerable is all the merchant backroom operations
... i.e. as i've refereed to several times in security proportional to risk
post
http://www.garlic.com/~lynn/2001h.html#61

where you may have tens/hundreds of millions of such merchant
operations ... some number involve entry-level employees with little
training and only semi-automated processes.

one of the places that such attempts like that (in the past) fell down
was dispute/charge-back. the merchant has the transaction log as the
consumer account number. the consumer calls their consumer/issuing
bank to complain about something giving 1) account number, 2) amount,
3) date, 4) merchant. the merchant is eventually contacted giving 1)
account number, 2) amount, 3) date. The merchant then has to look it
up in their records/log by the consumer's account number. all this
(can) happens by phone.

the simplest place to do this is at the issuing/consumer financial
institution ... by contrast to the tens/hundreds of millions of
merchants ... their are possibly only thousands. however, the
financial institutions are frequently already the best protected and
the lest likely to have a breach (so it doesn't provide much
additional overall improvement ... since it doesn't hit the weakest
link).

furthermore, most financial institutions already have an
implementation that already does something similar .... re-issuing
cards (lost/stolen) with new number ... they will carry both the new
number and the old number mapped to common account (however, it isn't
a prevention to skimming/harvest attack since you just need the number
used at the merchant). something similar is used for linked, family
cards.

having the conversion occur at the merchant ... where the biggest
threat exist ... means putting a copy of the table out in
tens/hundreds of millions of merchants ... that is manually accessible
by entry-level employees.

when we were working on what was to be called electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we made a suggestion (as countermeasure to insider) that all merchant
employees have full FBI background checks ... which can be quite
expensive and time-consuming ... recent posting on subject
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules

akin, it works for various workers in financial institutions ... but
again there are a lot fewer institutions and it involves significantly
fewer workers (compared to tens/hundreds of million merchant operations)

now, there is a variation on account numbers that they are trying
... but it is pushed out to the consumer ... which is one-time-account
numbers. the consumer is issued with a large number of account numbers
... all linked to the "backroom" account. this account numbers can
only be used once ... so if they are skimmed/harvested from the
merchant logs ... they can't be used in replay-attack. The
tens/hundreds of millions of merchant processes don't change.

the problem here is the inconvenience to the consumer ... and there
have been claims that the account number domain is getting depleted.
they have quite a few digits ... but several are used for association
and routing (a little akin to telephone area codes), having a unique
account number for every purchase ... makes them go quickly (so
approach isn't widely deployed ... and several deployments in the
early 70s didn't last long and were abandoned).

past posts in this thread:
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007

Miniature clusters

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Miniature clusters
Newsgroups: comp.arch
Date: Fri, 19 Jan 2007 10:02:27 -0700

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

This isn't really an architecture question, so much as a design one,
but I can't think of a more appropriate forum.

I am referring to systems with at least 16 CPUs (preferably actually
CPUs, not just cores) with a reasonable specification (e.g. ECC if
possible), that are suitable for putting in an ordinary office or using
at home.  E.g. they must all run off a single 13A socket, not be too
noisy (I am happy with 80 dB, but not everyone is), not need special
conditions and not be too bulky.

past emails discussing MEDUSA (cluster-in-a-rack) ...  prototype was
16 processors in a rack ... the product was going to have 32
processors in a rack (and you scale it up with multiple racks)
http://www.garlic.com/~lynn/lhwemail.html#medusa

and as mentioned here ... the project was transferred, announce
in a different venue, and we were told we couldn't work on
anything with more than four processors
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/2001n.html#83

I had attempted something nearly a decade earlier ... but the
density was significantly less
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

of course, the amount you can package in physical space has
significantly increased since either of these previous activities.

so where does 80-core chip fit in?
http://www.garlic.com/~lynn/2007c.html#4 "The Elements of Programming Style"

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 12:13:24 -0700

re:
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007

Retail security breach may be biggest in U.S.
http://www.iht.com/articles/2007/01/19/business/data.php

one more time can you say security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

lots of past posts mentioning account harvesting/skimming
for simple replay attacks
http://www.garlic.com/~lynn/subintegrity.html#harvest

even for some supposedly "modern" chip technology
http://www.garlic.com/~lynn/subintegrity.html#yescard

and past posts with general comments about threats, risks, vulnerabilities,
fraud, etc
http://www.garlic.com/~lynn/subintegrity.html#fraud

Decoding the encryption puzzle

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decoding the encryption puzzle
Newsgroups: bit.listserv.ibm-main
Date: Fri, 19 Jan 2007 12:52:40 -0700

Anne & Lynn Wheeler wrote:

for a little drift ... another crypto related thread  (FDE ... full disk
encryption)
http://www.garlic.com/~lynn/aadsm26.htm#23 It's a Presidential Mandate, Feds use it. How come you are not using FDE?

re:
http://www.garlic.com/~lynn/2007c.html#1 Decoding the encryption puzzle

the older article

Feds crawl toward encryption
http://weblog.infoworld.com/techwatch/archives/009492.html

from above:

Such appears to be the case with this year's infamous data-leak
episode of millions of U.S. veterans' private information last May,
which prompted the White House to issue a presidential mandate [PDF]
requiring all agency mobile laptops and devices storing sensitive data
to have fully encrypted hard drives.

... snip ...

and the referenced gov. document
http://www.whitehouse.gov/omb/memoranda/fy2006/m06-16.pdf

new article

Firms face pressure to encrypt data
http://www.boston.com/business/articles/2007/01/18/firms_face_pressure_to_encrypt_data/

and new item on vulnerability

Retail security breach may be biggest in U.S.
http://www.iht.com/articles/2007/01/19/business/data.php

and, of course, old posting on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

and comment here
http://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 13:10:07 -0700

Anne & Lynn Wheeler wrote:

one of the things that the x9a10 financial standard working group had
to take into account was that in the mid-90s the EU had made some statement
that retail payments should be as anonymous as cash ... i.e. no name,
no address, no telephone number, and no other personal gorp.

in that sense we attempted to make the x9.59 financial standard for
all retail payments, "privacy agnostic".
http://www.garlic.com/~lynn/subpubkey.html#x959

x9.59 would meet the requirement given the x9a10 financial standard
working group to preserve the integrity of the financial
infrastructure for all retail payments ... as well as

1) eliminate account number vulnerabilities (didn't do anything about
eliminating data breaches and security breaches ... but drastically
reduced the risk when such breaches happened ... especially related to
"account fraud") and

2) drastically reduced the places (all retail payments) where personal
information might be required (and therefor drastically reduced the
repositories containing such personal information ...  hopefully
helping reduce actually occurrences of other types of "identity theft")
...  also meeting the EU statement on making retail payments as
anonymous as cash ... or at least "privacy agnostic"

some of this led up to being the co-author of the x9.99 financial
industry privacy standard. as part of that effort ... I pulled
together a merged (eu-dpd, glba, hippa, etc) privacy taxonomy and
glossary ... references to merged taxonomy and glossary activities
http://www.garlic.com/~lynn/index.html#glosnote

re:
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007

TJX Hack Highlights Payment Information Insecurity
http://www.informationweek.com/showArticle.jhtml;jsessionid=MFDDZSZDTWEVAQSNDLRCKHSCJUNN2JVN?articleID=196902075

from above:

The cost of data breaches, whether the information is lost or stolen,
continues to escalate, costing companies an average of $182 per
compromised record.

... snip ...

that may not include the cost/aggravation to the individuals who get
fraudulent charges on their accounts.

other related posts
http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007

and this
http://www.garlic.com/~lynn/2007c.html#1 Decoding the encryption puzzle
http://www.garlic.com/~lynn/2007c.html#9 Decoding the encryption puzzle

of course there is the issue of insiders as well as security proportional
to risk
http://www.garlic.com/~lynn/2001h.html#61

or the observation here about account number leakage even if the
planet was buried under miles of encryption
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007

Decoding the encryption puzzle

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decoding the encryption puzzle
Newsgroups: bit.listserv.ibm-main
Date: Fri, 19 Jan 2007 13:53:55 -0700

Howard Brazee wrote:

Decades before, people kept printed copies of programs they wrote.
Sometimes they even used them in job interviews.

Is that significantly different?

potentially by several orders of magnitude ... also might completely
change the possible fraud "return-on-investment" equation.

something that might have 1percent fraud ... if it changed by two
orders of magnitude ... it could go to nearly all fraud ... possibly
resulting in collapse of the infrastructure

recent posts in this thread:
http://www.garlic.com/~lynn/2007c.html#1 Decoding the encryption puzzle
http://www.garlic.com/~lynn/2007c.html#9 Decoding the encryption puzzle

the whole data breach, security breach that has been in the news for
the past year or two ... is that the attacker's cost for an electronic
breach and to translate that electronic information directly into
fraud can be a couple orders of magnitude lower per account ... than saying
physical operation of holdup at gunpoint to obtain somebody's
wallet. If you take the time&effort of a physical holdup for a
couple of credit cards .... the cost to the attacker (per account) can
be easily several orders of magnitude larger compared to the cost to
the attacker (per account) for an electronic breach involving a couple
million account records.

and of course, reference to old security proportional to risk post
http://www.garlic.com/~lynn/2001h.html#61

lots of past posts involving some kind of fraud, threat,
vulnerability, exploit, etc

http://www.garlic.com/~lynn/subintegrity.html#fraud

and loads of past posts specifically mentioning data breaches and/or
security breaches
http://www.garlic.com/~lynn/aadsmail.htm#mfraud AADS, X9.59, security, flaws, privacy
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm6.htm#terror4 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aepay12.htm#5 Law aims to reduce identity theft

http://www.garlic.com/~lynn/aadsm11.htm#47 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm17.htm#32 visa cards violated, BofA reissuing after hack attack
http://www.garlic.com/~lynn/aadsm18.htm#35 Credit card leaks continue at a furious pace
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#28 "SSL stops credit card sniffing" is a correlation/causality myth
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#1 Keeping an eye on ATM fraud
http://www.garlic.com/~lynn/aadsm20.htm#2 US consumers want companies fined for security breaches
http://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#18 'Virtual Card' Offers Online Security Blanket
http://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/aadsm23.htm#0 Separation of Roles - an example
http://www.garlic.com/~lynn/aadsm23.htm#9 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#47 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#21 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm25.htm#26 Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy
http://www.garlic.com/~lynn/aadsm25.htm#41 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#5 ATMs hacked using MP3 player
http://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#7 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#11 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/2001d.html#58 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001l.html#10 E-commerce security????
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
http://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002l.html#20 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
http://www.garlic.com/~lynn/2003n.html#23 Are there any authentication algorithms with runtime changeable key length?
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#45 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#50 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005j.html#19 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005l.html#24 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#34 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#27 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2005u.html#31 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2005u.html#33 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions
http://www.garlic.com/~lynn/2006g.html#38 Why are smart cards so dumb?
http://www.garlic.com/~lynn/2006h.html#14 Security
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#47 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006p.html#18 19,000 Accounts Compromised
http://www.garlic.com/~lynn/2006p.html#38 Hackers steal AT&T customer data
http://www.garlic.com/~lynn/2006t.html#5 Are there more stupid people in IT than there used to be?
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#42 The logic of privacy
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007

Special characters in passwords was Re: RACF - Password rules

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Special characters in passwords was Re: RACF - Password rules .
Newsgroups: bit.listserv.ibm-main
Date: Fri, 19 Jan 2007 17:12:26 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

One of my hobbies was building enhanced, customized operating systems for
internal distribution. I've joked before (sometimes with multics aficionados)
that the number of customers vm installations was larger than the number
of internal vm installations; and the total number of internal vm installations
were significantly larger than the number of customer vm installations;
and that i directly distributed customized vm operation system to. However,
at various times, the number of internal installations that I built and directly
distributed customized operating systems for ... were as large as the
total number of Multics systems that ever existed.

and for a little cross-over from b.l.i n.g. re:
http://www.garlic.com/~lynn/2007b.html#51 Special characters in passwords was Re: RACF - Password rules

In the following "put tapes" are monthly cumulative update
distribution tapes.

"SJJ" ... is updated name for sjr/vm ... standing for "san jose joint"
(system)


From: wheeler
To: somebody at lidingo sweden
Date: 07/05/83  12:50:04

re: sjj VM system; Shouldn't be much trouble installing SJJ. We still
haven't finished with a CLEAN distribution tape so everything installs
cleanly. You should be aware that we are built on top of common with
all our own updates.

We are currently running on an early CSL24 system ... we worked with
Kingston to convert CSL23 to SP1.18+HPO2. We have most PTFs applied
from SP1 put tapes up thru about March. We are almost done with
bringing PTF level up to the current PUT tape. We have early releases
of several pieces of code already integrated (like IRONWOOD with local
fixes and enhancements ... also new PVM stuff). We are most of the way
thru HPO2.5 integration (primarily >16meg support).

Over and above that we have quite a few local changes (more than
Hursley). System is currently running on something over 50 machines
from 4331s to 3081Ks and is supported by 5-8 system programming teams.

... snip ... top of post, old email index

and recent post with old email mentioning IRONWOOD
http://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller cache

and post with old mention of >16meg support
http://www.garlic.com/~lynn/2007b.html#34 Just another example of mainframe costs

and a status update ... from STL (now called silicon valley lab)


From: wheeler
Date: 07/09/83  11:24:39

re: stl; stl i/s crew said yesterday that some of the IS machines are
going for 30 days at a time w/o a software system failure and stl i/s
has gone a week at a time w/o any machine taking a software failure.

This apparently is the first time that anything like that has happened
for them. Supposedly they attribute it primarily to this SJJ VM system
and the co-operation that has gone on (at least when talking to me).

There are at least three things that contribute to the improvement. 1)
there is a lot of local code in the SJJ system specifically for
reliability purposes, 2) the debugging activity is shared by all the
locations running the SJJ system so the quality and number of people
finding&fixing bugs is greater, 3) my DUMPRX CP problem determination
package has improved the ability of the people to do problem
determination.

as I said before, the I/S survey for STL shows marked improvement.
Besides reliability, another factor is the removal of a lot of the
logon restrictions. They were talked into substituting my local mods.
for GROUP FAIR SHARE for the logon number limits.

... snip ... top of post, old email index

a couple recent posts mentioning the old group fair share work:
http://www.garlic.com/~lynn/2007.html#14 vm/sp1
http://www.garlic.com/~lynn/2007b.html#39 How many 36-bit Unix ports in the old days?

and a collected posts mentioning resource manager and/or fair share
work
http://www.garlic.com/~lynn/subtopic.html#fairshare

a lot of the reliability updates, I had original done as part of
IOS subsystem rewrite I did for reliability in the disk engineering and
product test labs (bldgs 14&15)
http://www.garlic.com/~lynn/subtopic.html#disk

and lots of past posts mentioning dumprx
http://www.garlic.com/~lynn/subtopic.html#dumprx

posts with old email mentioning internal distribution
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
with old email from apr75 about distribution
http://www.garlic.com/~lynn/2006w.html#email750430

post about sjr/vm distribution
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
with old email from apr80 about the distribution
http://www.garlic.com/~lynn/2006u.html#email800429


From: wheeler
Date: 07/11/83  10:28:40

the swedish inquiry for VM is for their hdqrtrs location ... which
will package and install the same vm system for all internal IBM sites
in Sweden. They would like an up-to-date ... realistic version of the
R6TAPE MEMO. Don't know for sure what the arraignments to on-site
install are yet. With the interest from Europe, there should be the
possibility of getting somebody to cover the basic expense and once
that happens all the rest of the sites will always come-up with and
delta expense. I'm going to be too busy to go ... so if anybody else
is interested in picking up the ball ... go ahead. They will be
expecting some amount of familiarity with the system and help to
easily install it and run it thru its paces.

There is the potential for at least visiting 2-3 other locations in
Europe, at least for SJJ sales trip, if not for actual installs.

... snip ... top of post, old email index

R6TAPE MEMO was the detailed distribution document for the sjr/vm
release 6 mentioned here
http://www.garlic.com/~lynn/2006u.html#26 Assembler question

and for something a little different, announcement for the monthly bay
area vm users meeting


To: distribution
Date: 07/11/83  20:55:48

On July 19th, at 7:30pm at the monthly Bay Area VM users meeting
"BayBunch," Norm Radder, from the Bank of America's programming staff,
will discuss the Bank's implementation of the PROTECT EXEC.  The Bank
thinks that this EXEC addresses ten security problems inherent in VM.
The basis of the PROTECT EXEC is to address the weakness in password
only protection for the LINK command.  It allows the M-disk owner to
state who may LINK.  I don't know all the bells and whistles that the
Bank has added to their EXEC.  A PROTECT EXEC was an integral part of
the NCSS VM like timesharing system (NOMAD).  The Baybunch meeting
will be held at SLAC (Stanford Linear Accelerator) in Menlo Park,
California.

... snip ... top of post, old email index

... the security issue is basically adding an access control list
(ACL) capability to VM.

NCSS was one of the early timesharing service bureaus that started
with cp67. misc. past posts referring to various of these timesharing
service bureaus
http://www.garlic.com/~lynn/subtopic.html#timeshare

and specific posts mentioning NCSS, NOMAD, etc
http://www.garlic.com/~lynn/99.html#10 IBM S/360
http://www.garlic.com/~lynn/2001h.html#59 Blinkenlights
http://www.garlic.com/~lynn/2001m.html#51 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002m.html#61 The next big things that weren't
http://www.garlic.com/~lynn/2002p.html#37 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003d.html#15 CA-RAMIS
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
http://www.garlic.com/~lynn/2003d.html#68 unix
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003k.html#10 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#34 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2003m.html#33 MAD Programming Language
http://www.garlic.com/~lynn/2003n.html#15 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2003o.html#23 Tools -vs- Utility
http://www.garlic.com/~lynn/2004d.html#33 someone looking to donate IBM magazines and stuff
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#45 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006k.html#35 PDP-1
http://www.garlic.com/~lynn/2006k.html#36 PDP-1
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006k.html#39 PDP-1
http://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#13 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006o.html#49 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2007.html#8 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#12 "The Elements of Programming Style"

(old) distributed 4341s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: (old) distributed 4341s
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 06:40:21 -0700

a little SNA/3705 problem/issue with (French) distributed 4341s project.

index of old email mentioning 43xx machines
http://www.garlic.com/~lynn/lhwemail.html#4341

earlier post mentioning this project:
http://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal Computer"


To: wheeler
Date: 25 January 1983, 09:04:00 SET

hi,

Our 4341 DDP project is now officially launched.  One of our major
problems is the connection of the 4341's to the Concentrator network:

At the end of the experimental phase, we should have about 100 local
terminals connected to one distributed 4341. These terminals will be
partly used by people having access to MVS/IMS applications, like
WTAAS, through PVM (327x emulation) and the Concentrator network.

Is seems unreasonable to have so many lines (4 to 6 ?) between each
4341 and the Concentrator network.

Could you tell me what the status of the VMNSF project is. Could the
use of a S/1 N.I.P instead of a 3705 be a possible solution to our
problem?  Any information related to this topic would be useful for
us.  Thank you for your help

... snip ... top of post, old email index

recent mention of general SNA issues
http://www.garlic.com/~lynn/2006x.html#8 vmshare

i.e. it wasn't an issue of having a (non-SNA) network interconnecting
distributed 4341s ... it was having each of the 4341s connected into a
corporate (sna-based) terminal communication infrastructure
("concentrator network").

and misc. posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 07:42:00 -0700

re:
http://www.garlic.com/~lynn/2007b.html#39 How many 36-bit Unix ports in the old days?

references to group fair share scheduling (for unix, in the above post) also
shows up here in the x-over posting
http://www.garlic.com/~lynn/2007c.html#12 Special characters in passwords was Re: RACF - Password rules

and some (more vm) unix related email


From: ???
To: wheeler
Date: 8 January 1985, 01:51:41 ET

Subj:Caveat lector.

I am planning to tell the world you think our UNIX design was better
than the IX/370 UNIX design unless you object.  (Charts appended)

The world in this case is an ACIS review of our UNIX HOST strategy;
but I may not stop there.

... snip ... top of post, old email index

The ix/370 unix design was from the dallas organization that had
done the tss/370 rpq work for at&t. recent reference
http://www.garlic.com/~lynn/2007b.html#3 How many 36-bit Unix ports in the old days?

the above post has old email
http://www.garlic.com/~lynn/2007b.html#email800408

that includes reference looking for a 370 C compiler

this email is from the palo alto group that was doing the work on BSD
port for 370 (and trying to get me into trouble). This never actually
shipped, since they were eventually directed to retarget the BSD port
for PC/RT (801/romp) which was announced as "AOS".  old bsd/aos post
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ....
http://www.garlic.com/~lynn/2004f.html#44 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal R&D

lots of past 801 related posts
http://www.garlic.com/~lynn/subtopic.html#801

the palo alto group did later do 370 (and 386) port for UCLA's Locus
which was announced as aix/370 (and aix/386). recent post w/reference
to aix/370
http://www.garlic.com/~lynn/2007.html#32 V2X2 vs. Shark (SnapShot v. FlashCopy)

=====

And somewhat related to recent cluster thread
http://www.garlic.com/~lynn/2007c.html#7 Miniature clusters
and
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

... as opposed to (HA/MEDUSA) cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa


From: wheeler
Date: 07/12/85  09:15:51

spent afternoon talking to KERNAL adtech group in boeblingen ... they
have an alternative nucleus that is being proposed as a SSI
replacement for IX/370 (although they don't want to talk those details
at this point). They also have some part of a MVS simulation running
to the point that numerous MVS applications run under their kernal
... for instance on 37t.

They also had some interesting things to say about how they would
support a processor complex configuration. They already are already
down the road on not wanting to support channels but a high-speed bus
... and they have done work on how they would support multiple "local"
processors.  They are also looking at Multi-bus II which supposedly
has off the shelf hardware that would go to the 40 megabyte/second
range. That could configure numerous one board 370 processors.

The kernal group felt Roman was a lot further along (hope to talk to
somebody in that group on monday) ... they thot that 1987 was a
product availability. Roman project is now under processor development
and no longer in adtech ... and has fairly large organization. I'll
try and find out on monday how long it might take them to have a four
processor with bus interface adtech machine available. If they could
have a cheap multi-bus II quickly ... now have to worry about what is
managing the bulk store). It might be faster than trying to get A74
group to design a bus interface and build a four processor version.

... snip ... top of post, old email index

At this time, Europe/Germany (boeblingen) was putting a lot of effort
into ix/370 for a product (some of the dallas people were on assignment
there)

"37t" was 4331 repackaged into approx. size of desk-side two-drawer
file cabinet.

"roman" was a "new" 370 chip set (about performance of 168-3) ... previous
post with mention of mini-cluster, roman, as well as iliad
http://www.garlic.com/~lynn/2002l.html#27 End of Moore's law and how it can influence job market

"A74" was 370 processor attached to ibm/pc (with much better thruput
than earlier xt/at/370) announced as 7437 ... several 7437 press items
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home

other mention of a74/7437
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 10:39:51 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

now, there is a variation on account numbers that they are trying
... but it is pushed out to the consumer ... which is one-time-account
numbers. the consumer is issued with a large number of account numbers
... all linked to the "backroom" account. this account numbers can
only be used once ... so if they are skimmed/harvested from the
merchant logs ... they can't be used in replay-attack. The
tens/hundreds of millions of merchant processes don't change.

the problem here is the inconvenience to the consumer ... and there
have been claims that the account number domain is getting depleted.
they have quite a few digits ... but several are used for association
and routing (a little akin to telephone area codes), having a unique
account number for every purchase ... makes them go quickly (so
approach isn't widely deployed ... and several deployments in the
early 70s didn't last long and were abandoned).

re:
http://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007

that "early 70s" is mistype ... should refer to early part of this
decade in Europe and only a couple years ago in the US

a couple old posts on single-use/one-time account numbers
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm21.htm#18 'Virtual Card' Offers Online Security Blanket

and for drift ... several posts on one-time passwords ... similar
countermeasure to evesdropping/harvesting and replay attacks
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#46 What 'NSA'?
http://www.garlic.com/~lynn/2003p.html#10 Secure web logins w random passwords
http://www.garlic.com/~lynn/2005f.html#40 OTP (One-Time Pad Generator Program) and MD5 signature
http://www.garlic.com/~lynn/2005i.html#50 XOR passphrase with a constant
http://www.garlic.com/~lynn/2005l.html#8 derive key from password
http://www.garlic.com/~lynn/2005o.html#0 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#31 Looking for Information on password systems
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006k.html#28 Hashes and Passwords
http://www.garlic.com/~lynn/2006r.html#38 Trying to underdtand 2-factor authentication
http://www.garlic.com/~lynn/2006u.html#4 ssh - password control or key control?

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 10:56:47 -0700

krw <krw@att.bizzzz> writes:

If you want to get literal about it, 370s don't "boot" at all.  The
processor doesn't pick itself up by its bootstraps, rather the
service processor initializes the processor, memory, and I/O.
There is a *lot* of stuff that goes on at IMPL.  Loading microcode
and the OS is a small part of the process.

for some drift ... service processor came into existence to satisfy
field engineering requirement to be able to have a field service
"bootstrap" diagnostic process ... starting with being able to scope
"failed" components. starting with 3081, it was no longer possible to
scope the components. so they built in a "service processor" with lots
of probes to numerous parts of the system. the FE could scope the
"service processor" (if it was failing) and then use the "service
processor" to diagnose the real machine.

for 3090, the service processor was going to be a 4331 running a
highly modified version of vm370 release6; the FE could scope the 4331
and then use the 4331 to diagnose the 3090. before shipping, this was
replaced with a pair of 4361s (still running vm370); the FE no longer
needed to bootstrap scope the service processor (to diagnose a service
processor failure) ... because there was a spare service processor.

at the time, i wasn't paying a lot of attention on packaging so i'm
not sure of how much repacking went on for the 4331/4361 to use it as
3090 service processor ... and whether any of that repacking was
involved in creating 37t (a deskside 370) ... recent post
http://www.garlic.com/~lynn/2007c.html#14
with old email that mentioned the 37t
http://www.garlic.com/~lynn/2007c.html#email850712

and, of course, misc. past posts mentioning "service processor"
http://www.garlic.com/~lynn/96.html#41 IBM 4361 CPU technology
http://www.garlic.com/~lynn/99.html#61 Living legends
http://www.garlic.com/~lynn/99.html#62 Living legends
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#26 Superduper computers--why RISC not 390?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001h.html#2 Alpha:  an invitation to communicate
http://www.garlic.com/~lynn/2001j.html#13 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2002.html#45 VM and/or Linux under OS/390?????
http://www.garlic.com/~lynn/2002b.html#32 First DESKTOP Unix Box?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#19 What goes into a 3090?
http://www.garlic.com/~lynn/2002i.html#79 Fw: HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#28 ibm history note from vmshare
http://www.garlic.com/~lynn/2002l.html#7 What is microcode?
http://www.garlic.com/~lynn/2002l.html#10 What is microcode?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002q.html#53 MVS History
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
http://www.garlic.com/~lynn/2003l.html#12 Why are there few viruses for UNIX/Linux systems?
http://www.garlic.com/~lynn/2003l.html#62 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003n.html#17 which CPU for educational purposes?
http://www.garlic.com/~lynn/2004.html#10 Dyadic
http://www.garlic.com/~lynn/2004.html#11 Dyadic
http://www.garlic.com/~lynn/2004j.html#45 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004k.html#37 Wars against bad things
http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004p.html#27 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2004p.html#36 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#37 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#41 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005b.html#51 History of performance counters
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005t.html#39 FULIST
http://www.garlic.com/~lynn/2006.html#0 EREP , sense ... manual
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape
http://www.garlic.com/~lynn/2006n.html#6 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#8 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006r.html#27 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006x.html#24 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007.html#18 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007.html#24 How to write a full-screen Rexx debugger?
http://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#15 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#30 How many 36-bit Unix ports in the old days?

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 11:10:30 -0700

jmfbahciv writes:

None of this helps.  My mother writes a check at the grocery store.
The first time she wrote one, it took minutes to "clear" it.  Now
it takes no time to clear it.  I am assuming this is because
the store has her banking information, along with an "OK" bit set.

It doesn't need a thief to really screw the banking system up.
Just one software or procedural hiccup will make a horrible mess.

systemic risk ... various types of failures or compromises that can
cascade and take down the whole system. some amount of worrying is
done about such things. there is old story about a situation in
(inter-bank) overnight settlement in Europe some years ago ... that
nearly brought down the whole infrastructure.

there was also big push in the mid-90s to convert fedwire (interbank
transfers ... including interbank overnight settlement) to digital
certificates ... one for each of the 30k some financial institutions.
one fedres governor came out strongly against ... at the time there
was going to be a single certification authority ... and it was
pointed out if the certification authority was compromised ... then
all 30k digital certificates would instantly become invalid ... and at
the time it was estimated that it would take over three months to
re-issue all 30k digital certificates. systemic risk big time.

misc. past posts mentioning systemic risk
http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your account-authority model (small clarification)
http://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue
http://www.garlic.com/~lynn/aadsmail.htm#parsim parsimonious
http://www.garlic.com/~lynn/aadsmail.htm#mfraud AADS, X9.59, security, flaws, privacy
http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against Virtual Banks (fwd)
http://www.garlic.com/~lynn/aepay2.htm#fed Federal CP model and financial transactions
http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital Signatures ... in support of x9.59
http://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation.
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech7 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aepay10.htm#13 Smartcard security (& PKI systemic risk) thread in sci.crypt n.g
http://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
http://www.garlic.com/~lynn/aadsm10.htm#smallpay2 Small/Secure Payment Business Models
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/99.html#156 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#31 You think? TOM
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
http://www.garlic.com/~lynn/2003l.html#64 Can you use ECC to produce digital signatures?  It doesn't see
http://www.garlic.com/~lynn/2003m.html#11 AES-128 good enough for medical data?
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2004j.html#5 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
http://www.garlic.com/~lynn/2005i.html#11 Revoking the Root
http://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006n.html#28 Key exchange

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 11:44:25 -0700

jmfbahciv writes:

The only way to plug up the hole that's been made is to have
a voucher (a.k.a. check) match each posting.  Nowadays, posting
the payments no longer needs an accompanying piece of paper.
So any repetition done at current CPU and comm speeds can't be
stopped.

there is actually a mechanism built into much of the infrastructure
that is left over from days of lots of dropped lines and/or
communication glitches ... when it was common for clerks to reswipe
the card when they didn't get the expected ACK. they built in stuff
that would reject duplicate transactions that occurred in period of
several minutes (up to something like 20 minutes). it has been known
to catch situations involving valid duplicate transactions. A person
purchases one item of something and then with 5-10 minutes decides
that they want a second.

however, as previously detailed ... most attempts doing that
fraudulently at the originating merchant are quickly caught and the
merchant dealt with (as part of transaction fraud detection software).
as a result most of the harvesting/skimming attacks involve taking
acquired account numbers and performing fraudulent transactions as far
away from the original compromise (merchant) as possible.
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007

original post in this thread with news URL article about existing operations
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007

and other recent posts with news URLs about existing operations
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007
http://www.secureidnews.com/news/2006/12/22/securing-financial-transactions-a-high-priority-for-2007/
Encryption a perfect response to the Year of the Breach
http://scmagazine.com/us/news/article/623768/encryption-perfect-response-year-breach
Bots, breaches and bugs plague 2006
http://www.securityfocus.com/news/11432
By the numbers: A dismal year for data breaches
http://blogs.zdnet.com/BTL/?p=4169
VanBokkelen: 2006: The year of the breach
http://www.fcw.com/article97098-12-18-06-Print
Personal data security breaches hit 100 million milestone in US
http://www.finextra.com/fullstory.asp?id=16296
An Ominous Milestone: 100 Million Data Leaks (data breach)
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=22030
100m US records exposed by security blunders
http://www.theregister.com/2006/12/18/data_breach_milestone/
100 Million Victims of Data Theft (data breach)
http://it.slashdot.org/it/06/12/17/2214219.shtml
Boeing laptop theft puts U.S. data breach tally over 100M
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9006140&intsrc=hm_list
The Corrosive Siege Over Signature-Card Interchange
http://www.digitaltransactions.net/newsstory.cfm?newsid=1223
Retail security breach may be biggest in U.S.
http://www.iht.com/articles/2007/01/19/business/data.php
TJX Hack Highlights Payment Information Insecurity
http://www.informationweek.com/showArticle.jhtml;jsessionid=MFDDZSZDTWEVAQSNDLRCKHSCJUNN2JVN?articleID=196902075

now while credit cards and signature-debit cards appear to operate
almost the same ... there is some amount of difference between the
backend when fraud occurs. in the case of credit, none of your money
actually disappears. a couple past posts
http://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 13:52:38 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

this email is from the palo alto group that was doing the work on BSD
port for 370 (and trying to get me into trouble). This never actually
shipped, since they were eventually directed to retarget the BSD port
for PC/RT (801/romp) which was announced as "AOS".  old bsd/aos post
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ....
http://www.garlic.com/~lynn/2004f.html#44 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal R&D

re:
http://www.garlic.com/~lynn/2007c.html#14 How many 36-bit Unix ports in the old days?

and earlier ref ...


From: wheeler
Date: 08/03/83 14:17:32

just got back from 3 weeks vacation, have i missed much? Got a notice
that there is a Berkeley joint study. Been invited to meeting next
week in Palo Alto on the 9th and the following day In Berkeley on the
10th.

... snip ... top of post, old email index

above references kick-off for the bsd/370 effort which was later
retargeted to pc/rt (announced as AOS)

and ...


From: wheeler
Date: 08/03/83 14:36:36

XXXXXX from the branch office is attempting to set up a meeting with a
guy from Univ. of Santa Cruz who is responsible for specifying the
computers for the new 400in telescope that will be in Hawaii. There
will be computers at Hawaii and data will be shipped back to Santa
Cruz for processing on local computers there.

... snip ... top of post, old email index

misc. past posts with references to the effort:
http://www.garlic.com/~lynn/2004h.html#7 CCD technology
http://www.garlic.com/~lynn/2004h.html#8 CCD technology
http://www.garlic.com/~lynn/2004h.html#9 CCD technology
http://www.garlic.com/~lynn/2005l.html#9 Jack Kilby dead
http://www.garlic.com/~lynn/2006t.html#12 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)

and meeting conflict with 801 chip cache design meeting


From: wheeler
Date: 08/04/83  01:21:13

just realized that i may have gotten myself in a bind. CPU(801) cache
design meeting is in Los Gatos next week at the same time as the Palo
Alto/Berkeley UNIX meetings.

... snip ... top of post, old email index

index to old email mentioning 801, romp, etc
http://www.garlic.com/~lynn/lhwemail.html#801

and collected old posts mentioning 801, romp, rios, pc/rt, rs/6000, power/pc,
etc
http://www.garlic.com/~lynn/subtopic.html#801

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 16:32:09 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

just got back from 3 weeks vacation, have i missed much? Got a notice
that there is a Berkeley joint study. Been invited to meeting next
week in Palo Alto on the 9th and the following day In Berkeley on the
10th.

re:
http://www.garlic.com/~lynn/2007c.html#19 How many 36-bit Unix ports in the old days?

more trips down nostalgia lane ..


From: somebody in disk product test lab (bldg. 15)
To: wheeler
Date: 4 August 1983, 15:05:24 PDT

Lynn; Glad to see you back from vacation. Hope you had a good time. If
you are in the mood for looking at dumps, I have a PROG5 that occurs
after an interface control check. We end up with a director in status
pending, trace shows cu busy followed by cu end on a specific
address. (what happened to your fix for this problem?) We hang and end
up having to stop the cpu and clear the 3880. Then we blow with a prog
5 in DMKDAD. Device which is having problem is a 3380 on a different
channel than the original hang. MIH is invoked and the trace shows a
dummy interrupt on the 3380. DAD picks up RDEVIOB which has been
nicely filled in to read "FREE" and blows the first time he tries to
use the address. I suspect FRE but could see no place in trace table
where we freted the rdevblok.  Dump is 1132. I backed off the latest
IOS change as I ran into same IOS11's.  How were the mountians?

... snip ... top of post, old email index

i.e. a bug in bldg. 15 vm3033 system that occurred while i was on
vacation.

a little more about meeting conflicts with 801 hardware cache design
and bsd meetings ... as well as (what is now called) Keck 10meter
telescope


From: wheeler
To: somebody at Palo Alto science center
Date: 08/04/83  22:27:33

... will try and make meeting on Tuesday ... have a hardware cache
design meeting in Los Gatos on Tues, weds. & thurs ... will try and
work something out.

Was on vacation until yesterday.

Was talking to XXXXX yesterday ... he says that you have two VAXs
somewhere around.

I was contacted by branch office about something to do with professor
at Santa Cruz selecting computers for 400in telescope to be placed in
Hawaii (he was interested in getting a meeting specifically to talk
about shipping data between Hawaii and Santa Cruz ... hyperchannel and
satellites). I also suggested that science center might have somebody
interested in the subject. He was going to contact XXXXXX and may have
meeting either up there or at research.

... snip ... top of post, old email index

some amount of the Keck 10meter telescope effort was because of our
HSDT activity with T1 and higher speed transmission links (both
terrestrial and satellite)
http://www.garlic.com/~lynn/subnetwork.html#hsdt

ref: previous email
http://www.garlic.com/~lynn/2007c.html#email830803b

we were dealing with some amount of satellite capacity (in addition to
terrestrial connections). satellite broadcast intrinsically looks a lot
more like LAN infrastructure ... and TDMA satellite is somewhat
analogous to token-ring. I had been doing dynamic adaptive resource
allocation for some 15 years at this point ... so I figured I could
design a different satellite adapter interface that looked a lot more
like a LAN interface (for computer operation ... rather than
full-duplex terrestrial link) ... and effectively provide adjusted
on-demand bandwidth at the (satellite) super-frame boundary.

in the case of Hawaii to Santa Cruz ... the operation could even look
a lot more like current satellite TV ... (data channel) broadcast
signal from Hawaii with terrestrial telco control channel (1200baud
looked like it might even be sufficient). the possibility was to even
allow simultaneous reception for more than one downlink at a time.

... and then to time slicing between cache design and bsd/370 ...
status on palo alto BSD meeting ... i.e. previous email


From: wheeler
Date:  08/09/83  20:54:18

XXXXXX wants to put up a UNIX 4.2 as soon as possible ... something
executing by next spring so that it could be in the hands of 2-3 early
test sites by summer for review. I had to leave early to get to the
los gatos meeting so not sure what else went on.

Both YYYYYY & I (and possibly others) have suggested that going with
multiple address space CP mods (even if they are identical to the
Cambridge mods. and if they have already been shipped) may not be
feasible for him ... just because of the magnitude of the 4.2 hits to
support/use such a design. It doesn't look like that much can be done
other than 370 port ... preserving kernal design supporting running on
one machine with one real storage space.

There will be a meeting tomorrow in Berkeley and then two week joint
design review in Berkeley scheduled for Sept.

... snip ... top of post, old email index

and more on the bsd/370 design and possible requirement to effectively
add smp support to bsd.


From: wheeler
Date: 08/10/83  08:28:34

re: vm/unix; i'm equating the multiple virtual machine approach
logically to upgrading the unix kernal to supporting real
multi-processors when running native. I may be mis-understanding.
Porting to 370 native (or single virtual machine) would require
changes for the implementation of the hardware ... but the logic flow
thru the kernal should pretty much remain the same. There appears to
be a delta change to support multiple virtual machines comparable to
the serialization problems encountered when moving a operating system
from a UP implementation to MP implementation (i.e. on a native-UP,
the unix kernal is going to be aware of the exact sequence execution
of all events ... and the possibility exists that there are
dependencies because of the predictable sequence ... not sure what the
effect might be if VM pre-empts execution in a critical section).

My guess is purely hypothetical, YYYYYY would know more about any such
potential exposures requiring additional logic &/or design changes to
4.2 (if any).

... snip ... top of post, old email index

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 09:12:53 -0700

Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:

On IBM systems, cold and warm did not apply to the state of the
processor prior to the OS load, it was an option given to the OS which
implied that system areas were reinitialized as if the system had just
been installed, so crash, error, paging, spool, swap, and similar areas
were wiped, or treated as such.

VM spool file system had cold, warm, and chkpt. Cold and Warm were
originally part of cp67. warm was dependent on their being a clean
shutdown (or a system failure that would save spool file information
along with image of real storage). chkpt was added in vm370 ... but it
was sort of like (unix) fsck on restart ... it involved periodic chkpt
(somewhat like journaled file system) which was read on recovery
... but then it required reading each spool file serially, one at a
time. this was all processed before system was up and running (and
users could log on or other processing could start) if warm failed
(like a power outage), and forced to go to chkpt ... a large system
could be unavailable for upwards of an hour doing this process.
normal system failure with warm restart would fail and re-ipl and
automagically be back up and running within a couple minutes.
description comparing this to multics
http://www.multicians.org/thvv/360-67.html

The chkpt operations also impacted the total number of spool files
(new/create and old/delete) that could be processed per second.

The problem for HSDT
http://www.garlic.com/~lynn/subnetwork.html#hsdt

in conjunction with (internal network) VNET operations
http://www.garlic.com/~lynn/subnetwork.html#internalnet

was chkpt (and some other serial spool file processing) significantly
impacted the aggregate thruput thru a network node ... typically
capping things around 5-8 4k blocks/sec (20k-30k bytes/sec). That
wasn't much of an issue with 9.6kbaud lines ... but it really was
issue with multiple full-duplex T1s (needing aggregate thruput of
mbyte/sec or more). While the "official" corporate vnet backbone nodes
weren't hitting the HSDT thruput, there were having significant
thruput problems with the standard implementation


From: wheeler
To: distribution (including corporate vnet backbone support staff)
Date: 04/16/86  15:37:05

re: sbf update; I'm going to merge the four levels of SBF updates into
a single level for distribution ... and at the same time no-op a
couple of the debug checking abends (we haven't been having any ...
but there is an abend check for all zero CCPD pointer ... it is
possible under certain spool DASD I/O errors, that would ordinarily
result in aborting the processing of that particular spool file ...
for the CCPD pointer to be zeros ... the debug check would cause the
system to fail in an otherwise recoverable situation).

... snip ... top of post, old email index

I had done spool file system rewrite in several stages ... 1) a whole
bunch of updates that left the basic spool file processing in the
kernel ... but significantly improved the aggregate thruput and 2) a
complete rewrite in vs/pascal that moved spool file processing out of
the kernel into a virtual address space.


From: wheeler
To: corporate vnet backbone support staff
Date: 04/17/86  08:50:45

re: sbrmisc; all the normal PID code appears to ignore the SBRMISC
field when reading a file. When creating a file, everyone clears the
field to zeros .... and standard spool file processing then stuffs in
the pointer to the first block of the file ... while monitor,
accounting, etc leave it zeros.

I've added code to the multiple buffer diagnose read code that
validates the SBRMISC field when processing a file ... to make sure
there aren't any bugs in the spool file system. I believe I've cleaned
up the abends ... if the field is incorrect and just terminate
processing the file .... but I haven't recently had an opportunity to
test the code.

As long as you don't process a accounting/monitor/etc. spool file
(from a non-SBF system) with standard diagnose 14 (on a SBF system)
then there should be no problem. The other way around should also be
no problem because normal reads and diag. 14 reads ignore the field.

It would appear that the original design of the spool file system
might of included some provision for later addition of code that would
use the SBRMISC field pointer back to the first record ... but they
never got around to implementing it. The "specialized" spool files
(accounting, monitor, VMDUMP, etc.) were all added after the initial
implementation ... and they apparently ignored and/or never crossed
their minds to preserve the SBRMISC convention since it wasn't
documented and nobody used it.

... snip ... top of post, old email index


From: corporate vnet backbone support staff
To: wheeler
Date: 18 April 1986, 08:13:58 EST

Hi,

The CP turbo spool mods are running on VNETCMC since this morning.  No
problem so far (I didn't expect any).

Will start putting them up on *GATE machines some time next week.

... snip ... top of post, old email index

corporate backbone support starting to refer to the initial set of
changes as "turbo".


From: wheeler
Date: THU, 01/08/87 11:18:26 PST

re: hsdt-sfs;

The work on the proto-type spool file system progresses again ...
after being side-tracked to investigate peculiar operational
performance characteristics of 3380s when operating at 400-550 page
transfers per second.  I also shipped SFSPTAPE (CP SPTAPE DUMP
emulator) that supports both PAM and pid-3380 configurations.

The access/start-up of the hsdt-sfs spool file disk is working
reliably and reasonably fast (still some unanswered questions about
3380 performance at 500+ page transfer per second).  hsdt-sfs can
import spool files from any PID spool file system that it has DASD
access to (i.e. either from the same system or different systems).
I'm now starting working on the IUCV interface to support standard PID
cp spooling commands and read/writing of spool files.

Currently, hsdt-sfs uses four 4k buffers when processing spool files.
On spool file output, the 4 4k blocks are configured as a pair of 8k
buffers, with spool disk i/o writes overlapping spool buffer
processing.  On spool file input, processing attempts to read 16k from
the spool disk at a time.

hsdt-sfs eliminates the standard CP checkpoint record and replaces it
with spool file descriptor records, or SFFR (spool file first record).
Packed into the SFFR is a copy of the SFBLOK, index pointers to data
records in the spool file and possibly spool file data (in the case of
a spool file <3000 bytes all data and control information is packed
into the SFFR record).

... snip ... top of post, old email index

Part of the complete rewrite, eliminated the old "chkpt" process and
effectively made each spool file record self-describing. The rewritten
startup chkpt process would start reading the spool file areas a
cylinder at a time (reading whole tracks in one operation) and
building up current, valid files. This would process at nearly four
3380 cylinders/sec ... a dedicated 3380 spool pack in a little over 200
seconds ... and it could process multiple 3380 spool packs in
parallel.

old posts on the complete hsdt-sfs rewrite (in vs/pascal)
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2001n.html#7 More newbie stop the war here!
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004p.html#3 History of C
http://www.garlic.com/~lynn/2005d.html#38 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 10:37:58 -0700

jmfbahciv writes:

At the moment, I'm not as concerned about the money disappearing.
The problem is the amount of calendar-time it would take to
get an account straightened out.  Consider people who live on
a marginal income and don't have pots of money in other accounts.
My parents, as most oldsters who were green and blue collar workers,
are in this situation.  Any delay of access to money is serious
in their life-style.

re:
http://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007

what i'm looking at is the difference in probability of fraud occurring
in various ways and the number of people it might impact as well as
the aggregate impact. Furthermore, if it is possible to significantly
alter the major threats, it would leave more resources left to address
threats that have less aggregate impact.

somebody capturing a file with 50million accounts ... and hitting
several million of those accounts (and may never get caught)
... vis-a-vis a merchant site that submits some number of (fraudulent)
duplicate accounts ... it is recognized within 24hrs, has them
reversed, and the merchant has card processing turned off.

the probability of a merchant doing something like that is further
reduced by the prospect that it will almost always be quickly
recognized and they would not be able to actually enjoy any of the
benefit of the fraudulent activity. crooks tend to go for exploits
where they are much more anonymous ... making it harder to connect
back to them.

however, it is possible to come up with serious individual impact for
almost any kind of scenario ... and if you pick something that has
frequency ... say on the order of injury/death motor vehicle accident
... then the impact on victim of injury/death (and the probability)
would make a case for banning all motor vehicles and eliminating all
alcohol sales.

another scenario was I was asked to give keynote on identity
theft a couple years ago at large annual industry conference
... the talk was on the systemic issues related to identity
theft and how to improve the overall environment. however, for the
most part, the only audience questions were from individuals who were
personally experiencing identity theft (and how could they
recover) ... and little or nothing about the systemic issues.

A side issue is that both account fraud (doing fraudulent transactions
against existing accounts) as well as identity fraud (opening new
accounts or other types of new activity involving impersonation) ...
are typically lumped together under identity theft.

further drift, past posts mentioning motor vehicle accidents (usually
related to comparisons with other types of exploits/vulnerabilities)
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights   and traffic enforcement
http://www.garlic.com/~lynn/2003m.html#17 Throughput vs. response time
http://www.garlic.com/~lynn/2003o.html#25 Any experience with "The Last One"?
http://www.garlic.com/~lynn/2004c.html#36 If there had been no MS-DOS
http://www.garlic.com/~lynn/2004j.html#29 Vintage computers are better than modern crap !