Tag Archives: 2013

A Turkana Solar Eclipse Expedition

It’s been a few years since I was last up in the northern reaches of Kenya, and what an adventure that was! (blog posts 1, 2, 3 and 4)

BRCK Solar Eclipse trip, photo courtesy of Barak Bruerd on our last trip up to Northern Kenya

BRCK Solar Eclipse trip, photo courtesy of Barak Bruerd on our last trip up to Northern Kenya

This week finds me heading back, chasing the moon that will cover the sun. November 3rd at 5:30pm (East Africa Time) there is a hybrid solar eclipse. The lunar-like desert setting on the edge of Lake Turkana is said to be the best place in the world to watch it.

This also happens to be one of the most difficult places to get to, as fuel and supplies are a difficult thing to come by for the final 1000 kilometer loop. You have to bring it with you. It’s an unforgiving place, and yet one of the most hauntingly untouched and beautiful stretches of Africa that you can still find.

Solar Eclipse Path, Nov 3, 2013

Solar Eclipse Path, Nov 3, 2013

Though one never needs an excuse to have an adventure, the BRCK team is using this trip to stress test the device. We have a number of things planned, covering ruggedness and heat to testing out an amplification antenna with it. With luck, we’ll even have a VSat connection in hand, and test out WiFi via satellite internet backhaul and stream the eclipse live. You’ll be able to watch that at BRCK.com/eclipse.

[update: Huge thanks to Indigo Telecom for loaning us a BGAN terminal and 50Mb of data!]

Seven of us are trekking up to this iron triangle; where Sudan, Ethiopia and Kenya meet. We’re taking three 650cc motorcycles and a Land Rover 110. Two happen to be professional photographers, two others are highly talented amateur photographers, and I’m going as the hack iPhonographer. :)

Sibiloi National Park, by Lake Turkana in Northern Kenya

Sibiloi National Park, by Lake Turkana in Northern Kenya

Our destination is Sibiloi National Park (KWS site), possibly the least visited and most unknown park in Kenya. It’s a good few hours drive north of Loyangalani, which I’m curious to see after the past few years. As far as I can tell, there is really no reason to ever go there, well, except for an eclipse…

I’ll be blogging our adventures here, as well as with others on the BRCK Blog. You can follow the images and livestream at brck.com/eclipse.

[Note: It should go without saying, but I won’t be answering many emails…]

A 2013 Uchaguzi Retrospective

MRTN8684


UPDATE: Here’s the report put together by the iHub Research team (3Mb PDF): Uchaguzi Kenya 2013

The elections in Kenya this year have had a lot of drama, nothing new there. As I wrote about last week, Ushahidi has been involved quite heavily on the crowdsourcing side via Uchaguzi, which meant that we had an exhausting week as the results kept getting extended each day.

Uchaguzi Update

Some basic statistics:

  • 5,011 SMS messages sent in (that weren’t spam or junk, as those got deleted)
  • 4,958 reports were created (from SMS messages, the web form, email and media monitoring teams)
  • 4,000 reports were approved to go live on the map
  • 2,693 reports were verified (67% of approved reports)

Notes and Links:

  • Many reports, links an updates can be found on our virtual situation room
  • The analysis team provided twice daily rundowns based on verified data at http://visuals.uchaguzi.co.ke/
  • Rob created a map visual to show the reports coming into Uchaguzi over time.
  • The IEBC tech system failed, I started a Tumblr trying to figure out how the system was built, which companies were involved and what they did, and what actually went wrong.
  • Before the IEBC tech system was shut off, Mikel used their API to create maps (1, 2) and Jeff and Charles created a mobile-friendly results site as well.
  • Heather wrote up a good post on our situation room blog about what we’ve learned along the way.

Here’s an Uchaguzi community graphic:
Uchaguzi community graphic

Kenya’s 2013 IEBC Election Tech Problems

TL;DR – Kenya’s IEBC tech system failed. I started a site to collect notes and facts, read it and you’ll be up to date on what’s currently known.

Kenya’s IEBC (Independent Electoral and Boundaries Commission) had an ambitious technology plan, part based on the RTS (Results Transmission System), part based on the BVR (Biometric Voter Registration) kits – the latter of which I am not interested in, nor writing about. It was based on a simple idea that the 33,000 polling stations would have phones with an app on them that would allow the provisional results to be sent into the centralized servers, display locally, and be made available via an API. It should be noted that the IEBC’s RTS system was a slick idea and if it had worked we’d all be having a much more open and interesting discussion. The RTS system was an add-on for additional transparency and credibility, and that the manual tally was always going to happen and was the official channel for the results.

The Kenya IEBC tech system elections 2013

On Tuesday, March 5th, the day after the elections, the IEBC said they had technical problems and were working on it. By 10pm that night the API was shut off. This is when my curiosity set in – I didn’t actually know how the system worked. So, I set out to answer three things:

  1. How the system was supposed to work (Answer here)
  2. Who was involved and what they were responsible for (Answer here)
  3. What actually failed, what broke (Answer here)

Turns out, it wasn’t easy to find any answers. Very little was available online, which seemed strange for something that should be openly communicated, but wasn’t. We all benefit from a transparent electoral process, and most especially for transparency in the system supposed to provide just that.

So, I set up a site to ask some questions, add my notes, aggregate links and sources, and post the answers to the things I found on the RTS system. I did it openly and online so that more people could find it and help answer some of the questions, and so that there would be a centralized place to find the some facts about the system. By March 6th, I had a better understanding of the flow of data from the polling stations to the server and the API, and an idea of which organizations were involved:

  • Polling station uses Safaricom SIM cards
  • App installed in phone, proprietary software from IFES
  • Transmitted via Safaricom™s VPN
  • Servers hosted/managed by IEBC
  • JapakGIS runs the web layer, pulling from IEBC servers
  • Data file from IEBC servers sent to Google servers
  • Google hosted website at http://vote.iebc.or.ke
  • Google hosted API at http://api.iebc.or.ke
  • Next Technologies is doing Q&A for the full system

IEBC tech system diagram

Why now? Why not wait a week until the process is over?

It’s been very troubling for me to see people speculating on social media about the IEBC tech system, claiming there have been hackers and all types of other sorts of seeming misinformation. Those of us in the technology space were looking to the IEBC and its partners for the correct information so that these speculative statements could be laid to rest. I deeply want the legitimacy of this election to be beyond doubt. The credibility of the electoral system was being called into question, and clear, detailed and transparent communications were needed in a timely manner. These took a long time to come, thus my approach.

Interestingly, Safaricom came out with a very clear statement on what they were responsible for and what they did. Google was good enough to make a simple statement of what their responsibilities were on Tuesday. both of these companies helped answer a number of questions, and I hoped that the other companies would do the same. Even better would have been a clear and detailed statement from the head of IEBC’s ICT department to the public. Fortunately they did provide some general tech statements, claimed responsibility, refuted the hack rumor, and made the decision to go fully manual.

My assumption was that since this was a public service for the national elections, that the companies involved would be publicly known about as well. This wasn’t true, it took a while asking around to get an idea of who did what.On top of that, In a country that has been expounding on open data and open information, I was surprised to find that most of the companies didn’t want to be known, and that a number of people thought it was a bad idea to go looking for who they were and what they did. I wasn’t aware that this information was supposed to be secret, in fact I assumed the opposite, that it would be freely announced and acknowledged which companies were doing what, and how the overall system was supposed to work.

I’ve spoken directly to a number of people who are very happy that I’m asking questions and putting the facts I find in an open forum, and some that are equally upset about it. Much debate has been had openly on Skunkworks and Kictanet on it this, and when we debate ideas openly we fulfill the deepest promise of democracy. My position remains that this information should be publicly available, and the faster that it’s made available, the more credible the IEBC and it’s partners are.

By Friday, March 8th, I had the final response on what went wrong. My job was done. Now it’s up to the rest of the tech community, the IEBC and the lawyers to do a post-mortem, audit the system, etc. I look forward to those findings as well.

Finally, I’ll speculate.
My sense of the IEBC tech shortcomings is that it had very little to do with the technology, or the companies creating the solution for them. It was a fairly simple technology solution, that had a decent amount of scale, plus many organizations that needed to integrate their portion of the solution. Instead, I think this is a great example of process management failure. The tendering process, project management and realistic timelines don’t seem to have been well managed. The fact that the RFP due date for the RTS system was Jan 4, 2013 (2 months exactly before the elections) is a great example of this.

Some are saying that the Kenyan tech community failed. I disagree. The failure of the IEBC technology system does not condemn, nor qualify, Kenya’s ICT sector. Though this does give us an opportunity to discuss the gaps we have in the local market, specifically the way that public IT projects are managed and the need for proper testing.

It should be said that all I know is on the IEBC Tech Kenya site, said another way, read it and you know as much as me. There is likely much more nuance and many details missing, but which can only be provided by an audit or the parties involved stepping forward and saying what happened.