in privacy, Uncategorized 1,540 Words

How do we pay for privacy?

 

If you haven’t read Julia Angwin’s excellent profile of GnuPG’s lead developer Werner Koch, now would be a great time to check it out. Koch, who single-handedly wrote GnuPG in 1997, has been doggedly maintaining the codebase ever since — and not getting paid very well for it. Despite good intentions on all sides, Koch has been essentially going broke.

The news is not all bad. In response to Angwin’s piece, ‘the Internet’ rallied to GnuPG’s aid. So far individual and corporate donors have coughed up over EU 200,000 to pay Koch and even hire him some help. It looks like GnuPG is saved, and so are its users — for the moment.

But is this model really sustainable? I’m pretty skeptical.

Sooner or later this money will run out. And next time this happens, the Internet might not have a quarter million in spare change to fork over. In fact, that’s already the normal state of affairs for most privacy tools — software ranging from GPGTools to OTR — most of which subsist on meager donations and volunteer time. The scary part is that thousands of people depend on these tools for their privacy and even their physical safety.

This raises a question: how can we support the long-term development and maintenance of privacy tools? It turns out that nobody really knows the answer to this — but a few people are groping towards a solution. In this (entirely non-technical) post I’m going to talk a bit about what people are doing today — and how we might do better in the future.NB: I should mention that most of the smart ideas in this post come from Meredith Whittaker, who leads Google’s Open Source Research Group, and helped found Simply Secure. The dumb ideas are all mine.

How we support privacy tools today

If you’re developing, or are interested in developing privacy tools in 2015, there are a handful of funding sources for you to choose from. They include:

  1. Self-funding. The vast majority of privacy tools come from engineers working in their spare time. This is a great way to develop prototypes and simple tools, but it tends not to be very sustainable — particularly when developers have to choose between family and code maintenance.
  2. Donations, charges and crowd-funding. A few major projects pull in some cash through donations, but this seems to work well only during a catastrophe or when the spotlight is on a particular project. GnuPG, for example, made a ton of money following their recent publicity, but before that they averaged a minuscule $20k per year — and this is for one of the most widely used privacy tools on the Internet! Projects like GPG Tools recently began charging for their software, which may work a bit better. Unfortunately this is anathema for young projects that rely on network effect for their success.
  3. Industry grants. From time to time major corporations give out modest chunks of money to tool developers, particularly when those companies use tools internally. Case in point: Google Stripe and Facebook just gave $50k each to GnuPG, and the Linux Foundation Core Infrastructure Initiative (essentially an industry funding group*) kicked in an additional $60k. Unfortunately this money is tragically difficult to come by — for the average developer it might as well not exist.
  4. Government and NGOs. Perhaps the most promising source of money comes from the U.S. government, and a set of NGOs that have sprung up to disburse it. The State Dept. directly funds the Tor Project, and the government also provides block grants to groups such as the Open Technology Fund (via Radio Free Asia) and the — confusingly similar — Open Technology Institute (at New America Foundation). OTF in particular has done a phenomenal job at funding both development and audit of privacy tools.
  5. Internal industry funding. Once in a blue moon a company proposes to internally develop a privacy tool like Google/Yahoo End-to-End. I’ll believe this works when I see it.
  6. Academic research funding. A few academic tools have managed to slip into this space, most notably OTR and Tor. But this model is awfully hard to sustain, mostly because academics don’t get paid to do things. We get paid to teach and write papers. It’s hard to sustain software development this way.
  7. Bitcoin wallet theft. This is mostly a joke.
Of these funding sources, the U.S. government is by far the heaviest hitter — responsible for funding many well-known projects such as Tor and TextSecure. While I tend to think any money is good money in the hands of right people, I should point out that this view is not universally shared. In part this is because we, admittedly, don’t have much of a process to validate code and convince non-experts that this process isn’t producing compromised code.

As Jillian York points out, US government funding also comes with some political baggage, and sadly, tends to attract more than its fair share of paranoia.

Developers need more than just money!

If you give a starving privacy tool a million bucks, you get a well-fed privacy tool. Unfortunately it may not actually be a better privacy tool. That’s not because people are trying to waste your cash. It turns out that software development, crypto, and security are just plain hard.

So yes, people need to eat — that’s a baseline. But beyond that what developers also need are things like expert guidance, security audits, analysis tools, and collaboration with other developers. They also really need help with the hardest problem in computer science, which is turning a pile of code into a product that people want to use.

A few groups like OTF (in case you’re not getting the hint, I really like them*) are trying to help with some of this. They fund professional code audits through groups like iSEC Partners. They fund usability resources and provide communications help. They host regular meetings where project members can get together and dork out about how to handle encrypted spam. A friend calls this a ‘dog park for developers who haven’t been outside for a while.’ This sounds silly, but it really, really helps.

Beyond those things, there’s still an awful problem of coordinating all of this technical stuff so that auditing results adhere to some consistent standard and produce knowledge that gets retained within the organization, as well as seeing that tools get proper academic analysis where necessary. And finally, there are useful services such as connecting developers with UI designers and helping them to turn their tools into real, usable products.

A few groups have done well at this all on their own. Moxie’s Open Whisper Systems not only launched a popular messaging app, but managed to get TextSecure (the protocol) into 600 million WhatsApp clients. Unfortunately this kind of success doesn’t come easy to people and requires a lot of assistance. Institutions can really help.

How can we do better?

There are a lot of answers to this question. But since this is a blog post, let’s swing for the fences. What’s really needed is a privacy incubator. A place that provides both funding (or at least, guides funding) as well as in-house technical staff and researchers, non-technical help such a communications, infrastructure, a great advisory board, and access to tools and engineers.

In essence this center would combine all the best parts of NGOs, academic institutions, and corporate research into one center. It would help with projects ranging from research to development, and would also provide infrastructure for developers — helping to keep them from re-inventing the wheel with each new idea, and perhaps even helping projects to merge when one has strengths. Connecting them with corporations who could conceivably deploy their tool.

This organization could also provide resources ranging from legal advice to marketing, two areas that software developers are notoriously bad at. It might even provide important, but miscellaneous resources like healthcare.

Please keep in mind I’m not advocating the creation of an entirely new organization — god forbid, we have enough of those already (the XKCD cartoon at right comes to mind). Instead, the goal should be to identify organizations that are already working and either connect that, or build up their capabilities with a large infusion of cash.

Anyway, we can all dream. But this is a dream that would actually make some difference.

So will this happen?

I guess it depends on the will and the money. It also depends on us: that is, on the willingness of the technically focused privacy/security community to accept that many of the elements we need to succeed are outside of our personal realm of expertise, and we need help with them.

Friends of mine also keep telling me that there are major philanthropic organizations out there looking to make a difference in this area. I’m still waiting to see it happen, but wheels turn slowly. One thing I can tell you: it wouldn’t take much to do better than what we have today.

* Full disclosure: I’m on the advisory board for Linux Foundation’s Core Infrastructure Initiative. I also once sat in on an advisory board meeting for OTF. Nobody paid me — but they did feed me lunch.

11 thoughts on “How do we pay for privacy?”

  2. There's another way of looking at the funding problem that I haven't seen anyone mention yet. Look at OpenSSL – which has had similar funding problems in the past – and compare it to projects like BouncyCastle or Crypto++, neither of which have had funding problems. The reason for this is that they're actively supported, maintained, documented, not riddled with bugs and security holes, and the code isn't awful. The reason why OpenSSL has funding problems is that it's so ghastly that no-one in their right mind would pay money for it. Less awful crypto libraries don't seem to have the same funding problems. GPG isn't quite as bad as OpenSSL – I'm not sure that any other crypto can be that bad – but it's still horribly bloated, hard to use, and when you look into the source, badly written code. Maybe the reason why it has trouble getting funding is that people don't consider it worth paying for…

  3. One thing hasn't been mentioned in the Probublica piece: Koch operates a company http://g10code.com/ with the purpose to maintain and propagate GnuPG. Obviously he's not a business guy, which is a rare thing among programmers. So, it is not GnuPG in jeopardy but Koch's private existence, which is his own fault. Why should I donate money then?

    And, as the previous poster already mentioned, if Koch would behave a little more open minded, build a developer community around the project and not behave like a dictator, then GnuPG would not depend on Koch entirely.

    I am a developer of crypto software as well and I reject the scheme of funding. Either you operate a company with which you maintain the software (and there are lots of examples where this works) or you've got a job to make money. I would never take money from companies like facebook or google and certainly not from any government.

    Instead what would be needed would be an organization (like the FSF) to operate some kind of community building process. So if someone is not good with communication or marketing, then the organization could take the job, find developers who will share maintainership of the code and make support, have an eye on the developers, and the like. And the organization could then collect money, if required.

  4. Speaking of OpenPGP, and OpenSSL, I was on the RFC2440 committee and wrote a THIRD interoperable implementation – which found a minor bug in PGP 5.0 since part of what I did with it was regression test (run through every combination of every algorithm and option) my implementation v.s. GPG v.s. PGP5.0. It is still out there somewhere and was small enough to work on a Palm (pilot). It used SSLeay which became OpenSSL.
    PGP 5.0's source code was available (to be faxed, when that was the only way you could export Crypto). PGP's source was several massive tomes. The PGP part was around 2000 lines and I wrote it to be faxed. I also had a one page “add ssl to lynx by setting a proxy”.

    Perhaps the one way to make this work is to fund “reference implementations” – find really good coders and pay them to write clean code and audit it, and then have a maintenance group – but Google, Apple, RedHat and the rest could find problems and submit patches. We have the RFCs, and standards but we don't have clean implementations of many of them.

  6. In my experience, a lot of people who complain about lack of donations don't offer recurring donations (like GPG, and several webcomics). If you find yourself begging for money every month, but don't offer recurring donations, you need to rethink your strategy. I suspect GPG will run into the same situation again in the future since no one will remember to keep paying them.

  7. Demonstrably non-backdoored crypto has to be open source, which means that it has to be a public good. Public goods are hard to fund, because people usually won't pay for them if they think other people will pay for them, and everyone will benefit, whether they've paid or not; and people usually won't pay for public goods if they think no-one else will pay for them, unless they think their single donation is make-or-break for the public good to be provided.

    But there are ways of encouraging people to pay for public goods. For example, I came across https://snowdrift.coop/ recently, in which a small donation can automatically make other people also donate more; if your donation is more likely to make a difference to whether the public good is provided, you're more likely to donate.

    Also, there's the idea of software completion bonds, or the “Wall Street Performer Protocol”, which I read about here: http://firstmonday.org/ojs/index.php/fm/article/view/865/774 . Essentially, people who want the public good bet that it won't be provided, and aren't upset if they lose the bet (because the public good is provided); and people who can help provide the public good bet that it will be provided, make it happen, and get paid by winning the bet.

    Another option (which doesn't require the establishment of bond markets!) is that someone offering to provide public goods promises to provide one of two public goods (maybe two different requested features for the same piece of open source software), depending on which receives the most bids. As long as the bidding remains competitive, everyone's contributions are crucial, tipping the balance in favour of their own preferred public good. I've written about this at http://wp.me/p2IaW7-6i

  9. It's also possible to write good free software that accepts funding. Look at SQLite for example, the code is public-domain but there's also an SQLite consortium, https://www.sqlite.org/consortium.html, which sponsors development. This is somewhat like the Red Hat pay-for-support business model, another variant of which is the Sleepycat license where you get the code under the GPL but can pay for a standard commercial license. All of these provide means of funding free software without the developers having to give up control of their code.

  10. I believe Google and Facebook are paying $100k ($50k each) annually, not a one-off donation. The argument about under-funding is absolutely valid though.

Comments are closed.