Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Following is a translation of a short article published in a French newspaper "Le Figaro", on 21st January 1991. It was part of a special supplement describing the new electronic weapon systems the allies are currently using. Electronic navigation systems are now so advanced that the pilot of a fighter airplane is not obliged to play an active role during the flying phase. The computer is in fact a better pilot in sorties involving penetration of enemy territory by flying at very low altitude (under the sensitive radar zones). It is not prone to tiredness, and much better at avoiding obstacles: it is therefore possible to fly at supersonic speed ( < 1000 km/h) in a hilly region, whilst constantly being at an altitude of 15 metres from the ground. This is very reliable, since the sensors of the airplane constantly provide data which the navigation systems computer uses. Unfortunately, the actual pilots cannot stand this type of passive flight. Not because by vanity, but because they tend to get sick: the U.S. Air Force has found out during experimental missions that even the best and toughest of pilots gets sea-sick after a few minutes when submitted to accelerations and bearing changes that he did not generate himself. This is so serious that when some pilots arrived at the target site, they had lost all faculties of analysis, and as a result the U.S. Air Force has decided to abandon at least partially the concept of automated piloting for very low altitude flights. " Olivier M.J. Crepin-Leblond, Elec. Eng., Imperial College London, UK.
Today's New York Times states (on page two of the business section) that
Apple has filed with the FCC to reserve radio bandwidth for use in wireless
local area networks. Instead of running LAN cable all around your building,
you put low-power transmitter/receivers in all your machines, and away you
go. The assigned bandwidth would be used by all comers on a first come,
first served basis within each area, much as cordless phones or garage door
openers are now. They estimate 150ft as the useful radius of communication;
data rates would be the same as wired LANs (10Mb/sec or so).
The risks should be pretty obvious to readers of this digest. Somebody in
the next building could eavesdrop on your traffic, or actively connect into
your net, with NO special hardware. I sure hope Apple is at least planning
to encrypt the packets---no mention of this, or of any security concerns, in
the article. (But if they are going to support 10Mb/sec data rates, the
encryption would have to be fairly weak, methinks.)
If I ran a corporate network, I wouldn't touch this with a 10-foot pole.
tom lane
I can offer first-hand experiences concerning use of technology in forensics. Some colleagues and I have developed software systems to help manage forensic information `in the field' following a mass casualty disaster. Initially we focused upon dental information, where the goals are to capture both antemortem and postmortem records rapidly, then suggest possible matches between them. Based upon suggestions from the software, an expert would take the time only to perform an autopsy (in order to confirm the match) once enough confidence had been built up by the software that the match was likely. Previously, only paper records were kept; matches were based upon having medical examiners pick up a file folder of raw records, and then walk down a long row of human remains, comparing each in turn until a possible match was found. With our software, both goals are attained: 1. Some amount of organization was brought to raw data that begins to gush forth after a tragedy (dentists employ many recording schemes, most of them conflicting, it seems). 2. The heuristic we developed for suggesting matches works. Our first suggestion for a possible match has proven to be correct better than 95% of the time, based upon analysis of records that have been made available to us following previous air disasters. So much for the advertising. Now for the nitty gritty. The only way we can obtain this success is by *ignoring* much of the key information that an expert would use to help make a positive identification! Earlier versions of our program attempted to consider detailed information about such things as root canals, the quality of tooth enamel (hypoplasia, abrasions, mottled), and shape of incisors. The program was magnificently successful when used with quality information. However, our testing showed that there is almost no quality information to be had in the first place. Dentists (some!) will charge for work not done, or will mark the wrong tooth on paper records when in a hurry to get to the next patient (off by one, or right index from wrong side of mouth). They will mark down the wrong type of filling material. Or they won't update a patent's records if they find new work done there by someone else (say, the patient was on the road, needed a quick filling by someone near at hand). And so on. Never mind the problems that any program will have should you send out for the records of "Jane and John Doe", only to find Jane answers the phone, but John's secretary is missing... Next, the transcription problem. Lots of data, with diverse formats and inconsistent attention to details, cannot be accurately transcribed by assistants conscripted by airlines (or local ME office, or whatever). With experiments, we were able to find a choice of parameters that is least likely to be screwed up in the original antemortem form, is sufficient to get us very close in suggested matches, and yet is simple enough that a spreadsheet editor can let users enter all the material on one screen. By giving up the urge to use all the data and be *exact*, we were able to find a solution that got very close. In this case, this is sufficient to guide expert users, who will then make very good use of their time (confirming matches, not investing time looking for them). In summary, Sherizen's observation is correct: the key problem is obtaining accurate information in the first place (i.e., we have rediscovered GIGO). The key engineering problem, therefore, is anticipating common error modes and adapting our technology accordingly. Jim Purtilo, Computer Science Department, University of Maryland
There was an accidental Patriot launch in Turkey of two Patriots against aircraft returning from Iraq. Four aircraft took evasive action, and all esacped. Although the system was in anti-ballistic (vs. anti-aircraft) mode, this does show the Patriot may be useless against anything other than predictably moving hunks of metal, and that automatic launch on warning is as dangerous as we thought.
Dave Parnas writes in RISKS 10.82:
> There was no SDI software technology to be applied to Patriot.
Today I spoke with someone who works in an engineering capacity with a US Army
guided missile group (I didn't ask if my source minded being quoted, so I won't
be more specific). According to my source, the sensors that are currently
being used on Patriot missiles to track BMs were developed as part of the SDI
program (recall that the Patriot was originally an anti-aircraft system, and
thus used different sensors). The first test of these new sensors on a Patriot
took place about six months ago at White Sands. So while the Patriot itself is
not based on SDI technology, the sensors that it uses to track BMs are based on
SDI technology.
Don Wegeng
Some years back I was stationed with HHB 45th Arty (AD) a Nike Hercules unit.
45th ADA was located in Arlington Heights Il, a suburb of Chicago at the time.
The Herc had a high explosive warhead, but could also be fitted with one of
several nuclear warheads. Contemplating the effects of a nuclear blast over
say Northfield ( a northern suburd of Chicago) and being willing to question
authority I posed to my superior the question "What good does it do to shoot
down a Russian bomber with a missle that will destroy the town under it ?" and
the reply was "Well son .... what would you rather have: ## kilotons over
Evanston, or 10 to 50 megatons over the loop ?" Now at the time it almost made
sense, 10 to 50 mt over the loop would sure negate the suburbs, and ## kt in
the burbs would only cause significant damage to the loop area. Please note the
key word is almost. I have no doubt that the same mindset is in use today and
the question has got to be: "Well son, would you rather have big burning
fragments of Patriot and Scud over the burbs or a Scud downtown ?" {Could that
be Scud or Scud Lite ? :-) } I sure as hell don't have the answer. Ed Wright
In <RISKS DIGEST 10.81> li@helen.oracorp.com proposed a partial precaution against bogus-vote insertion, namely that some votes be tagged `negative', meaning that the votes cast are really reversed. I leave the security and sociological consequences to more qualified folk. I address the following claim: >(even if I write down +1234567, I could have >mentally remembered it to be a negative number. Now I remember 1 bit >information, not a long random number). I wouldn't trust the public's ability to remember a single bit of information. Indeed, even I have trouble remember whether the my front door is locked or unlocked when the handle is in the vertical or horizontal position, and this is a door I lock every day.
This is out of high school history, but fortunately that isn't too far in
the past for me:
The old technique for buying votes had a person watching on the way from the
voting booth to the ballot box. You had to unfold your ballot and show them a
correctly marked ballot, then go and drop it in the box. Then you got yor $5
(or whatever it was). If not, you got a visit from some large guys.
Politics is almost the definitive dirty activity. We need a very foolproof way
to prevent influence where we don't want it. I'm not implying that anyone
today would engage in widespread abuse, but blatant vote-buying is not too long
in Canada's history, at least (I don't know about the U.S.), and it could
return in 25 years.
To be secure against bribery and intimidation of individual voters, it must not
be possible for A to prove to B that he did or did not vote for B. (Well, if
*nobody* in A's district voted for B, then B has some idea, but...)
This is why I like the current method of constructing a human-readable ballot
and placing it in a box. Recounts are possible, the voter can clearly see what
they're doing, and ensuring that there are initially no ballots in the box and
that each voter places at most one ballot in the box is relatively easy and can
be done by several witnesses. It's not impossible to abuse, but it requires a
large conspiracy.
Will these voting by phone techniques prevent me from signing up a few hundred
drunks, having them vote from a telephone I supply, with me listening on an
extension, and giving them each a bottle of rum afterwards? In a marginal
constituency, this could make a difference.
-Colin
CALL FOR PAPERS AND PARTICIPATION
Seventh Annual Computer Security
Applications Conference
December 2-6, 1991
San Antonio, Texas
The Conference. Operational requirements for civil, military, and commercial
systems increasingly stress the necessity for information to be readily
accessible. The Computer Security Act of 1987 requires that all Federal
agencies take certain actions to improve the security and privacy provided by
federal computer systems. Accomplishing both operational and security
requirements requires the application of the maturing technology of integrated
information security to new and existing systems throughout their life cycle.
This conference will explore technology applications for both civil and
military systems; the hardware and software tools and techniques being
developed to satisfy system requirements; and specific examples of systems
applications and implementations. Security policy issues and standards will
also be covered during this five day conference.
Papers and Tutorials. Technical papers and tutorials that address the
application of integrated information security technologies in the civil,
defense, and commercial environments are solicited. Original research,
analyses and approaches for defining the computer security issues and problems
identified in the Conference's interest areas; secure systems in use or
development; methodological approaches for analyzing the scope and nature of
integrated information security issues; and potential solutions are of
particular interest. A prize of $500, plus expenses paid to attend the
conference, will be awarded for the best paper written by a student. For
details contact Ravi Sandhu at the address below.
INSTRUCTIONS TO AUTHORS: Send five copies of your paper or panel proposal to
Ann Marmor-Squires, Program Chairman, at the address given below. We provide
"blind" refereeing; put names and affiliations of authors on a separate cover
page only. It is a condition of acceptance that manuscripts submitted have not
been previously published. Papers that have been accepted for presentation at
other conferences should not be submitted. Tutorial proposals should be sent
to Daniel Faigin at the address given below.
Papers and tutorial proposals must be received by May 17, 1991. Authors will
be required to certify prior to June 19, 1991, that any and all necessary
clearances for publication have been obtained, that they will be represented at
the conference to deliver the paper, and that the paper has not been accepted
elsewhere. Authors will be notified of acceptance by July 29, 1991. Camera
ready copies are due not later than September 18, 1991. Material should be
sent to:
Ann Marmor-Squires Daniel Faigin
Technical Program Chair Tutorial Program Chair
TRW Systems Division The Aerospace Corporation
2751 Prosperity Ave. P.O. Box 92957, MS M1/055
Fairfax, VA 22031 Los Angeles, CA 90009-2957
(703) 876-8161 (213) 336-8228
marmor@a.isi.edu faigin@aerospace.aero.org
Ravi Sandhu, Student Paper Award, George Mason Univ., ISSE Dept.,
Fairfax, VA 22030-4444, (703) 764-4663 sandhu@gmuvax2.gmu.edu
Areas of Interest Include: Advanced Architectures, C3I Systems, Trusted DBMSs
and Operating Systems, Public Law 100-235, Networks and Open Systems, Software
Safety, Policy and Management Issues, Risk/Threat Assessments, State-of-the-Art
Trusted Products, Electronic Document Interchange and Modeling Applicability,
Certification, Evaluation and Accreditation, Current and Future
Trusted Systems Technology, Reviewers and Prospective Conference Committee
Members.
Anyone interested in participating as a reviewer of the submitted papers,
please contact Ann Marmor-Squires at the address given above. Those interested
in becoming members of the conference committee should contact Dr. Ronald Gove
at the address below.
For more information or to receive future mailings, please contact the
following at:
Dr. Ronald Gove Diana Akers
Conference Chairman Publicity Chair
Booz-Allen & Hamilton The MITRE Corporation
4330 East-West Highway 7525 Colshire Dr.
Bethesda, MD 20814 McLean, VA 22102
(301) 951-2395 (703) 883-5907
Gove@dockmaster.ncsc.mil akers@mitre.org
Victoria Ashby, Publication Chair, The MITRE Corporation, 7525 Colshire Dr.,
McLean, VA 22102 (703) 883-6368 ashby@mitre.org
C A L L F O R P A P E R S
INTERNATIONAL CONFERENCE ON
T H E O R E M P R O V E R S I N C I R C U I T D E S I G N :
T H E O R Y , P R A C T I C E A N D E X P E R I E N C E
NIJMEGEN, THE NETHERLANDS, 22-24 JUNE, 1992
FOCUS AND OBJECTIVES
Formal methods are increasingly seen as important in the design of digital
systems. The use of these techniques in practice is often regarded as being
strongly dependent on the support of appropriate mechanized theorem proving
tools. The purpose of this conference is to provide a forum for discussing
the role of theorem provers in the design of digital systems. The objective
is to cover all relevant aspects of work in the field, including original
research as well as case studies and other practical experiments with new
or established tools.
The primary focus will be on the ways in which formal methods are supported
by theorem proving tools, rather than on the theoretical foundations of
formalisms and design methods. The topics of interest include the philosophy
behind such tools, their design and development, their evolution, and their
evaluation through use. Of equal importance is the migration path of a theorem
proving tool and the associated technology into current digital engineering
practice.
The intended audience includes workers in the field of hardware verification
as well as practising digital designers.
TUTORIALS
It is intended that the conference will address, among other issues,
practical questions such as:
Why use a theorem prover?
Which theorem prover should I use?
When should I use it?
How should I use it?
To enhance this aspect of the proceedings, the working sessions will be
complemented by tutorials on a variety of theorem proving tools and
associated topics. A Tutorials Chair has been established to ensure that a
wide range of systems are represented and to underline the importance that is
placed on the matter.
PROGRAMME AND PROCEEDINGS
The conference programme will start with a day of tutorials and
demonstrations, followed by two days of presentations by contributing authors.
The programme will also include invited lectures by three prominent
researchers in the field of machine-assisted verification. The invited
speakers are:
Mike Gordon, University of Cambridge.
Warren Hunt, Computational Logic Inc.
Dave Musser, Rensselaer Polytechnic Inst.
A digest of papers will be made available to participants at the conference
and the proceedings will be published after the conference.
ORGANIZATION
The conference is organized by the Computer and Communications Systems Group
of the University of Nijmegen, the Netherlands. The conference organizers are:
General Chair:
Raymond Boute, University of Nijmegen.
Programme Chair:
Victoria Stavridou, University of London.
Tutorials Chair:
Tom Melham, University of Cambridge.
Local Arrangements Chair:
Huub van Thienen, University of Nijmegen.
PROGRAMME COMMITTEE
The programme committee includes:
Albert Camilleri (HP Labs, UK)
Luc Claesen (IMEC, Belgium)
Ed Clarke (CMU, USA)
Mike Fourman (Edinburgh Univ., UK)
Joseph Goguen (Oxford Univ., UK)
Allen Goldberg (Kestrel Institute, USA)
Keith Hanna (Univ. of Kent, UK)
Warren Hunt (CLInc, USA)
Jeff Joyce (UBC, Canada)
Deepak Kapur (Albany SU, USA)
Dave Musser (RPI, USA)
Tobias Nipkow (Univ. of Cambridge, UK)
Paolo Prinetto (Politechnico di Torino, Italy)
Clive Pygott (RSRE, UK)
David Shepherd (Inmos, UK)
Joseph Sifakis (IMAG, France)
IMPORTANT DATES
The important dates are as follows:
30 September 1991 :
Final deadline for the submission of papers.
28 February 1992 :
Date for notification of acceptance or rejection.
30 April 1992 :
Final camera-ready copy due.
22-24 June 1992 :
Conference at Nijmegen.
SUBMITTING A PAPER
Four copies of a complete paper (in English) should be sent to the Programme
Chair at the address given below to arrive no later than 30 September 1991.
Papers must not exceed 6000 words in length, with full-page figures counted as
300 words. Each paper should include a short abstract and a list of keywords
for subject classification. All papers will be refereed and the final choice
will be made by the programme committee on the grounds of relevance,
significance, originality, correctness and clarity. Submitted papers must not
be published or under consideration for publication elsewhere in the same or
similar form. Authors of accepted papers will be sent LaTeX style files to
aid in the production of camera-ready copy.
PROPOSALS FOR TUTORIALS
Proposals are solicited for tutorial presentations on relevant theorem
proving technology or tools. The intention is that a tutorial will provide
an overview of the basic ideas behind a theorem proving tool, rather than
detailed instruction in how to use it. Tutorials should include an assessment
of strengths and weaknesses of a tool and should concentrate on general issues
such as security, robustness, the degree of interaction required, the user
interface, and the mathematical skill required of the user.
Proposals for tutorials should not exceed 1000 words in length and should
give a clear indication of the topic and structure of the presentation.
Also welcome are proposals for informal demonstrations of working systems.
Proposals for both tutorials and demonstrations should be sent to the
Tutorials Chair at the address given below to arrive no later than 30
September 1991.
ADDRESSES FOR CORRESPONDENCE
Papers and all general correspondence should, in the first instance, be sent
to the Programme Chair at the following address:
Victoria Stavridou,
TPCD Programme Chair,
Department of Computer Science,
RHBNC , University of London,
Egham Hill, Egham,
Surrey, TW20 0EX, United Kingdom.
Tel: (+44) 865 273808 (until 30/9/91)
Tel: (+44) 784 443429/3421 (after 30/9/91)
Fax: (+44) 865 273839/784 437520
Email: victoria@cs.rhbnc.ac.uk
Proposals for tutorials and demonstrations should be sent to the Tutorials
Chair:
Tom Melham,
TPCD Tutorials Chair,
Computer Laboratory,
University of Cambridge,
New Museums Site, Pembroke Street,
Cambridge, CB2 3QG, United Kingdom.
Email: tfm@cl.cam.ac.uk
All correspondence should include a return postal address and, if possible,
an electronic mail address.
Please report problems with the web pages to the maintainer