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

[Rudman, Richard A]

Rex and the group:

>From the point of view of EAS entry points to the broadcast world, you have
nicely summed up comments I was in the process of writing up for this
discussion. 

There's over 60 years of research on how the public reacts and does not
react to warnings. CAP drew many of the lessons learned from this research
reservoir as CAP was hatched.

A goodly amount of those lessons, as many of you know, are in the form of
research done at the Natural Hazards Center at the U. of Colorado. Should
anyone not familiar with what the NHC and specifically wish to peruse this
body of work, specifically the research on EPI that Dennis Mileti & various
cohorts contributed, the NHC site is at: http://www.colorado.edu/hazards/

Richard Rudman
California EAS State Emergency Communications Committee
Vice Chair

========

on 1/6/06 9:48 AM, Rex Buddenberg at budden at nps.navy.mil wrote:

> 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.