x You must enable Federated Login Before for this application.
Google App Engine Control Panel -> Administration -> Application Settings -> Authentication Options

A Code of Trust - StackGeek

A Code of Trust

Thu, 08 Aug 2013


After Lew Moorman recruited me to advise Rackspace, I wanted to better understand Rackspace's intent and how they envisioned the future of their industry was going to pan out over the coming years. On of my first questions to Lew was "Why did you Open Source OpenStack?". Lew replied, “We did it to ensure a robust ecosystem, drive long term innovation and to help commoditize the core operating system.”

I’ve been thinking about what he said since, and it appears everything Rackspace wants to achieve with its Open Source strategy is actually based on trust. All good ecosystems rely on trust, whether that’s the school you trust with your child's education, or the bank you trust with your cash or the technology bits you trust with your data. Without trust, no ecosystem remains stable. Trust also empowers positive change and innovation. People who want their ideas to have impact must entrust other people to amplify, execute and improve on what they’ve created. That’s why the most powerful innovators make ideas readily and equally available to markets, governments and society.

Trust is also a necessary requirement of any commodity. When you buy gold, pig iron, pork bellies or crude oil, you’ve got to trust that you’re getting what your contract says you’re going to get. You’ve got to trust that when you say “gold” and I say “gold” we’re talking about the same thing. No more, no less.

To that end, an Open Sourced OpenStack gives way to methods for trusting the underlying infrastructures that runs our code, stores our data and makes our technology startup innovation process successful. This trust in infrastructure comes about when you have access to and are able to understand all the hardware, software and services your company uses day to day. While there will be many of us who don't choose to look behind that curtain of transparency for all the components we use to build our business, there will be a few of us who can and will.

At no other moment in time has trust been at such a premium. Recent revelations show the NSA has its fingers in every aspect of technology in our lives, including our phones, our operating systems, our clouds, and even the processor chips in our computers. All of these current events serve to highlight how precarious and precious the establishment of trust has become in the communications and interactions occurring between all of us.

It's not a surprise most communications occurring today on the Internet take place via software APIs. These APIs are critical to establishing trust in the way we interact with each other.

APIs Define Interactions

APIs exist to provide programmers an easy way to 'wrap' a set of function calls which reside inside a larger set of separate files. You can imagine these function wrappers as envelopes with a label on the outside summarizing what is on the inside of the envelope. Inside each envelope are more envelopes with labels and/or letters, any of which you may choose to open and read, given you have the ability to open the envelopes and view the underlying code.

Let's take a look at a simple two file example of an API. The first file contains code that wraps a fictitious Open Source API called MiCloud:

# clusterbuster.py - a simple "API" for snakeoi.ly site
# import the multi-tenant infrastructure cloud library
import MiCloud

def build_cluster(num_servers):
  cluster = MiCloud.create_cluster("Bob")
  for x in range(num_servers):
    node = MiCloud.grab_available_node()
    instance = node.start_instance()
    ip = MiCloud.get_ip()
    print "instance %s started" % x
  print "cluster built"

The code here provides a simple loop to iterate over several MiCloud calls. Our programmer can now write a small amount of code in a second file to start ten servers:

import clusterbuster

# start the snakoi.ly cluster

This second code snippet embodies the essence of an API: It makes it easy to do powerful things with a few lines of code. It also enables the underlying code to change the way it does things 'under the hood' without our programmer having to know or do anything different.

There are a few crackpots who think API parity between OpenSource software and closed/proprietary services like AWS are important. Contrary to these individual's claims, API trust is actually a far more important topic for consideration.

APIs Define Levels of Trust

Let's consider a scenario where another programmer is using a similar 'cloudy' API as the one above, but isn't able to see the first file because a) the code is closed source and b) it's being hosted on a service provider's infrastructure. In this example, the first file (again, hidden from public view) has been modified slightly by a large corporation to include code which checks to see how much a customer paid the service provider last month and if it was below a certain amount, starts an instance for them on an older part of the cloud provider's infrastructure:

  user_value = customer.last_month_invoice_amount()
  if user_value > 50000 or random.random() > 0.5:
    node = MiCloud.grab_available_node()
    node = MiCloud.grab_available_node_on_crappy_old_greasy_servers()

This decidedly evil example could present itself in the real world via proprietary software libraries or Web APIs, both of which could run non-Open Sourced code and non-transparent infrastructure.

If you think you can assume to trust proprietary APIs and closed source code created by companies who's primary purpose is increasing revenue, think again. Bruce Schneier's post from 2007 revealed what might have been a possible backdoor in the algorithm used by Microsoft's CryptoAPI. Fast forward to today, Microsoft is now being accused of giving the NSA a backdoor to Outlook and Skype. They are claiming they had no choice.

We all want to trust companies to do the right thing with our data. We want to trust Microsoft writes completely secure code we can run and we want to trust Amazon gives us fair, safe and secure computing with the AWS APIs. However, there’s no basis for that trust until you can see into the source code they are running or fully understand how they build and run the services they provide. This is especially true when companies are being forced into compromising situations by certain governments.

SaaS Services Benefit from Implied Trust

When Raffy Marty and I founded Loggly, I quickly realized how important our user's log data could be. Shortly after launching Loggly, we received a request from a customer to delete their account and all the data they sent us. It turned out one of their developers left debug statements in production code, which ended up forwarding their Loggly account all of their user's unencrypted usernames and passwords! Whoops. We both recalled stories of similar requests by Splunk customers struggling with purging data from their installs - for credit card numbers! Double whoops.

Incidents like these serve to illustrate a broader point which I completely missed at the time, but Raffy was quick to point out: Our customer's customers had no idea they also needed to trust Loggly with their data. Our customers assumed they could trust Loggly to do the right thing with that data because they were doing business with us, regardless of our intent or coding abilities. Further, the implied trust chain also required all those people also trust Amazon, because Loggly used the EC2 APIs to start and run our instances.

The fact is, if I use a proprietary service provider because I don't want to run the services myself, then there really is no way to know for certain they will act responsibly with my data. I must implicitly trust them to do the right thing, in all cases. Unfortunately, you can't really trust a service built on closed technologies because you can't see inside the service. The combination of desired outcomes (easy infrastructure) and risk bias (implied trust) presents itself as a dangerous one because leads to cognitive dissonance - literally believing two things at once: I have to TRUST this service because I NEED this service.

I believe, in order to achieve real trust, we have to open everything. And by everything I mean EVERYTHING on the Internet in between my brain and yours. Working together to build that trust enables better outcomes for customers, ensures there’s a sustainable innovation ecosystem and makes technology progressively more accessible to a wider and wider community.

A trust based initiative is worth fighting for and one I’m focused on building in the coming years. I trust you will join me! :)