Ashoka
Last month I taught the first ever course on “Technology and Peace” at the UN-mandated University for Peace (UPEACE) in Costa Rica. The course drew 16 participants from 11 countries, representing a number of distinguished organizations including Ashoka, the Council on Foreign Relations and George Mason University’s Institute for Conflict Analysis and Resolution (ICAR).
Participants engaged in discussions, case studies, and practical exercises involving how technology can be used for building peace. The course made use of new technology-focused teaching techniques to ease the learning process. (Read more about the course in Studying on the Frontier of Technology and Peace and on the TechChange blog).
One of the highlights of the course was a two-hour simulation of the Ushahidi crisis mapping software. The goal of the exercise was to have participants understand the possibilities and limitations of crisis mapping through a practical application.
To make the simulation realistic we built it around the upcoming Wolesi Jirga elections in Afghanistan, set for September 18th 2010. This election has been postponed several times due to corruption and many experts are concerned that it might lead to new violence by the Taliban to intimidate voters.
The process:
1. Software: Ushahidi’s open-source software was installed onto a Web-based server. Because of the location and limited participants with cell phones that worked in Costa Rica, I decided not to install FrontlineSMS. The campus did have wireless Internet, so participants used laptops and smartphones to send messages from the field.
2. Designated Polling Stations: Four polling stations were scattered around campus. Each polling station had a piece of paper with detailed conditions about the level of violence and whether or not the station was open. Once underway, I circulated around campus to change the papers and post new conditions.
3. Four Groups: The class was organized into four groups of four people each:
Group 1: UN Officials: UN officials were based in the classroom or UN headquarters in Kabul. Their goal was to use Ushahidi on their computers to (1) ensure as many citizens as possible made it to the right polling stations and (2) ensure that international media had an accurate account of what was happening on the ground.
Group 2: Election Monitors: This group played the role of election monitors stationed in Kandahar. They were tasked to work with the UN headquarters staff in Kabul to ensure as many people as possible made it to the right polling stations to cast their vote.
Group 3: Citizens: This group played the role of Afghan citizens eager get out and participate in the democratic process but concerned about their safety. They had to figure out as a group how to use Ushahidi’s alert system to receive updates about polling center violence. Citizens were asked to vote one by one at 10-minute intervals, regardless if any alerts had been sent out.
Group 4: Taliban: This group was tasked with the goal of disrupting the election process and the Ushahidi platform in any “cyber” way possible.
The Action, Resulting Learnings, and Aspects for Further Reflection
1. Communications Strategy: The UN team and volunteer election monitor group came up with a strategy to ensure only messages coming from election monitors were validated by UN staff. Because the Taliban could read the same reports off of the Ushahidi platform, the election monitoring team assumed that hashtag or number systems might not work so they devised a code based on the placement of word “violence” in the sentence. The Taliban group never cracked the code but the reports from Citizens at polling stations were also not validated. This points to a very real challenge NGOs and governments face when using Ushahidi—do they accept crowdsourced information from the public or limit their scope to NGO staff? There are tradeoffs with each strategy.
2. Trade-Off Between Time and Accuracy: After ten minutes, the first citizen voted but the UN staff group and election monitors had not figured out the Ushahidi system in time to validate and disseminate reports. After approximately 15 minutes they learned the system. 40 minutes into the simulation, the Taliban group decided instead of trying to subvert the process with accurate-sounding bad data, they would try and overwhelm the system by sending as many reports as they could. Even though the UN knew the reports were erroneous it took them precious time to consider and dismiss them. I am eager to see how SwiftRiver and other filter systems might be able to combat this strategy.
3. Email Alerts Didn’t Seem to Work: The citizen group signed up to receive email notifications but never received alerts during the exercise. I’m not sure if this was a human error on our end or some kind of built-in software delay. Instead the citizens monitored the map on the website and read the live feed of validated reports coming through the system to make decisions about where to vote.
4. Password Security: During group orientation I wrote the login, password and URL for everyone to see. The defaults were “admin” and “admin.” Halfway through the simulation I reminded the Taliban group that the passwords might still be the default. Indeed, the UN staff had not changed the password and the Taliban group was able to log in and start validating their own erroneous reports. Once the UN staff realized their system had been compromised, they tried to change the password but it was too late.
Some critics maintain election monitoring may not the best use of Ushahidi, and that it is really best for logistical coordination and mapping, as we saw in Haiti. Perhaps, but election monitoring provides a great context to run a simulation examining Ushahidi’s potential and limitations. After two hours, all 16 participants came away with a great command of how to use this important technology. I’m eager to work with others to design similar simulations. Please leave feedback, questions and suggestions in the comments, or e-mail [email protected]
(Cross Posted from Ushahidi Blog and the TechChange Blog)