WorldChanging ally W. David Stephenson, who specializes in distributed security strategies, crafted a list of what he would consider the ten key elements of an effective security model. It struck me as I read his list that most of these are precisely what would be needed for a distributed, reliable warning and response system for any kind of emergency, including natural disasters.
In Stephenson's model, the system elements should:
Also have day-in-day-out applications so that they will both be familiar in an emergency (i.e., not requiring users to have to learn something new when they're already stressed) and will have economic and/or social benefits so their purchase and deployment are more easily justified. Be decentralized, so they are less likely to be rendered inoperative by attacks on a centralized switching facility, etc. Be in the hands of the general public, so they leverage technology that is already in use (and, given the inevitable cost and procurement limits of government technology, more current) and that people are likely to have with them when disaster strikes, so they can get up-to-the minute information. Be location-based, so that we can get away from lowest-common denominator evacuation and response plans that are likely to cause their own problems such as traffic jams. Empower the public, because authorities may themselves be incapacitated and our fate will be in our own hands, and because we may be more likely to listen to trusted friends and/or neighbors than distant authorities. Be two-way, so that the general public and/or responders who may be the first to come upon an emerging problem can feed information back to authorities. Be redundant, because various technologies have distinctive strengths and liabilities that may render them unusable, or, make them crucial fall-back options. Allow dissemination of information in advance, so they can be quickly activated and/or customized in an emergency (instead of requiring massive data-dumps in the midst of a crisis). Be IP based, because packet-based information will require less bandwidth in a situation where conserving it is crucial. Foster collaboration, because multiple agencies and jurisdictions may be involved and will need to share information from a wide range of sources on a real-time basis.
If you replace the word "attacks on" in the second item with the more general "damage to," you have an excellent starting checklist for what a disaster response system would need. The emphasis on the empowerment of the public as both users of and contributors to the workings of the system is particularly important. We all have a responsibility to look out for each other, and -- as examples from open source to election protection show -- informed, aware groups can often do what centralized authorities cannot.
As nice as a 10 point list is, however, it's missing a few important elements; design needs don't always fit into nice round numbers. We've frequently discussed ideas and models of sustainable, long-term, functional design here. Drawing from some of them, we can flesh out some of the other points a smart, modern disaster-secure system would need to cover.
Designing for the Long Term talks about what goes into constructing "social infrastructure" systems meant to last for extended periods of time. A system for disaster security would certainly fall into that category. From these design principles, the following seem to be the most important additions to our list:
- Transparency to determine when changes are needed and that undesired functions are not being performed.
- Verifiable trustworthiness of [...] the above.
These two go hand-in-hand. A distributed emergency warning and response system shouldn't be prone to fraudulent or improper use, period. One way to make sure that an emergency message is the real thing is to embed transparency throughout the system. Users shouldn't have to simply trust that messages are real; they should be able to find out where the messages are coming from, what information is backing up the messages, and what kinds of confirmations there are that the problem is real and needs to be acted upon. And at times when there is no emergency underway -- that is, the vast majority of the time -- users should be able to feel confident that the system isn't down or unreliable.
This brings us to a selection from Principles of Humane Systems. Humane systems are those designed to be a source of comfort and utility, not irritation. The key element from this set is:
- Default to harmlessness. Systems fail; when they do, they can fail gracefully or they can fail catastrophically. When a system fails, it should do so in a way which does not itself make problems worse.
This one is absolutely critical. When problems happen with the system -- and they will -- failure should not exacerbate an already-bad situation. Failure of one part should not interfere with other, still-functional, elements. A "system failed" state should be readily distinguishable from an "all clear" state. A damaged system should not send out unintended messages (such as messages meant as drafts or tests). And a partially-damaged system definitely should not be open to abusive or intentionally deceptive use.
The "Viridian Principles" list, constructed in large part by WorldChanging Ally #1 Bruce Sterling, contains a number of intriguing sustainability-focused rules, most of which are more appropriate for object design rather than system design. But the following stand out as being particularly relevant to disaster-secure design:
- Avoid the Timeless, Embrace Decay ...Nothing physical is eternal. It's very bad design to create some device which quickly ceases to function, while its useless components persist around us, ugly and dangerous.
- Design for the Old. The median age is advancing steadily around the world. The 21st century will have a historically unprecedented demographic structure. Short of catastrophe and mass slaughter, we will never see the 20th century's youthful demographics again. The senior members of society have their own ergonomics and anthropometrics. If you don't design for them, you're designing for an ever-shrinking fraction of the world.
- Make the Invisible Visible. Our primary advantage over previous generations of artists and graphic designers is that we can see much better than they could. We can manipulate, store, create and analyze graphic imagery with historically unprecedented ease and power. This trend should be recognized, advanced, and artistically exploited. Advances in instrumentation can be used to change the zeitgeist. If carbon dioxide were blood-red, our skies would look ominous indeed.
The first acknowledges that technologies change, infrastructure changes, and societies change. A good system for reliable disaster warning and response should not be tied inextricably to an ultimately temporary technology or behavior. We should expect to have to replace elements at regular intervals; this will prompt us to re-examine our assumptions about what we need and what we are trying to accomplish.
The second is relevant even if those parts of the world where the demography is dominated by the young. Improvements in health care and education (especially for women) invariably result in lower birth rates and a steadily aging population. Our system shouldn't fall prey to the seduction of whatever is currently popular with teenagers, but should strive for broader accessibility and usability.
The last principle is one we discuss frequently here at WorldChanging. We are surrounded by invisible data, whether streaming through the air as wireless bits or intrinsic to our ever-increasing understanding of the world around us. A well-designed system should, wherever possible, make available information about where the user is that the user could not otherwise observe, but would help the user make better decisions. What's the best path to safety? Is there something in the air or water which could be dangerous to me and my loved ones? Is the road ahead flooded or blocked or damaged? Is clean water or food available? Is another wave (or storm or, eventually, earthquake) coming? Who should I talk to or go to for help?
Make no mistake: one of the results of the tragedy in the Indian Ocean will be new systems for public safety and disaster warnings. Most of these will be poorly-designed, with significant flaws, openness to abuse, and ultimately fatal failings. We all should have a voice in the selection and implementation of systems to protect us; that voice should be well-informed and confident. Principles for good system design exist, and we should not be afraid to demand them.
(Update: David Stephenson sends this comment: Jamais: I'm deeply honored that you built on the "smart mobs for homeland security" framework for this emergency communications strategy -- your elaboration is a perfect example of why I said it needed to be collaborative. Another thing which I think parallels the "embrace decay" concept is that any strategy should be iterative, designed with feedback loops to elicit comment, then constantly revise the plan based on the feedback. One of the things that disappoints me about the Ready.gov web site is that it took until February 2003 to get it up (leading,incidentally, to allegations that it was prepared more as part of building a war mentality among the public on the eve of Iraq, rather than really trying to inform and involve the public). There should have been a rudimentary, no-cutesy graphics, site up Sept. 12, 2001, with basic info already available from FEMA and the Red Cross, then constantly updated.)
Comments (1)
I've started a livejournal community to discuss the issues surrounding this. If anyone wants to join/have a look it's at http://www.livejournal.com/community/disaster_relief/
Posted by Alex | January 1, 2005 9:37 AM
Posted on January 1, 2005 09:37