Who Do You Trust, Part 1

I’ve mentioned in the “About …” page that I have a particular interest in open-source software development.  I’d like to talk a bit about why I do, and it seems to me that a logical place to start is with a discussion of the notion of trust.

Those of you who have been using the Internet for any length of time have undoubtedly heard the question of trust invoked.  For example, it has been standard advice for many years that users should not open any E-mail attachments if they are not “from someone you trust”.   Or you may have been told only to download material from Web sites that you trust.  But what does that really mean?

One kind of trust is exemplified by my strong belief that my best friend won’t steal my wallet, or that my banker won’t abscond with the contents of my account.  (At the moment, he’d be lucky to get to Baltimore on it, but that’s a different problem.)   I think the understanding of this kind of trust is pretty deeply embedded in the typical person’s mental apparatus; it is, after all, something that always would have been evolutionarily useful for social animals such as ourselves.

So, if I trust someone in this sense, I feel confident that he will not intentionally send me a malicious E-mail attachment, for example.  That is straightforward; most of us would find it possible to identify the correspondents we trust, in this sense.  The only drawback is that this has very little to do with the real problem: people who we trust not to try to harm us may nonetheless send us something malicious, because of lack of knowledge or skill, or just carelessness.  So really the trust we are talking about is not just trust in the sense of relying on someone’s honesty and good intentions, but also on their capacity to do the right thing.

Unfortunately, experience suggests that evaluating trust in this sense is a much more difficult thing.  We live in a world of increasing complexity and specialization; even if we are experts in one area, we can’t possibly know about everything that might matter.  When it comes to software, more and more parts of our daily lives are directly impacted by the quality (or lack thereof) of the software we use, not just in obvious things like Web browsers or office applications, but in control systems for our cars, appliances, medical equipment, and voting machines, to name just a few.  How this need for trust affects the way I think about software development is the subject of the follow-ups to this post.

Searching for Google

Earlier today, starting around 10:45 EDT, some people, especially in the Eastern US, found that they could not access Google sites and services, including Google mail.  The incident lasted for about 1.5 hours, although the duration and severity of the problem varied by location.  According to a post on the official Google blog, an unspecified routing error within Google’s systems caused the problem:

An error in one of our systems caused us to direct some of our web traffic through Asia, which created a traffic jam.

This is plausible.  Trans-Pacific cable capacity is much more limited than trans-Atlantic capacity, and there are fewer alternative paths.  Dropping in a huge slug of additional traffic would be quite likely to gum up the works.  (There are backup links via satellite, but since satellites in geostationary orbits are 22,000+ miles away, the latency difference matters.)

The SANS Internet Storm Center also has a diary entry about the outage.  (Right at the moment, SANS seems to be having some problems, but this link was correct as of ~20 minutes ago.)

Update 23:00 Thursday 5/14

The SANS links seem to be working now.   There is also a very interesting, somewhat tongue-in-cheek blog post from Arbor Networks, showing the impact of the Google problem on Internet traffic.