Now, there are many problems in the world of digital security - from governments around the world undermining privacy technology or firewalling their citizens off from information to valiant but underfunded security tools having the time to focus only on keeping the tool safe, but not making it easy to use. Some of these problems are rather significant, some are more approachable, but there remains a hidden problem, so pervasive and pernicious that it undermis all of our good work in bringing usable, human-centered privacy and security tools to wider audiences.
I have a piece up on Medium about our SAFETAG project. It's a project that myself and another colleague have spent countless hours building out to really focus on working with small non-profits on assessing their risks and providing a framework for them to think critically about what really matters to their work, and how to most reasonably address them based on potential impact, real risk of it happening, and their capacity to change digital security practices.
It continues to be very rewarding work, and our tiny team has gotten to see a lot of amazing changes take place by the organizations which have been audited through this process. Anyhow. Check out our piece on Medium: https://medium.com/local-voices-global-change/meet-safetag-helping-non-… , but also take a look at the framework itself at SAFETAG.org. It's an open source framework, and we'd love to see questions and commits over on our github repository!
Pivot-Twist-Dev takes the classic "pivot-twist" approach for idea pitches of taking a familiar concept and twisting it in a new way to the international development space. You might get ideas like "IT'S LIKE TINDER, BUT FOR NATURAL RESOURCE MANAGEMENT" or "IT'S LIKE FITNESS TRACKERS, BUT FOR SOCIAL ENTREPRENEURSHIP." Are they good? Only a pilot project could possibly tell.
Google has been making headlines with their shiny Project Shield which wraps PageSpeed with other tools to defend sites against denial of service attacks. The history of the denial of service, however, runs deep, and underlines that no centralized response to it will ever be able to cost-effectively scale against a distributed attack.
Let's rewind back to the 90s. Denial of service was a very, very different thing then - it was a tool for free expression, not one used to mute dissenting opinions as it is today.
In the dot-com boomtimes of the late 90s, I was absolutely fascinated by the digital protests that sprung up in reaction to Mexico's treatment of the Zapatista Movement. Floodnet was an activist art project by the Electronic Disturbance Theater. Floodnet was simply a website you could visit and it would direct your browser to constantly reload pages on the website of the Mexcian government. In addition to overloading the website with thousands of requests from you and our fellow programmers, you could add in a political message with each page load, to force the government's server to fill their log files with messages like "human rights not found."
"The FloodNet application of error log spamming is conceptual Internet art. This is your chance to voice your political concerns on a targeted server. [...] The server may respond to your intentional mistake with a message like: "human_rights not found on this server." So by creatively selecting phases, you can make the server voice your concerns. It may not use the kind of resources that the constant reloading uses (FloodNet automatically does that too), but it is sassy conceptualism and it invites you to play with clever statements while the background applet is running." (via http://www.thing.net/~rdom/ecd/ZapTact.html)
This original "denial of service" attack was seen as the digital mirror of a classic "sit-in" protest. It was a way for a David to strike back at a Goliath through technology. However, this, ahem, "sassy" political activism began an arms race that today is dominated by Goliaths alone. Instead of a tool of protest, denial of service attacks are today tools of retribution and ways to mute dissenting voices. They are massively automated and distributed, and are run not by rowdy bands of dissidents, but by well-organized for-hire groups (https://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fe…) and even from government infrastructures.
The only defense, so far, has been equally massive, and centralized, commercial services. This is a growing industry with its own round of disruptive innovators all to itself. This current business innovation is helping to move from the monolithic services protecting online infrastructures at high costs to a more scalable model, with services that smaller websites can benefit from. Still, back-end models are the same - providing shelter from DDoS attacks by having sufficient servers and bandwidth to absorb whatever their proprietary tools and filters cannot outright block.
Open source models to fight back have been conspicuous in their absence - until now.
The Deflect Project, created by the eQualit.ie technology collective based out of Montreal and Dublin, is responding to that gap. They focus on providing protection for activists and journalists around the world, who are subject to DDoS attacks from those who disagree with their views all the way to their own governments. Thanks to grant funding, Deflect is able to offer their services for free to independent media sites, NGOs and non-profits -- but the technology model under the hood is the real game-changer.
I've been reflecting on some of the challenges I've faced across multiple organizations trying to leverage the power of technology to create positive social change. This reaches way back to my work as a Peace Corps volunteer, up through grad school, my time as a contributing editor at OLPCNews, and through multiple NGOs balancing tech, impact, and budgets.
Obviously, there's no definite one-size-fits all approach to implementing technology in any sector, much less the world of the international NGO that stretches from hip online platforms to how to best use dusty Nokia feature-phones.
Here are the principles I've come up with to date. I took these to Twitter in a lively discussion, and want to expound upon them a bit more:
- Build for sustainability. Minimize what you have to build yourself, and leverage existing platforms
This means giving strong preferences to open source platforms or at least existing services that meet a set of criteria (their service meets your needs, you own your data, shared values, track record...) For any service, someone, somewhere has already built a powerful framework that will be constantly updated and improved, and bakes in thousands of features (security, translation, powerful content management, mobile interfaces, etc.) which will be effortless to turn on when you discover you need them. Focus your precious software development budget on the much smaller number of things that are custom to your work and don't exist. This greatly reduces the initial dev costs as well as ongoing maintenance costs.
- Seriously, don't build it yourself.
has a hands-on photoshoot with the revolutionary XO-4 convertible tablet/laptop. It has an infrared touchscreen, has refocused its interface to run on top of a standard Linux distribution instead of a customized and tweaked version, and... um... it looks rather familiar. I mean to say, it's almost indistinguishable from the XO-1.
And that's a very good thing. What has happened to the OLPC program is, in many ways, what I'd hoped they'd intentionally choose as a path forward- thoughtful and efficient development focused on impact over glitz, using existing projects and tools where available, and not re-inventing things that weren't broken, but using incremental improvements. Of course, that approach doesn't catch headlines as well, but it does work.
The ICT_Works blog has come out swinging: Linux vs. Microsoft is the most useless debate in ICT4D
As would any sane-minded person after being subjected to a shouting match in Kyrgyzstan. And the core point is absolutely valid - when you're talking about educational outcomes, there is no effective difference:
Educators stressed that teachers already had extensive training on Windows software and would be confused, even lost, in the Linux environment. Students who learned Linux and LibreOffice would be at a disadvantage in the job marketplace as employers would only hire staff that are fluent in Microsoft applications. [...] All of the adults in the conference learned how to use computers back when Windows 98 was in vogue, some even started with Basic, yet no one complains they cannot use an iPhone, iPad, or even MacBook without training.
Two years ago, in the aftermath of the January, 2010 earthquake, hackers and social activists led a charge and saved lives in Haiti from across the sea. Ushahidi remindes us of the scale of this by reposting a blog from the process. Re-reading this through me into a reflective state on how far ICT4D has come in the past few years, and how much more value it brings to the table.
The initial, amazing outpouring of support for earthquake victims in Haiti was heartwarming. The worldwide aid response, not without some hiccups and valid criticism, went well.
The one thread through the global response to the earthquake has been the supporting role that technology has played. At a basic level, SMS fundraising will no longer be seen as a pipe-dream. With deeper impact, however, was the direct role that technology played. We saw the ability of hackers with good hearts around the world to lend a helping hand through infrastructural projects like Ushahidi and Open Street Map as well as engagement tools like The Extaordinaries' iPhone app. Inveneo's ICT_Works blog goes into great detail on the The Rise of the Voluntary Humanitarian Technologist in Disaster Response:
I have a critical flaw - not being able to say no to helping out worthwhile projects get their technological house in order.
I've left a trail of wikis, content management system-run sites, and creative cabling across three continents. One such effort was in the pre-iPhone world of the early 2000s with a creative social enterprise that empowered artisans to realize the full market value of their goods (often undercut by middlemen taking advantage of innumeracy, a need for liquidity, or both). These goods are then shipped to the US to sell. The NGO takes a small cut for its operations and the shipping cost, and everyone benefits. Beyond dealing with the unpredictability of the Nicaraguan electrical system, they were efficient in their offline practices, but saw the need for inventory tracking. That seemingly basic task is both a key to empowering online sales and other scaling activities, but is no short order. The system must be able to know what items were stored in what locations in the US and in Nicaragua, and meet the needs for a geographically disperse set of volunteers to sell those items at events. It also has to have a simple and largely foolproof way of adding inventory from the Nica office that can absorb a backlog of work if the power or Internet connection is off.
No problem - totally doable. For the US side, we work with a Salesforce Foundation volunteer to create an online, cloud-based inventory system where the volunteers can log transactions live on the site using a re-purposed cue:cat barcode scanner -- the cue:cat itself being a dotcom-era QR code wannabe, best summed up by Jeff Salkowski of the Chigao Tribune as "You have to wonder about a business plan based on the notion that people want to interact with a soda can." and by Wired’s Leander Kahney as "a cheapo bar-code scanner that looks like a marital aid."
On the Nica side, the staff can add the inventory on a spreadsheet and batch upload it into SalesForce whenever they have power. This gives them an offline backup, and lets work continue (on a laptop) even if power cuts out. The Excel sheet automatically creates a code that can be barcode-ified for matching by the volunteer sales staff without painstaking scribbling of notes.
We’re in this to save and improve lives, not make a profit. If a plan fails, it’s lives lives - not just bank accounts -- that are not enriched.
Perfect, right? With so much time spent on the “challenging” part of the equation in Nica, not enough thought went into the sales side - often outside, at craft markets, sometimes in the rain. Not happy environments for laptops, rarely enough electricity or battery power to last the day, and never any wifi to actually connect to the Internet to track sales in realtime.
Times have changed, and the plan, like the cue:cat itself, may have a new life in our 3G-saturated world with QR Codes and Square point-of-sale gadgets replacing the bulky laptop, but at the time, it was simply a failure.
What do you do when your project just falls flat? Moving on and hiding it is the wrong answer. The right answer is that you get up in front of a crowd of your peers, donors, and investors (past and potentially future) and spill the beans. In the startup world, some amount of failure is expected, and even welcomed. Learning from failure is, after all, the best education out there. But in the do-gooder space of non-profits and international development organizations, failure is not an option.
The challenge is that we’re in this industry if you will to save and improve lives, not make a profit. If a plan fails, it’s lives lives - not just bank accounts -- that are not enriched.
There are obviously failures in development, as evidenced by the mere fact that we’re five to six decades in to concerted global efforts, and still working on it. More ICT4D projects fail than ever scale beyond the pilot stage. The World Bank bravely released its internal study revealing that while most of its projects succeed overall, in the ICT4D category of projects, only achieve their intended outcomes 30% of the time. Some of those may be wildly successful in unanticipated ways, others just complete flops.
Katrin Verclas has done the community a huge favor in creating and open-sourcing the concept of the FailFaire.
The Failfaire celebrates and de-stigmatizes failure by loosening lips with some alcohol and then throwing people on staqe for a tightly scheduled 5 minute moment of candor. Thanks to the open-source philosophy, these have spread to internal organizational events as well as a few public failfaires, most recently one hosted by Inveneo’s Wayan Vota in DC at the World Bank itself, and another coming up this December in NYC hosted by MobileActive.
The risks of failure in development work are clearly weightier than Q3 profits,which makes the relaxed, raucousness of a failfaire that much more important. For a community that has no normal mechanism for learning across the various implementers, the only way we can advance the whole cause is through these commiserations over good goals, good people, and solid technology completely failing - and learning from them.
This was best encapsulated after the event. One presenter discussed his media-darling pedal-powered phone booth for remote villages, which was a complete failure. Another Failfaire-er approached him afterwards to commiserate on similar problems - their own popular bike-powered computer system actually took almost seven people pedaling to reliably power the system. While bikes garner tons of often-misguided warm feelings and media popularity, they aren’t necessarily silver bullets -- a lesson for the road.
I will be discussing the tech trends from 2011 and looking forward to what 2012 holds for us with a fine group of panelists during DCWeek. Our panel still has some free tickets left - RSVP at http://www.meetup.com/net2dc/
Want to get in the action early? Join our thread over at Quora.
Read more about the event at DCWeek: http://bit.ly/dcweektechtrends1108