Thanks to insightful feedback from John Light, I realized it would be good to do a regular Turtle Status Letter in order to keep our followers and supporters abreast of our activities and decision-making process. We now plan to do one every year.

Inside This Year’s Letter:

How We Started

Our stated mission is fairly broad and focuses on supporting beneficial decentralization technologies.

However, it is odd that nowhere in our work is it explained how that became our focus. It started with a seemingly unrelated question: how can we fix email?

It turns out that solving the problem of secure asynchronous communication is so difficult that to this day no one has really come close to solving it. There are three primary reasons this is so:

  1. Email is built upon multiple fundamentally insecure, fundamental systems. By "fundamentally insecure" I mean there is no way to "patch" these systems to make them secure (they must be tossed out and replaced by something else), and by "fundamental systems" I refer to the fact that they power today's Internet and everything kinda depends on them.
  2. Most "solutions" are centralized and are insecure in some way. So-called "secure email solutions" today are not really secure because of their centralized nature and because they rely on the insecure systems mentioned in (1). Their centralization also fundamentally limits their adoption.
  3. The goal posts keep moving. By this I mean our understanding of what is required for communications to be "secure" keeps changing. It wasn't too long ago that people felt simply encrypting a message was sufficient to consider it "secure". However, that was before the director of the CIA said, "We kill people based on metadata", and people began to realize the implications of GPG's design, and the news that you could be killed by a drone because a buggy computer algorithm (called SKYNET!) on the other side of the world, suddenly—and incorrectly—decided to label you a terrorist.

Source: https://www.youtube.com/watch?v=8QG-9wR_KxA

Our journey turns out to be not unlike that of a turtle slowly making its way out to the sea, avoiding obstacles as it goes.

With every forward step, we learn more about the nature of the problem and what it will take to solve it. Most importantly, we learn what it will not take to solve it.

The okTurtles Browser Extension

Our original vision for "fixing email" was to secure online communication over any website in a user-friendly fashion—starting with a browser extension that did this:

Screen Shot 2016-02-21 at 8.57.39 PM

However, as we explored the problem in greater detail, we began to realize the full scope and magnitude of the problem, and how fixing it would require working at a lower level.

We knew it required changing how HTTPS works, and that meant the browser extension would have to be able to securely communicate with a blockchain. So we focused on finishing DNSChain. However, having now done so, a variety of significant challenges still remain:

  • Firefox makes it extremely difficult to verify HTTPS connections using any alternative system. The only existing code that manages to pull this off is Moxie's Convergence (most likely incompatible with the Firefox at this point), and that code is a nightmarish, unmaintainable mess (not entirely Moxie's fault).
  • Mozilla is not a good steward of Firefox's extension APIs. They make frequent breaking changes, and this uncertainty means that our work could end up being undermined (wasted) at any point in time.
  • There are significant security-related challenges in designing a UI that looks like the screenshot above. We have to defend against "fake UI overlay attacks" (i.e. Facebook inserting a text field on top of ours in order to capture the plain-text communication), but doing so involves compromising the simplicity of the extension's user interface, and that is not OK.
  • DNSChain is not a complete solution on its own. Most users cannot be expected to run their own DNSChain server, and would be unlikely to know a friend (or even acquaintance) who did. Thus, most users would have to trust a DNSChain server that's maintained by someone they did not know. We'll discuss the steps that we took to address this problem in the next section.
  • Even if we managed to succeed with all of the above, encrypted communication over centralized networks like Facebook and Gmail still reveals who is communicating, and it still allows those companies to completely block or delete that communication, potentially ruining the user's experience.
It's become clear to us that while the browser extension may be a useful hack, ultimately it will require a lot more to establish a real long-term solution to the problem of "secure communication everywhere." Solving this problem will take time, but that's OK because we are turtles, and turtles are thoughtful creatures who look at their options, avoid the paths that lead to failure, and then continue moving steadily forward. Our exploration of this path has already payed off in various ways, and it has helped many folks besides us to move forward as well.

DNSChain

One of our goals is to help move the world, in whatever useful way we can, to "secure communication everywhere." DNSChain has helped quite significantly on that front: DNSChain has taught many people about the problems and solutions associated with public key management, and in turn it's taught us many lessons as well.

One of those lessons is about the realities of server-side software, and how challenging it is for some protocols to scale. Recall, as mentioned above, that most users would have to trust a DNSChain server that’s maintained by someone they did not know simply because of how difficult (and resource intensive) it is to run a blockchain full node.

Since our goal requires us to minimize the amount of trust that has to be placed in any third party, we explored various solutions to this problem, starting with the development of a new thin client protocol called Proof-of-Transition. As our understanding of decentralized protocols became more advanced, we realized that the next step the Internet would need to take to realize “secure communication everywhere” would be the development of a generic, technique-agnostic protocol for securely querying arbitrary blockchains.

This understanding led to our participation in the Rebooting the Web Of Trust design shop, organized by one of the co-authors of the SSL/TLS protocol, Christopher Allen. Working alongside many wonderfully brilliant folks, we helped produce a whitepaper for a Decentralized Public Key Infrastructure (DPKI) for the Internet.

DPKI — Decentralized Public Key Infrastructure

Our work on the browser extension and DNSChain has now led to a description for a Decentralized Public Key Infrastructure (DPKI) for the Internet:

Abstract

Today’s Internet places control of online identities into the hands of third-parties. Email addresses, usernames, and website domains are borrowed or "rented" through DNS, X.509, and social networks. This results in severe usability and security challenges Internet-wide. This paper describes a possible alternate approach called decentralized public key infrastructure (DPKI), which returns control of online identities to the entities they belong to. By doing so, DPKI addresses many usability and security challenges that plague traditional public key infrastructure (PKI). DPKI has advantages at each stage of the PKI life cycle. It makes permissionless bootstrapping of online identities possible and provides for the simple creation of stronger SSL certificates. In usage, it can help “Johnny” to finally encrypt thanks to its relegation of public key management to secure decentralized datastores. Finally, it includes mechanisms to recover lost or compromised identifiers.

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf


This paper is the result of work from various attendees to the design shop. The full list of contributors (sorted by last name):

  • Christopher Allen, Arthur Brock, Vitalik Buterin, Jon Callas, Duke Dorje, Christian Lundkvist, Pavel Kravchenko, Jude Nelson, Drummond Reed, Markus Sabadello, Greg Slepak, Noah Thorp, and Harlan T Wood
We will be writing more about DPKI in the following months, and we invite you to read the paper and share your thoughts!

Voluntary Basic Income: Group Currency & Group Income

If DPKI addresses information security through decentralization, then VBI (voluntary basic income) addresses financial security through decentralization. Our work on Group Currency and Group Income, incidentally, also makes heavy use of blockchain technology. The relationship between decentralization and basic income is the subject of a soon-to-be-published future post, so stay tuned for that!

Educational Content

We published a lot of educational and informational content, and some of our favorites include: For more please see our blog and our YouTube channel. Lots more in the works!

Future: What's Next for the Turtles?

As we make our turtle crawl toward a more decentralized future, we will be focusing on three things:
  • DPKI
  • Group Income (see our recent post on that)
  • Our first crowd fund to help us achieve these goals (lots of progress has been made on this behind-the-scenes)
That's it! Thank you for reading this far, I hope you've enjoyed our first turtle status letter! 😀

Donating = Loving!
You can empower our work by donating!

Comments