The Risks Digest, Volume 23, Issue75

Peter G. Neumann

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 23: Issue 75

Thursday 24 February 2005

Networked homes spell trouble for consumer electronics: NewsScan
Spam-blocker causes missed court date: Terry Carroll
UK gets official virus alert site: Chris Leeson
SPIM: NewsScan
More robot scanner phenomena: Mark Rockman
Re: Component Architecture: Martyn Thomas
Peter B. Ladkin
Jay R. Ashworth
Mike Ellims
Daniel P. B. Smith
Ben Galehouse
Roderick A. Rees
David G. Bell
Raj Mathur
Re: Urology medical student residency "matching" process failure: Jerry Leichter
Re: Assuming customers can't spell: Tom Russ
IWIA 2005 Call for Participation: Stephen D. B. Wolthusen
Info on RISKS (comp.risks)

Networked homes spell trouble for consumer electronics

<"NewsScan" <newsscan@newsscan.com>>

Thu, 24 Feb 2005 10:32:31 -0700


The vision of the "networked home" is driving the digitalization of nearly
every consumer electronics device, and eventually could lead to the
disintegration of the consumer electronics industry as we know it, says
Columbia University public policy expert and economist Eli Noam. Caught in
the upward spiral of Moore's Law, the chips that run consumer electronics
devices will become evermore powerful, and many stand-alone products, such
as Blu-Ray Disc players, TVs and PCs, could entirely "disappear," says
Noam. In fact, it's already happening: consumer PCs now come with built-in
TV and recording functions, and vendors are selling DVD, CD and VHS players
packaged as single units with hard disk drives. And while Noam predicts a
bonanza for consumer electronics makers in the near term -- the next seven
years or so -- ultimately, many of the networked products will be replaced
by a single box or hub. "The good news is that this will mean an initial
spike in demand for makers. But it also means fewer hardware boxes being
sold," says Noam. As the trend continues, and consumers demand easy-to-use
and glitch-free home networking, a new breed of specialized services, called
CSPs (Consumer Electronics Service Providers), could emerge, who would
integrate home, community and work-based networks, providing services based
around content provision, security and assurance.  [*ComputerWorld*, 16 Feb
2005; NewsScan Daily, 24 Feb 2005]
  http://www.computerworld.com/managementtopics/management/itspending/story/0,10801,99821,00.html?source=x10

Spam-blocker causes missed court date

Wed, 23 Feb 2005 11:54:28 -0800 (PST)


"A plaintiff's attorney in a wrongful-death lawsuit, who missed a court
date because his firm's spam blocking software automatically sidetracked
the court's e-mail notice, has narrowly escaped being sanctioned for
failing to appear at the scheduled status conference...."

http://news.lp.findlaw.com/andrews/pl/med/20050223/20050223barnes.html

UK gets official virus alert site (BBC News)

<"LEESON, Chris" <chris.leeson@atosorigin.com>>

Thu, 24 Feb 2005 10:04:22 -0000


The UK government is setting up a Virus Alert site to warn users of viruses,
vulnerabilities and so on. It is aimed at home and small business users.

http://news.bbc.co.uk/1/hi/technology/4291005.stm

It is expected to issue between six and ten alerts a year, concentrating on
the most major problems. It will not provide patches, but will point the
user to where the patches can be downloaded. It is also made clear that the
site is not a panacea or a substitute for proper AV and Firewall provision.

Similar schemes exist in the USA and Netherlands.

This looks like a very good idea, and I applaud the government for doing it
(something that I do not do often). Alas, there remains a number problems:

1. This would be a great site for the Malware Brigade to spoof. I hope that
   it is more secure than most Web Sites.

2. They are concentrating on the most serious threats.  Understandable, but
   even the "less serious" threats can be trouble.

3. Most PC users are simply not interested in PC Security and won't be
   convinced that they have to be. The new users may well not realise that
   they are exposed at all. (I am a little sore about this having just spent
   three days trying to salvage someone's XP system after the PC had spent
   two weeks on Broadband without Firewall or AV...)

SPIM

<"NewsScan" <newsscan@newsscan.com>>

Tue, 22 Feb 2005 10:02:43 -0700


Battling the spim-meisters

Almost one in three instant-messaging users in the U.S. have received
some kind of "spim" (unsolicited commercial instant messages), according to
a survey by the Pew Internet & American Life Project. Results indicate that
users age 30 and younger are more likely to get spimmed, compared with the
next older age cohort (31-49). Other than the age discrepancy, however, no
other demographic trends were discernible, says Pew: "Instant message users
in all income brackets and in all racial and ethnic groups are equally
likely to receive spim. Somewhat surprisingly, broadband users at home are
no more likely than dialup users to receive spim, even though, presumably,
those with always-on broadband connections keep their instant message
programs running for longer periods of time than dialup users." The survey
found that 52 million Americans -- 42% of the online population -- use
instant messaging, and among the 30-and-under age group, it's 66%.  [Pew
Internet & American Life Project, 21 Feb 2005; NewsScan Daily, 22 Feb 2005]
  http://www.pewinternet.org/PPF/p/1052/pipcomments.asp

First spimmer arrest

An 18-year-old New York teenager has become the first person to be arrested
on suspicion of spimming. Anthony Greco allegedly sent 1.5 million messages
hawking pornography and mortgages to users of MySpace.com's IM system, and
was arrested in a sting operation in the Los Angeles Airport last Wednesday
following an extortion attempt on his part. Greco believed he was flying to
LA to seal a deal with the president of MySpace.com, whom Greco had
threatened with publicizing his spim techniques if he were not granted an
exclusive marketing arrangement that would have legitimized his spimming
activities. Assistant U.S. Attorney Brian Hoffstadt says that while Greco's
case marks the first criminal prosecution of instant message spamming, there
may well be more to come: "We're just beginning to get the tip of the
iceberg. This could be a new wave as online communities start up."  [CNet
News.com 21 Feb 2005; NewsScan Daily, 22 Feb 2005]
  http://news.com.com/U.S.+makes+first+arrest+for+spim/2100-7355_3-5584574.html

More robot scanner phenomena

<"Mark Rockman" <mrockman@acm.org>>

Sat, 12 Feb 2005 21:19:33 -0500


Twice in one week I've tried to use a robot scanner only to find it is stuck
at the "FINISH AND PAY" node of the transition diagram.  The bagging area
has nothing in it.  There is no customer around, except me.  Conclusion:
shopper rang up the goods, bagged them and left.  Result: merchant is
stiffed for $17.49, an innocent customer could be accused of having rung up
the goods and hid them, and WORST, the lane is out of service until a
manager becomes aware of the situation minutes or hours later and overrides
the computer.  Does the robot notice time passing at the FINISH AND PAY
node?  It does not.  Shouldn't an alarm go off?  I think so.

Re: Component Architecture (Blaak, RISKS-23.74)

<"Martyn Thomas" <martyn@thomas-associates.co.uk>>

Wed, 23 Feb 2005 21:35:30 -0000


Well, I know one company that is willing to offer warranties on its
software, free, because it uses a "Correct by Construction" approach that
reduces the commercial risks to acceptable levels. They don't charge more
for the development, either, because it doesn't cost them any more to work
this way than industry norms.

The company is Praxis High Integrity Systems: www.praxis-his.com .

And no - I don't have any financial links with them, although I did co-found
a predecessor company.

Re: Component Architecture (RISKS-23.74)

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>

Thu, 24 Feb 2005 08:15:18 +0100


I was surprised to find little of the extensive commentary on Robinson's
essay directed at his premise. (Stephen Bull and George Jansen addressed the
premise en passant.)

The premise is obviously false, as points 1-4 below note.

1. I would hazard a guess that most software development in the world (in
   terms of effort) is directed towards modifying already existing software,
   and comparatively little of it towards developing source code from
   scratch in a common programming language.

2. It has been standard knowledge in the industrial SW development world for
   the two decades I have been working in and around it that between 60%
   (Putnam, 1978) and 80-90% (Balzer, Cheatham, Green, 1983) of software
   development lies in "maintenance", that is, modifying already existing
   SW. (Boehm 1987 put TRW's effort at 67%.) So in simple terms of level of
   effort, most of the effort even in "from-scratch" SW systems does not go
   into the initial coding, but into modification of existing systems.

3. The work of many large companies offering SW-based systems is better
   described as configuring existing systems, or building on a base of
   existing SW. Air traffic control system providers spend considerable
   development effort on each new installation. Much of that effort is spend
   configuring their already-existing SW to the specific ATC center airspace
   architecture, and modifying it to attain client requirements.  The NERC
   in Swanwick, U.K., presented as the largest system of its kind, used,
   roughly, 50% of its code from a common core (~1M LOC) and 50% as local
   adaptation. (The "common core" ended up not being all that common: the
   U.S. FAA's AAS, which also was to be based on it, was canceled.) The
   business of two of the world's largest SW system providers, Oracle and
   SAP, is better described not as building systems from scratch but as
   configuring extensive existing SW systems to a client's particular needs.

4. Trucking companies, at least in Europe, buy their enterprise SW from, for
   example, a SAP-approved company which has adapted SAP's enterprise SW for
   trucking company business. Or from one of SAP's competitors such as
   PeopleSoft.

Much of the rest of the commentary points out why configuring existing SW
systems to a new application is not that easy. That accounts for why most of
SW development effort goes there.

Peter B. Ladkin, University of Bielefeld www.rvs.uni-bielefeld.de

Re: Component software edition (RISKS-23.75)

<"Jay R. Ashworth" <jra@baylink.com>>

Wed, 23 Feb 2005 16:10:19 -0500


I found it telling about the RISKS audience that only my submission, and
that of George Jansen, said, in effect, "But we're *doing* that already";
that seemed the fundamental point of Paul's original contribution, and I was
surprised that so few of the other categories of responses you selected made
the appropriate rebuttal.

Was the percentage of replies that *did* rebut his point proportionately
that small, or did you just filter harder there?  [YES, NO, respectively.
No filtering.  I am running almost every reply except for overt dupes.  PGN]

Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA
http://baylink.pitas.com  +1 727 647 1274  jra@baylink.com Baylink

Re: Component Architecture (Robinson, RISKS-23.73)

Thu, 24 Feb 2005 16:39:34 -0000


George Jansen introduced the kitchen programming paradigm; the house
programming paradigm was introduced in the following paper a couple of years
back.

  Robert Biddle, Angela Martin, James Noble: No name: just notes on software
  reuse. OOPSLA Companion 2003: 240-260

It provides an interesting take on the construction parts bin and the
literary history of software reuse.

Here's an observation, if the construction/civil engineering industry is so
good at reuse. Why is there such a large market for sticky gunk for
gluing/filling and otherwise concealing.  Where would the construction
industry be without "No More Big Holes" (expanding foam in a tube) or
PolyFiller?

Mechanical engineering has it's standard components, nuts, bolts, screws,
nails etc. Just as we have some as well, languages, editors, protocols etc.
The point being missed in arguments like the one Robinson puts forward, is
that it ignores the fact that in any system of sufficient complexity -
nearly everything else is bespoke design.

How many standard components are there on an F22?

Re: Component Architecture (RISKS-23.73)

<"Daniel P. B. Smith" <dpbsmith@verizon.net>>

Wed, 23 Feb 2005 19:34:07 -0500


Who says the parts are interchangeable?

Paul Robinson has the silver bullet, and it is software components.  Right.

One of the things I learned from a talk by Tom Love, circa 1991, on software
components, was that Eli Whitney's mass-produced parts were not, in fact,
interchangeable (even though that was the basis on which he had gotten
Congress to fund his factory).

And so it is with software parts.

Circa 1998, a program I had written, which had been shipping for years,
developed a very odd bug.

It turned out to be an error in the vendor's C library implementation of
strcmp.

It had some clever-clever optimizations so that it could perform the bulk of
the comparison by four bytes at a time. And a number of different logic
paths to avoid setting up a zero-count loop if the transfer was less than
five bytes long. And some special cases depending on the relative alignment
of each of the comparand's addresses with a four-byte boundaries. One of the
cases happened to misbehave if a character at one particular position in the
string happened to be in the upper byte range (128 to 255, high bit
set). (And for the record, yes, the documentation for strcmp does define
what the behavior is supposed to be bytes in the upper byte range. And the
behavior wasn't consistent; comparing string A with strings B and C, where B
and C had identical contents but different placement in RAM, gave different
results).

I could have reported the bug to the vendor. As a matter of fact, I did. It
hasn't been fixed yet. (The development system was supposedly still being
supported but was nearing end-of-life and wasn't a very high priority).

Maybe I could have gotten on my high horse and returned the compiler to the
vendor and insisted on our money back. But getting the product to compile
and build under another vendor's development system would have taken much,
much longer than that.

So I did what I truly believe to be the sensible thing: I wrote my own
implementation of strcmp. Wrote it to be as simple as it could possibly be
and to hell with efficiency. Unit-tested it. Carefully. With a test-case
generator that generated all sixteen cases of relatively alignment of
start-of-string to four-byte boundaries, and many combinations of upper- and
lower-byte characters. And put it into service.

strcmp is one of the most simple, basic, fully-documented, and
frequently-used "components" there is.

strcmp isn't an interchangeable part.

Re: Component Architecture (Robinson, RISKS-23.73)

Wed, 23 Feb 2005 10:56:42 -0500


I agree in many ways with Paul Robinson's comments. However, I think that it
is easy to underestimate the challenges involved. Mechanical engineers have
been held accountable (at least in a sense) for their engineering failures
since Hammurabi. Almost certainly, this cultural norm makes buildings
safer. However, it certainly doesn't make them perfectly safe.

Standardization and modularization is encouraged in the physical world
because specialized equipment greatly increases the efficiency of
construction for many products. The equipment needed to create a transformer
is rather different than that required to create a
capacitor. Standardization also makes warehousing and logistics easier.

These particular advantages either don't exist or aren't so obvious in the
computer realm. For these reasons, as well as for all of the reasons
typically mentioned for software, there are many standards for nuts, bolts,
steel, concrete, and so on.

As a result of this, nuts and bolts are rather standard. Or rather, nearly
all of them follow some standard or another. I'm told that some automobiles
have both metric and SAE bolts in them. You still need to know the model of
your automobile in order to order almost any part. Turnkey machine shops are
still in business. I've seen transformer companies specifically advertise
their willingness to wind custom transformers. Custom chip fabrication is no
small market.

Software engineering is a young field, and it shows. Modularization requires
interface standards and these are still being developed. Heck, even the
standards for presenting said interface standards seem to be under
comparatively active development.

It is easy to present modularization and formal methods as holy grail
solutions.  To be sure, they can yield big improvements. However, the
standards and modularization that we take for granted in the physical world
are the product of much evolution and no small amount of experience. Formal
methods played a part in this, but only a part.

Re: Component Architecture (Robinson, RISKS-23.73)

<"Rees, Roderick A" <roderick.a.rees@boeing.com>>

Wed, 23 Feb 2005 07:44:52 -0800


Paul Robinson ("In the Matter of Component Architecture") makes some proper
points, but there is something missing.  There actually are software
components that could be widely used -- such as those for straightforward
mathematics.  The reason for this, though, is that mathematics is
deliberately stripped of almost all meaning.  Bertrand Russell famously said
that it is the subject in which we never know what we are talking about nor
whether what we are saying is right.  The meanings and definitions of
mathematics are deliberately so limited, to minimise the possibility of
confusion, that in everyday human terms they are meaningless.

The problem with real and meaningful expression is that it is never fully
expressed or even fully conscious.  We always make a whole series of
assumptions, most of which are not explicit.  This leads to all the great
battles in theology and philosophy, because no two people are ever talking
about exactly the same thing, which is a direct consequence of the fact that
we never fully know our own assumptions.  All the great engineering
failures, where they were not the consequence of simple mistakes, were
caused by ignorance or neglect of physical realities.

In software we see this every day.  Several times a week I want to strangle
a programmer, because of the things he has assumed about the way other
people think.  He works on a process for months and is familiar with it, so
it all seems obvious to him; and then I am presented with a choice of A and
B, and have no idea what assumptions and consequences go with either of
them.  Or I make the right choice, but it does not work because - as I
eventually discover - he requires an updated version of one of my support
programs, which I can't get because my company did not know it existed.

There was an article in *New Scientist* some years ago called "Why Can't
You Program the VCR?" written by a professor of IT, who admitted that he
could not program the damned thing.  Designers' assumptions again.

If we are to get anywhere near producing useful software components beyond
mathematics, there will have to be a determined effort to uncover the
assumptions underlying the requirements, the programmers' training and
thinking, and the management control.  And who is going to pay for that?

Re: Component Architecture

<dbell@zhochaka.demon.co.uk ("David G. Bell")>

Thu, 24 Feb 2005 09:53:01 +0000 (GMT)


Computers and Standard Components

May I simply say that I fully support the well-deserved derision directed at
software producers who keep re-inventing the wheel wasting time, effort, and
what is ultimately *my* money as a purchaser.

One of the pioneering standards for interchangeable components, still in
use, is the Whitworth thread.  It is ironic that Mr. Whitworth was prompted
to devise the standard by the experience of working with Charles Babbage,
and the many nuts and bolts of his experimental mechanical computing
machines.

Some software I've used, the programmer needs something like a 15/16"
Whitworth spanner, applied cranially.

Re: Component Architecture (Kuenning, RISKS-23.74)

Thu, 24 Feb 2005 09:59:50 +0530


> ls -l | grep -v '^d' | awk '{total+=$5}END{print total}'

It works, yes, but not generally reusable.  You may be better off with:

  ls -l | grep -v '^[bcdps]' | awk '{total+=$5}END{print total}'

so you don't try to count sizes of devices, pipes and sockets.

Raj Mathur raju@kandalaya.org http://kandalaya.org/

Re: Urology medical student residency "matching" process failure

Sun, 20 Feb 2005 16:26:52 -0500


Daniel Kahn Gillmor (Risks-23.71) reports on a problem with the urology
medical studentmatch.  He points to the blog entry describing the problem:
  http://blogborygmi.blogspot.com/2005/01/selection-dysfunction.html
and quotes from it - leaving out the actual explanation:

  Upon careful review, we found that one of the criteria in the match was
  not applied correctly, causing some outcomes to be skewed.

While clearly a bug and embarrassment, it's hardly a deep problem with the
program.  If you optimize along an incorrectly-computed measure, the result
won't be right - but that's hardly a basis for criticism of the optimizer.

Mr. Gillmor complains that "the algorithms used in the match process [should
be] freely available".  They are: A single Google search followed by looking
at three pages leads to:

  http://www.nrmp.org/res_match/about_res/algorithms.html

(The mathematics of this were published years ago.  Basically, given a set
of preferences in each direction - application for program and vice versa -
there are exactly two "optimal" solutions, in the sense that for anyone to
improve his position by moving to lower-numbered position in his own
ranking, someone else would have to be moved to a higher-numbered position
by at least as much.  The two solutions differ in that one is at least as
good as the other - but may be better - from the point of view of all
applicants, while the other is at least as good from the point of view of
all programs.)

As to his other comments:

> So, why wasn't a human reviewing the results of the match for
> reasonableness before publication?

There are hundreds of people matched every year, apparently with little
complaint since the program was put in place (at least since my sister
entered her residency, which would be around 20 years ago).  In this case,
the error was blatant - some highly-rated programs weren't matched to anyone
- and indeed was caught within 3 days.  It's not clear that a subtle error
could be spotted by a human being.

> What safeguards are there on the data-entry step (since GIGO continues
> to apply)?  Why isn't there an audit process in place?

This doesn't appear to have been a data-entry error.  It's not clear what
should have been audited.

We'd all like systems to be perfect.  But the reality is that one has to
consider both the cost of the error and the cost of preventing it.  Both the
programs looking for applicants, and the applicants themselves, pay for this
service.  I can't right now find the cost - it may depend on the particular
match - but having watched people go through this process, I would not
expect it to be cheap.  How much extra would *you* pay to help eliminate
what appears to be a very rare error?

You might also want to look at

  http://medicalmatcherrors.blogspot.com/

(pointed to from the previous blog), and especially the first (well, only as
of when I looked) response.

I should point out that I have absolutely no connection with this process,
but I've always thought it was one of the more rational and, from what I've
seen, better run selection efforts.  I would have much preferred this kind
of thing to the college application process I went through in the late 60's
- a process that, from all reports, has gotten much more complex, difficult,
subject to "gaming", expensive, and unpredictable since!

Re: Assuming customers can't spell (Malakoff, RISKS-23.73)

Wed, 23 Feb 2005 11:28:33 -0800


On Change of Address Form Validation

Andrew Malakoff's experience with the change of address form may have had
another, and to my mind more likely, explanation than a spelling checker.  I
suspect that the address was, in fact, run through the US Post Office's
address canonicalization process.  This would seem to be a quite reasonable
validation step, since most businesses that send out mass mail (like
newsletters) have such software for checking and grouping mailings.
Changing the address to match what the Post Office expects seems to be the
right thing to do, even if the "official" spelling of street or place names
is not what the local actually use.

One could test this by going to the USPS web site and running the same
process on the address and see if the same thing happens:

  http://zip4.usps.com/zip4/welcome.jsp

For example, "123 west oak avenue" => "123 W OAK AVE"

IWIA 2005 Call for Participation

<wolt@igd.fhg.de (Stephen D. B. Wolthusen)>

Wed, 23 Feb 2005 15:04:56 +0100 (MET)


        Third IEEE International Information Assurance Workshop
              March 23-24, 2005 --- College Park, MD, USA
                         http://iwia.org/2005
                           Sponsored by the
       IEEE Computer Society Task Force on Information Assurance
                        in cooperation with the
      ACM Special Interest Group on Security, Audit, and Control

This third international workshop on information assurance pursues several
goals. One is the dissemination of research across the spectrum of
information assurance and the fostering of a scientific community working in
this field.  Another primary goal is to bring together researchers and
practitioners from both governmental, defense, intelligence, and civilian
areas and to stimulate discussions on current and future problems as well as
solutions.  The keynote talk will be given by Dr. Roger Schell.  For
information on the program, location of the workshop, accommodation and
registration please see http://iwia.org/2005.

General Chair: Jack Cole, US Army Research Laboratory, USA
Program Chair: Dr. Stephen D. Wolthusen, Fraunhofer-IGD, Fraunhoferstr. 5,
  64283 Darmstadt GERMANY +49 (0) 6151 155 539

Report problems with the web pages to the maintainer

Forum on Risks to the Public in Computers and Related Systems

Volume 23: Issue 75

Thursday 24 February 2005

Contents

Networked homes spell trouble for consumer electronics

Spam-blocker causes missed court date

UK gets official virus alert site (BBC News)

SPIM

More robot scanner phenomena

Re: Component Architecture (Blaak, RISKS-23.74)

Re: Component Architecture (RISKS-23.74)

Re: Component software edition (RISKS-23.75)

Re: Component Architecture (Robinson, RISKS-23.73)

Re: Component Architecture (RISKS-23.73)

Re: Component Architecture (Robinson, RISKS-23.73)

Re: Component Architecture (Robinson, RISKS-23.73)

Re: Component Architecture

Re: Component Architecture (Kuenning, RISKS-23.74)

Re: Urology medical student residency "matching" process failure

Re: Assuming customers can't spell (Malakoff, RISKS-23.73)

IWIA 2005 Call for Participation