[CAP] Decrease milling when increase trust RE: Vol7 #2

[Rex Buddenberg]

There are about three issues floating around here and we have to unravel
them else we get cause <--> effect non-fits.

The original question was doubting the authenticity of a message -- when
I get one out of the blue, and only one, is it credible?  This is an
authenticity problem, pretty pure and simple, and the XML-sign function
is the appropriate way to digitally sign these messages.  External to
the standard, we need to have a public key infrastructure that supports
verification of the public keys.
	The proposal of using a swarming solution to solve an authenticity
problem is a non-fit.  The solution doesn't match the problem.  And
habitual use of it will lead to reality-by-rumor situations which is
clearly not good.  

The issue Henry is after below is not an authenticity issue, but a
cousin: integrity.  The digital signature solution can guarantee
integrity of data in transit (the 3.7 and 7.3 numbers can't get
transposed over the comms system without the message digest failing) but
it doesn't address the initial data composition (before the message is
signed).  
	But the swarming solution is not appropriate either -- because that
would also happen _after_ the data composition is done.  How many times
have you seem multiple news sources propagating, ad nauseum, the
same .... wrong .... data? 
	IMHO, CAP provides a pretty good lever into this problem.  Most data
transposition problems that I've seen over the years have to do with
human data readers transposing numbers*.  Mechanizing these operations
is a key to eliminating these error sources.  


Rex Buddenberg
Naval Postgraduate School
Code IS/Bu
Monterey, Ca 93943

831/656-3576




*in a former life, I remember several cases where ship operators quoted
positions, read right off the Loran set, that would have put them
several miles inland. A lot of these were properly troubleshot as one
degree of longitude off -- clearly not the machine's problem.
	In telegram messages of yore, both military and civil, it was well
understood that numbers could get easily corrupted.  Letters could too,
but word context usually let the reader mentally fix, a crutch not
available for numbers.  So numbers were often repeated (in at least one
format that I learned, they were all re-recited at the bottom of the
message as an integrity check.  And in many systems, the keyboards
simply didn't have numberal keys -- you had to spell out the numbers to
reinsert the context crutch.   

On Fri, 2006-01-06 at 09:09 -0800, Henry Lahore wrote:
> >CAP alerts imply a centralized method of distribution, which is how
> most emergency alerts are propagated.  For the swarm system, a separate
> protocol would need to be developed, that perhaps encapsulates or
> provides translation to a CAP alert instead.  
> A centralized method of distribution, bases on a single source, is
> fraught with errors. Very few people will quickly spend resources
> (emotion, ego, gasoline, time, money, ...) based only on reception of a
> single message. 
> 
> It does not matter who a centralized message is from: police, USCG,
> Homeland Security, mayor, president, ...  If the message is not
> confirmed/endorsed/trusted very few people will immediately react.
> 
> There are just too many reasons that a single message might not apply to
> the recipient, so will not be believed until it is trusted - often by
> getting confirmation from or via additional sources.  
> Example causes of an erroneous message:
>   Sender mis-interpreted information
>         did not correctly hear the location of the disaster
>         transposed the magnitude of the disaster (quake 3.7 vs. 7.3)
>         mis-read the radar screen - location, magnitude, etc.
>   Human error: 
>         entered wrong location: center, radius, polygon end-point, ... 
>         entered wrong time: transpose 5:09 and 9:05
>         entered wrong type of disaster, 
>         entered wrong certainty, 
>         pushed wrong button
>   Software or simulation error: 
>         software/model was not designed for the situation
> As a system designer, I became aware of the huge number and types of
> errors which are possible and how a good system design can virtually
> eliminate errors from humans, software, hardware, and communications.
> Some examples of systems which are designed to have very very little
> error include: aircraft, air traffic control, and nuclear power plants.
> _______________________________________________
> This list is for public discussion of the Common Alerting Protocol.  This list is NOT part of the formal record of the OASIS Emergency Management TC.  Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> CAP-list mailing list
> CAP-list at lists.incident.com
> http://eastpac.incident.com/mailman/listinfo/cap-list
> 
> This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself.
-- 
Rex Buddenberg
Naval Postgraduate School
Code IS/Bu
Monterey, Ca 93943

831/656-3576