RISKS Forum: Risks Digest 25.78

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Monday 14 September 2009  Volume 25 : Issue 78

ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
  <http://catless.ncl.ac.uk/Risks/25.78.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
South Africa's Telkom: For the Birds or Not For the Birds (Gene Wirchenko)
OLPC: Sic Transit Gloria Laptopi (jidanni)
Smart Cars? (Gene Wirchenko)
Boston city employees routinely deleted e-mail (D.Slack/M.Levenson via
  Monty Solomon)
Networks and Nationalization With Respect to Cyberwar
  (jidanni on Suresh Ramasubramanian)
Heavy Data Use Puts a Strain on AT&T Service (Jenna Wortham via Monty Solomon)
Snow Leopard: A gigabyte by any other name (Monty Solomon)
Humbert Humbert <heart> Fishfingers (Lee Rudolph)
Quantum Chip Helps Crack Code (Anne-Marie Corley via Monty Solomon)
Nonprofit for collecting info on SCADA & PCS security incidents
  (Stephanie Neil via PGN)
Utah Gets Tough With Texting Drivers (Matt Richtel via Monty Solomon)
Re: UK Chinook helicopters grounded for *years* (Peter Duncanson)
Bertrand Meyer, *Touch of Class*, Springer, 2009 (PGN)
Re: VA erroneously informs over a thousand vets (Alexandre Peshansky)
Interesting disclaimer added by my ISP to the latest RISKS (Glenn Chambers)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Fri, 11 Sep 2009 23:02:44 -0700
From: Gene Wirchenko <genew () ocis net>
Subject: South Africa's Telkom: For the Birds or Not For the Birds

You have probably read the April Fool's Day RFC 1149
(A Standard for the Transmission of IP Datagrams on Avian Carriers)
(available at http://www.rfc-editor.org/rfc/rfc1149.txt).

You may have read http://www.blug.linux.no/rfc1149/ which is about an
implementation of it.  Maybe they should try it in South Africa.  They
appear to have the hardware.

  A South African information technology company on Wednesday proved it was
  faster for them to transmit data with a carrier pigeon than to send it
  using Telkom, the country's leading [I]nternet service provider.  Internet
  speed and connectivity in South Africa are poor because of a bandwidth
  shortage.  The 11-month-old pigeon, Winston, took one hour and eight
  minutes to fly the 80 km from Unlimited IT's offices near Pietermaritzburg
  to the coastal city of Durban with a data card strapped to his leg.  In
  that time, just two per cent of the data was sent over the Internet."
  [Source: Pigeon Transfers Data Faster Than Internet Provider (Reuters),
  Kamloops This Week Daily (Kamloops, British Columbia, Canada), 2009-09-11
  issue, p. 4]

The joke used to be about the bandwidth of a station wagon full of magtapes,
and now, the hardware has been miniaturised to pigeon-size.  I am amazed at
the advances in computer technology.

  [Also noted by Matthew Kruk.  PGN]
http://au.news.yahoo.com/a/-/mp/6016150/pigeon-transfers-data-faster-than-south-africa-telkom/

------------------------------

Date: Sat, 05 Sep 2009 05:46:36 +0800
From: jidanni () jidanni org
Subject: OLPC: Sic Transit Gloria Laptopi

...there was no one hired to work on deployment while I was at OLPC, with
Uruguay's and Peru's combined 360,000-laptop rollout in progress. I was
parachuted in as the sole OLPC person to deal with Uruguay, and sent to Peru
at the last minute. And I'm really good at thinking on my feet, but what the
sh*t do I know about deployment? Right around that time, Walter was demoted
and theoretically made the "director of deployment," a position where he
directed his expansive team of -- himself. Then he left, and get this: now
the company has half a million laptops in the wild, with no one even
pretending to be officially in charge of deployment. "I quit," Walter told
me on the phone after leaving, "because I can't continue to work on a lie."
http://radian.org/notebook/sic-transit-gloria-laptopi

------------------------------

Date: Mon, 14 Sep 2009 09:43:15 -0700
From: Gene Wirchenko <genew () ocis net>
Subject: Smart Cars?

  In today's connected world, the time you spend in your car might be the
  only time you're really off the grid. But that's about to change --- the
  automotive and ICT sectors are collaborating to network vehicles and come
  up with ideas for useful applications. Whether its finding carpool
  buddies, swerving to avoid a collision, or avoiding traffic jams --- CATA
  wants those applications to be tested in Canada.  [Source: Intelligent car
  1,000-km corridor between Ontario and Quebec envisioned]
  http://www.itbusiness.ca/it/client/en/home/News.asp?sub=true&id=54501

The risky stuff starts near the bottom of page 2.

A concern of mine is how motorists in vehicles without this system will
interact with vehicles that do.  It seems to me that expectations of
intelligent response are not going to be met.

------------------------------

Date: Sat, 12 Sep 2009 23:36:43 -0400
From: Monty Solomon <monty () roscom com>
Subject: Boston city employees routinely deleted e-mail

Menino's office acknowledges city employees routinely deleted e-mails
By Donovan Slack and Michael Levenson, *The Boston Globe*, 13 Sep 2009

Mayor Thomas M. Menino's administration, prompted by public records requests
from *The Globe*, has acknowledged that city employees were routinely
deleting e-mails, a potential violation of the state public records law.
This came after *The Globe* filed several requests for e-mails sent and
received by Menino's Cabinet chief of policy and planning, Michael
J. Kineavy -- who is one of Menino's most powerful and trusted advisers,
intimately involved in nearly everything at City Hall.  However, a search of
city computers found just 18 e-mails he had sent or received between 1 Oct
2008, and 31 Mar 2009.  The unusually low figure prompted administration
officials to question him about what happened to the rest of the e-mails he
was presumably sending and receiving during that period.  Kineavy told them
that he deletes all his e-mails on a daily basis, in such a way that they
are not saved on city backup computers.

http://www.boston.com/news/local/massachusetts/articles/2009/09/13/meninos_office_acknowledges_city_employees_routinely_deleted_e_mails/

------------------------------

Date: Sat, 12 Sep 2009 03:59:34 +0800
From: jidanni () jidanni org
Subject: Networks and Nationalization With Respect to Cyberwar

Cyberwarfare is the sort of game where you don't really need to be a huge
government with the largest standing army in the world and sophisticated
weaponry in order to win. Any teenager in his basement can control a
botnet. And a botnet targeted at a poorly secured site will take it down,
never mind whether the site belongs to the US government, or to the
Iranians, or the Chinese, the Russians, Indians, etc. etc.

In other words probably the best way to go in a so-called "cyberwar" is
defense.  Harden your security. And make efforts to take down the sources
of the DDoS or other attack as a way to mitigate it.

Not by breaking into it -- that's not a good idea-it will very likely end up
affecting an innocent party, and you might not even have taken out the
actual source -- given that a lot of botnet C&Cs are usually compromised
hosts, controlled by a chain of proxies from god knows where else
(connecting those dots is quite tough, when a botnet is done right).

Rather, by actually using the public private partnership you have,
internationally, to work with upstream providers of the source to mitigate
these attacks, work with the providers of your critical infrastructure's
connectivity to filter attack sources etc. etc.

A textbook case of "how not to do this" -- during the recent North Korea (!)
DDOS: A vietnamese antivirus / security vendor, BKIS and their analysis said
the command and control servers were in the UK-again, quite possibly
compromised hosts were used for the C&C.

That turned into a "The UK, not North Korea, is behind this cyberattack" in
the media. Which doesn't sound quite right to me...

Suresh Ramasubramanian: More on Networks and Nationalization with
Respect to Cyberware, 21 Jul 2009
http://www.circleid.com/posts/20090721_networks_and_nationalization_with_respect_to_cyberwar/

  [Legislating against the concepts of Deep Packet Inspection (DPI) or other
  preferential treatment of packets is not the brightest thing to do. I've
  seen others draw analogies to gun control using the 'guns don't kill
  people' argument. Network algorithms don't kill people either but that's
  the most I'll take that line of argument forward, it is loaded and the
  traps are 'easy' to find for people on both sides of the argument.
  jidanni]

------------------------------

Date: Wed, 2 Sep 2009 22:18:15 -0400
From: Monty Solomon <monty () roscom com>
Subject: Heavy Data Use Puts a Strain on AT&T Service

Jenna Wortham, *The New York Times*, 3 Sep 2009

Slim and sleek as it is, the iPhone is really the Hummer of cellphones.
It's a data guzzler. Owners use them like minicomputers, which they are, and
use them a lot. Not only do iPhone owners download applications, stream
music and videos and browse the Web at higher rates than the average
smartphone user, but the average iPhone owner can also use 10 times the
network capacity used by the average smartphone user.  [...]  The result is
dropped calls, spotty service, delayed text and voice messages and glacial
download speeds as AT&T's cellular network strains to meet the
demand. Another result is outraged customers.

http://www.nytimes.com/2009/09/03/technology/companies/03att.html

------------------------------

Date: Wed, 2 Sep 2009 22:23:37 -0400
From: Monty Solomon <monty () roscom com>
Subject: Snow Leopard: A gigabyte by any other name

Excerpt from Mac OS X 10.6 Snow Leopard: the Ars Technica review
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars

A gigabyte by any other name

Snow Leopard has another trick up its sleeve when it comes to disk usage.
The Snow Leopard Finder considers 1 GB to be equal to 10^9 (1,000,000,000)
bytes, whereas the Leopard Finder-and, it should be noted, every version of
the Finder before it-equates 1 GB to 2^30 (1,073,741,824) bytes.  This has
the effect of making your hard disk suddenly appear larger after installing
Snow Leopard.  For example, my "1 TB" hard drive shows up in the Leopard
Finder as having a capacity of 931.19 GB.  In Snow Leopard, it's 999.86 GB.
As you might have guessed, hard disk manufacturers use the powers-of-ten
system.  It's all quite a mess, really.  Though I come down pretty firmly on
the powers-of-two side of the fence, I can't blame Apple too much for
wanting to match up nicely with the long-established (but still dumb, mind
you) hard disk vendors' capacity measurement standard.

------------------------------

Date: Tue,  8 Sep 2009 20:11:03 -0400 (EDT)
From: lrudolph () panix com (Lee Rudolph)
Subject: Humbert Humbert <heart> Fishfingers

... Panic at the London Evening Standard yesterday where the theatre critic
Henry Hitchings filed his review of Lolita at the National Theatre, only to
learn that no one at HQ could locate his copy.  The panic starts early there
-- 5am -- with production staff looking at the clock and imploring him to
file again.  Why couldn't he communicate with them.  No one could understand
it.  Enter a hero computer boffin.  The firewall, he explained, was
rejecting the word Lolita.  So Hitchings had to re-file substituting Lolita
throughout with the less troublesome "Fishfingers".  Relieved production
staff re-inserted all the Lolitas at the other end.  ...
http://www.guardian.co.uk/politics/2009/sep/09/boris-johnson-cycling-goldschmied-rogers

------------------------------

Date: Thu, 10 Sep 2009 08:01:33 -0400
From: Monty Solomon <monty () roscom com>
Subject: Quantum Chip Helps Crack Code

Anne-Marie Corley, Quantum Chip Helps Crack Code;
Experimental chip does part of code-cracking quantum algorithm, 3 Sep 2009

Modern cryptography relies on the extreme difficulty computers have in
factoring huge numbers, but an algorithm that works only on a quantum
computer finds factors easily. Today in Science, researchers at the
University of Bristol, in England, report the first factoring using this
method-called Shor's algorithm-on a chip-scale quantum computer, bringing
the field a tiny step closer to realizing practical quantum computation and
code cracking.

Quantum computers are based on the quantum bit, or qubit. A bit in an
ordinary computer can be either a 1 or a 0, but a qubit can be 1, 0, or a
"superposition" of both at the same time. That makes solving certain
problems-like factoring-exponentially faster, because it lets the computer
try many more solutions at once. The race is on to find the ideal quantum
computer architecture, with qubit contenders that include ions, electrons,
superconducting circuits, and in the University of Bristol's case, photons.

MIT professor Seth Lloyd, who has been researching quantum computing and
communication systems since the early 1990s, says that "optical methods
[using photons] have a long way to go before being useful."  But, Lloyd
adds, the Bristol experiment demonstrates that the components for optical
quantum computing can be squeezed onto a chip, which is an important step
forward.

Shor's algorithm was first demonstrated in a computing system based on
nuclear magnetic resonance-manipulating molecules in a solution with strong
magnetic fields. It was later demonstrated with quantum optical methods but
with the use of bulk components like mirrors and beam splitters that take up
an unwieldy area of several square meters. ...

http://www.spectrum.ieee.org/computing/hardware/chip-does-part-of-codecracking-quantum-algorithm

  [The rest of the article sounds as if the paradigmatic hard problem
  at this point is still factoring 15.  PGN]

------------------------------

Date: Mon, 14 Sep 2009 08:10:50 -0400
From: Peter G Neumann <Neumann () csl sri com>
Subject: Nonprofit for collecting info on SCADA & PCS security incidents

Stephanie Neil, *Managing Automation*, 12 Sep 2009
http://www.managingautomation.com/maonline/news/read/NonProfit_Targets_CyberSecurity_in_Plants_33037

The move from proprietary, non-networked control systems in the plant to
off-the-shelf, open applications that share information across industrial
and business networks is a double-edged sword for manufacturers. On one
side, people are more productive; on the other side, SCADA and process
control systems are falling victim to hackers and network viruses.

Getting a handle on how to manage cyber-threats, however, has always been a
bit tricky. Reporting an industrial incident to organizations such as the
government-backed CERT program, which tracks Internet and network security
attacks, accidents, and failures, could expose a company's network
vulnerability or create a legal liability. As a result, many manufacturers
keep a lid on their own security issues, which limits knowledge sharing that
could help the industrial community as a whole.

Enter the Security Incidents Organization, a newly formed non-profit group
that provides public access to its Repository of Industrial Security
Incidents (RISI). Established in July, the group maintains an industry-wide
repository for collecting, investigating, analyzing, and sharing critical
information regarding cyber-security incidents that directly affect SCADA
and process control systems.

The RISI database dates back to 2001, when it was housed at the British
Columbia Institute of Technology (BCIT) as part of a research project that
was shut down in 2006. At that time, BCIT faculty member Eric Byres
purchased the database and continued to collect data on incidents. His
company, Byres Research, was acquired by safety and security services firm
exida earlier this year.

Jeremy Epstein, Senior Computer Scientist, SRI International, 1100 Wilson
Blvd, Suite 2800, Arlington VA 22209 +703-247-8708 jeremy.epstein () sri com

  [Eric Byres is noted in two previous issues of RISKS, notably
    Critical infrastructure cybersecurity risks, RISKS-23.57,
  and also for Infoworld interviews with him and Alan Paller, in
    SCADA Hacks, RISKS-24.44.
  Please see http://www.securityincidents.org if you are interested in
  being involved in RISI.  PGN]

------------------------------

Date: Sun, 30 Aug 2009 09:49:27 -0400
From: Monty Solomon <monty () roscom com>
Subject: Utah Gets Tough With Texting Drivers

Matt Richtel, *The New York Times*, 29 Aug 2009
Driven to Distraction: Utah Gets Tough With Texting Drivers
http://www.nytimes.com/2009/08/29/technology/29distracted.html

In most states, if somebody is texting behind the wheel and causes a crash
that injures or kills someone, the penalty can be as light as a fine.  Utah
is much tougher.  After a crash here that killed two scientists -- and
prompted a dogged investigation by a police officer and local victim's
advocate -- Utah passed the nation's toughest law to crack down on texting
behind the wheel. Offenders now face up to 15 years in prison.

The new law, which took effect in May, penalizes a texting driver who causes
a fatality as harshly as a drunken driver who kills someone.  In effect, a
crash caused by such a multitasking motorist is no longer considered an
"accident" like one caused by a driver who, say, runs into another car
because he nodded off at the wheel. Instead, such a crash would now be
considered inherently reckless.

"It's a willful act," said Lyle Hillyard, a Republican state senator and a
big supporter of the new measure. "If you choose to drink and drive or if
you choose to text and drive, you're assuming the same risk."

The Utah law represents a concrete new response in an evolving debate among
legislators around the country about how to reduce the widespread practice
of multitasking behind the wheel -- a topic to be discussed at a national
conference about the dangers of distracted driving that is being organized
by the Transportation Department for this fall.

Studies show that talking on a cellphone while driving is as risky as
driving with a .08 blood alcohol level -- generally the standard for drunken
driving -- and that the risk of driving while texting is at least twice that
dangerous. Research also shows that many people are aware that the behavior
is risky, but they assume others are the problem.

Treating texting behind the wheel like drunken driving raises complex legal
questions. Drunken drivers can be identified using a Breathalyzer. But there
is no immediate test for driving while texting; such drivers could deny they
were doing so, or claim to have been dialing a phone number. (Many
legislators have thus far made a distinction between texting and dialing,
though researchers say dialing creates many of the same risks.)

If an officer or prosecutor wants to confiscate a phone or phone records to
determine whether a driver was texting at the time of the crash, such
efforts can be thwarted by search-and-seizure and privacy defenses, lawyers
said.

Prosecutors and judges in other states already have the latitude to use more
general reckless-driving laws to penalize multitasking drivers who cause
injury and death. In California, for instance, where texting while driving
is banned but the only deterrent is a $20 fine, a driver in April received a
six-year prison sentence for gross vehicular manslaughter when, speeding and
texting, she slammed into a line of cars waiting at a construction zone,
killing another driver.

But if those prosecutors want to charge a texting driver with recklessness,
they must prove the driver knew of the risks before sending texts from
behind the wheel.

In Utah, the law now assumes people understand the risks. ...

------------------------------

Date: Wed, 02 Sep 2009 14:11:33 +0100
From: Peter Duncanson <mail () peterduncanson net>
Subject: Re: UK Chinook helicopters grounded for *years* (RISKS-25.77)

Danny Burstein's comment "UK bought Boeing helicopters, figured they'd save
money by designing their own software..." is based on an inaccurate news
report and is incorrect.  There was no attempt to design their own software.

The report from the UK Parliament's Public Accounts Committee makes the
position much clearer.

(It is the purchasing nation's responsibility to assess and certify the
airworthiness of the aircraft.)

Conclusions and Recommendations:
http://www.publications.parliament.uk/pa/cm200809/cmselect/cmpubacc/247/24704.htm

 3. The problems with the [Chinook] Mk3 procurement stemmed from the
    Department's failure to specify in the contract that it required
    access to the software source code in order to assess the safety
    risks and establish whether the helicopters would meet UK
    airworthiness standards. Given that software is key to the operation
    of most modern defence equipment, this is irresponsible. The
    Department should specify access to software as a clear requirement
    within any contract, especially where access to proprietary software
    is needed to provide airworthiness certification."

The Original Procurement of Chinook Mk3 helicopters:
http://www.publications.parliament.uk/pa/cm200809/cmselect/cmpubacc/247/24705.htm
 1. In 1995, the Ministry of Defence (the Department) decided that,
    in order to meet the long standing requirement for dedicated
    helicopters to support special operations, an original order for 14
    Chinook Mk2a helicopters from Boeing would be changed. Six were
    retained as Mk2a and have flown satisfactorily ever since they were
    delivered, but it was decided that the other eight would be modified
    to become Chinook Mk3 helicopters. The Chinook Mk3 helicopters
    feature unique cockpit avionics which, because of the Department's
    budgetary priorities elsewhere, ended up being a hybrid of analogue
    and digital systems, rather than a pure digital arrangement as used
    in the United States special operations Chinook (MH47-E) and by the
    Royal Netherlands Air Force.

 2. In 2005, the Department acknowledged that the Chinook Mk3 project
    had been badly handled... The hybrid digital and analogue cockpit
    avionics could not be shown to meet United Kingdom airworthiness
    standards. As a result, the helicopters could only be granted a
    limited release to fly, and are restricted to flying on cloudless
    days above 500 feet where the pilot can navigate via landmarks. This
    makes them completely unsuitable for use on operations.

 3. One of the key reasons for not granting a full release to fly was
    that the software codes that maintained the instrument displays in
    the Mk3 cockpit could not be proven to be safe. The Department
    acknowledged that analysis of the code, which would help anticipate
    how the software, and hence the helicopter, would behave in all
    flight conditions, may have enabled it to certify them as safe.
    Boeing, in protecting their intellectual property rights, denied the
    Department access to the software source code. The Department
    accepted that the original contract, which did not mandate access to
    the codes, was not sufficient for the purpose of procuring
    helicopters that could be proven to be safe.

 5. ... If the Department had not been so willing to compromise on
    the specification of the cockpit, it might have been able to prove
    airworthiness in the same way as it has for other aircraft. For
    example, by using the safety cases put together by the United States
    for the C17 aircraft, the Department has been able to satisfy the
    British airworthiness authorities and use the aircraft
    operationally, without having to resort to analysis of the flight
    software. The Department acknowledged that it should not
    over-specify changes to equipment or platforms unless it had, for
    example, to fit United Kingdom specific communications equipment.

The report is available as a PDF file:
http://www.publications.parliament.uk/pa/cm200809/cmselect/cmpubacc/247/9780215526663.pdf

------------------------------

Date: Mon, 14 Sep 2009 13:51:23 PDT
From: Peter G Neumann <neumann () csl sri com>
Subject: Bertrand Meyer, *Touch of Class*, Springer, 2009

A book arrived in the post from Switzerland today in a package that was
soaking wet, as if it had been submerged or left out in the rain.  However,
the book itself was encased in plastic, and was not only in perfect
condition, but very readable and very relevant to RISKS.

  Bertrand Meyer's new book, *Touch of Class: Learning to Program Well with
  Objects and Contracts* ``gives students the edge by teaching both the
  fundamentals of programming and the professional-level skills preparing
  them for the challenges of modern software engineering.''  (Quoted from
  the back cover).  876+lxiv

The book is dedicated to Tony Hoare and Niklaus Wirth, and I think it would
please both of them very much.  It is very likely to be a real value for
students, professors, and software engineers alike.  PGN

------------------------------

Date: Thu, 03 Sep 2009 12:30:39 -0400
From: Alexandre Peshansky <peshanal () umdnj edu>
Subject: Re: VA erroneously informs over a thousand vets (McCool, RISKS-25.77)

On 27 Aug 2009, Rob McCool reported VA gaffe as "Through a data maintenance
error, the Veteran's Affairs department recently sent out automated letters"

The issue probably has nothing to do with data maintenance error.  The error
is in the underlying ICD-9 (International Classification ... of Diseases),
which is, along with CPT (Current Procedural Terminology) and, to smaller
degree, HL7 (Health Level 7), totally unsuitable for anything except billing
for current medical intervention.  This is a problem well known in clinical
research community and was a topic of many a lively discussions.  The same
underlying problem caused spurious assignment of a range of illnesses to
Mr. deBronkart in his Google Health record (RISKS-25.64), extracted from ICD
and CPT in his billing data.  These coding systems are not hierarchical (or
where they try to be, hierarchy is often broken), non-conservative (the
meaning of the codes changes over time, with codes being re-assigned (as in
quoted case), split and merged.  The latter makes them unusable over any
non-trivial timeframe without metadata, which is often unavailable (the
source document - medical chart _should_ contain the date of each entry,
which would have made maintaining the metadata possible - _if_ it was
preserved in transcription.

So the risk in the quoted cases is, probably, in the use of data items
outside of domain for which they were designed (similarly to use of SSN for
authentication).

Alexandre Peshansky, Manager, OCR Informatics Core, NJ Medical School,
UMDNJ CC F-1220 205 S. Orange Ave., Newark, NJ   (973) 972-4897

------------------------------

Date: Tue, 01 Sep 2009 19:39:05 -0400
From: Glenn Chambers <gchamber () bright net>
Subject: Interesting disclaimer added by my ISP to the latest RISKS

On Tue, 2009-09-01 at 08:51 -0700, RISKS List Owner wrote:
> - -----------------------------------------------------------
> WARNING!  This email may be asking for account details.
> bright.net would NEVER email you asking for this information.
> Do not reply to this email unless you are certain of the
> sender.
> - -----------------------------------------------------------
>
> RISKS-LIST: Risks-Forum Digest  Tuesday 1 September 2009  Volume 25 : Issue 77
I can imagine cases where this could cause problems...

------------------------------

Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request () csl sri com
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.   The mailman Web interface can
 be used directly to subscribe and unsubscribe:
   http://lists.csl.sri.com/mailman/listinfo/risks
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
   risks-request () csl sri com
 containing only the one-word text subscribe or unsubscribe.  You may
 also specify a different receiving address: subscribe address= ... .
 You may short-circuit that process by sending directly to either
   risks-subscribe () csl sri com or risks-unsubscribe () csl sri com
 depending on which action is to be taken.

 Subscription and unsubscription requests require that you reply to a
 confirmation message sent to the subscribing mail address.  Instructions
 are included in the confirmation message.  Each issue of RISKS that you
 receive contains information on how to post, unsubscribe, etc.

=> The complete INFO file (submissions, default disclaimers, archive sites,
 copyright policy, etc.) is online.
   <http://www.CSL.sri.com/risksinfo.html>
 The full info file may appear now and then in RISKS issues.
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks () CSL sri com with meaningful SUBJECT: line.
 *** NOTE: Including the string "notsp" at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
   Lindsay has also added to the Newcastle catless site a palmtop version
   of the most recent RISKS issue and a WAP version that works for many but
   not all telephones: http://catless.ncl.ac.uk/w/r
 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    <http://www.csl.sri.com/illustrative.html> for browsing,
    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
    <http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 25.78
************************