Blayne Sucks

Martin Fowler recently wrote something with which I found myself jarringly disagreeing. The post is about a concept called observed requirements.

Although I strongly disagree parts of his recent post, I did want to say upfront that I really like Martin Fowler’s work. Ever since I read Martin‘s book UML Distilled, I have been a fan. For something that is meant to simplify understanding, UML always appeared overly complicated to me and his book does a nice job of focusing on making it useful. Martin is also a big proponent of Agile Methods and Extreme Programming, both of which have improved software development practices by turning software development on its head.

Martin’s post starts with this quote from the book “Mastering the Requirements Process,” which I read last spring. (Note: I read the first edition of this book, which contains the quote Martin uses. I have not seen the second edition. Then again, I only have the second edition of UML Distilled. Such is the life of a grad student.) Here’s the questionable quote:

Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again.

Suzanne and James Robertson

When I first read this quote, I had pretty much the same initial, gut reaction that Martin had. It advocates an extreme position in a field where many different development methodologies have been successful. However, Martin’s post takes a position at the other extreme and is equally questionable.

Martin seems to think that the word “requirement” itself is a bad word, and that requirements are incompatible with agile methods. He claims that web sites developed using agile techniques violate the “waterfallish” requirements process and suggests four specific ways that such web sites can observe requirements throughout development:

• Look at what people are trying to do with the site and provide easier ways for them to do it.
• Look at where people are abandoning doing something, and look for ways to fix whatever was frustrating them.
• Build a new feature and see if people use it.
• Build an experimental feature and make it available to a subset of the user base. Not just can you see if they like it, you can also assess how much load it puts on your servers.

He goes on to say that web sites should monitor how their users actually use their site because what a user really does is much more accurate than what a user says they do. First, let’s get this out of the way. Suzanne and James Robertson dedicate a significant portion of their book (about half a chapter) to requirements elicitation through observing users! Let’s look at two more quotes from the first edition of their book.

First quote:

It is unlikely that many users can explain what they do in enough detail for the developer to completely understand the work, and thus capture all the requirements.

Second quote:

For example, one of our clients, [...], had 20 different products. [...] The way the users handled each of these products at first looked to be different. However, a common pattern emerged as we studied the structure of the work – we were looking for similarities, not differences. We observed that each product was in fact a different way of [...]. The end result was that we found a common set of requirements, and were able to make a single core implementation, and then dress it differently for each of the products.

I have edited the second quote to remove project-level details and focus on the “observed requirements” concept. Quite simply, I don’t understand how these quotes are irreconcilable with Martin’s four suggested approaches to observing requirements. In fact, they seem to be quite compatible. The jarringly disagreeable part of his post is that Martin paints requirements as a software artifact that can only be used in Waterfall development, which is completely untrue.

Second, let’s talk about requirements. Requirements can, and should, be a part of any agile method of development. They answer a critical question: “why?” In the case of an observed requirement, the answer is obvious: “Because that is, by definition, exactly what the user wants or needs!” In fact, requirements are even easier to integrate into the agile process than other software development processes. The regular meetings with customers provide a great opportunity for requirements-based techniques, but agile proponents typically eschew actually documenting any of the contextual information involved in these meetings in favor of self-documenting code and UML.

Self-documenting code has always seemed a bit silly to me. Just as an author can’t write to two audiences at once, a programmer can’t satisfy the compiler and provide complete documentation at the same time. Martin Fowler writes in UML Distilled (2nd Edition):

The fundamental reason to use the UML involves communication. I use the UML because it allows me to communicate certain concepts more clearly than the alternatives. Natural language is too imprecise and gets tangled when it comes to more complex concepts. Code is precise but too detailed. So I use the UML when I want a certain amount of precision but I don’t want to get lost in the details.

Many agile proponents like UML and in particular, use cases. Unfortunately, use cases, and other UML artifacts, typically don’t offer enough contextual information to answer “why” questions. (Though, they are excellent for answering “how” questions.) It is possible to augment use cases with contextual information. Later in UML Distilled, Martin says that developers should feel free to modify UML to meet their needs. Of course, once you have added the needed contextual information, you’re effectively just writing requirements.

Any agile proponent would find a lot of Suzanne and James Robertson’s book useful if they went into it with an open mind. Many of the techniques for discovering customer requirements could improve the efficiency of regular customer meetings in an agile development process. Conversely, many proponents of detailed requirements specs would find a lot of useful information in agile-based books like Martin Fowler’s Refactoring book and Kent Beck’s Extreme Programming Explained book.

Third, and finally, let’s talk about the current use of user interaction data as an “observed requirement.” The one thing in Martin’s post with which I completely agree is that observed requirements are extremely useful and haven’t been fully explored. As a privacy researcher, I think there are some unresolved issues for user data protection, but as a developer it is clear that this data can improve the product. The often cited example in this is Amazon.com’s book recommendation service, which I enjoy. For the moment, let’s set aside the privacy concerns because that could be a whole post in and of itself.

Martin mentioned at the end of his post that he hasn’t found much advice on leveraging customer website use for the express purpose of improving their systems. I don’t think the idea is being used as well as it could be, but it is out there. John Musa has been talking about Operational Profiles, which are effectively a set of observed requirements, for years as a way to improve software development. He’s even got his own book out there on the subject.

That’s the only work that I know that gives extensive, useful guidance on how to take user interactions with a software product and directly tie it back into the development process. I certainly don’t have all the answers here. If anyone knows another place where this concept has been studied, I would love to hear from you.

ABC News has an article on the eavesdropping of Americans that answers any remaining questions regarding the FISA Amendments passed this past summer. Essentially, the article details the use of surveillance systems to spy on ordinary Americans. Here’s a quote from the article:

“These were just really everyday, average, ordinary Americans who happened to be in the Middle East, in our area of intercept and happened to be making these phone calls on satellite phones,” said Adrienne Kinne, a 31-year old US Army Reserves Arab linguist assigned to a special military program at the NSA’s Back Hall at Fort Gordon from November 2001 to 2003.

Kinne described the contents of the calls as “personal, private things with Americans who are not in any way, shape or form associated with anything to do with terrorism.”

The article goes on to describe the nature of some of the phone call as pillow talk or phone sex. Some of the individuals involved were from the US Military, the International Red Cross, and Doctors Without Borders. Naturally, the Senate is investigating. The article further states that some especially juicy clips were saved by employees of the NSA.

Unfortunately, abuse of surveillance systems by insiders is nothing new. Bruce Schneier has shown us that surveillance cameras are abused and ineffective. Six well-known security and privacy researchers have warned about this sort of abuse with telephone surveillance as well (pdf).

The only thing that is remotely surprising about this is that we have specific details from whistleblowers, who are risking their careers and livelihood to tell us about this abuse. In this case, it is even more surprising that not one, but two independent whistleblowers came forward simply because the agency involved was the notoriously secretive NSA.

The GCHQ, which is the British equivalent of the NSA, recently dealt with its own whistleblower: Katherine Gun. In this case, Gun was a translator asked to favorably translate documents as evidence to garner support for the Iraq war. Her case was dropped at trial almost immediately. Speculatively, the decision to drop the case was due to the calculated decision that producing the evidence required to prosecute her would have been more embarrassing for the GCHQ than simply letting her go.

Many whistleblowers find the ethics of betraying their employer for the greater good an excruciating ethical dilemma. Check out this BBC News interview of Katherine Gun if you are interested in how she weighed the decision. (There’s a book about her if you are more ambitious.) For these reasons and many more, whistleblowers like Mark Klein in the AT&T case that prompted the FISA Amendments and now David Murfee Faulk and Adrienne Kinne in this more recent case with the NSA shouldn’t be our last line of defense.

Essentially, lesson from this ABC News article is simple: surveillance tools will be abused. It is human nature for power to corrupt. The Founding Fathers of the United States recognized this and tried to limit the power of the government explictly for this reason. They built checks and balances into our government because they knew that hoping for whistleblowers to highlight problems was not reliable. Why does the current US government not seem to comprehend this?  How many more whistleblowers and ABC News stories will it take for our government to catch on?

I recently was without my computer for some time and stumbled upon al3x’s Rules for Computing Happiness shortly after getting back online.  My time away from my computer gave me the opportunity to think about my own computer usage.  I thought I would go ahead and post my own short lists of rules.  For the sake of brevity, I will limit myself to five tips per category.

Obviously, the goal of using a computer is to improve your “happiness” through making work easier or making play more fun.  Although measuring happiness is hard, there is a clear divide between how computer power users (geeks) and the average person (non-geeks) uses a computer.

The first group has different objectives when they use their computer.  People in this group are more interested in hardware and software that gives them choice and control.  They are willing to put in the time to weigh their options and make the decision they feel is appropriate.

Geek Software:

1. When looking for a piece of software, always consider using an open source alternative.
2. Use software that stores data in open file formats.
3. Learn how to use a Unix-based operating system.  Good options include Mac OS X, Linux, or OpenSolaris.
4. If you travel, be sure to encrypt your data.  I almost put this into the Non-Geek category, but I think full disk encryption may still be a little bit out of the range of things that Non-Geeks are willing to learn how to use.  Either way, this is incredibly important if you travel and have any personal information on your laptop.
5. Don’t be afraid to use proprietary software when it is simply the best tool for the job.  I think potential examples of this are Photoshop and TextMate.  Both of these programs have good open source alternatives (Gimp and vim or Emacs respectively), but the bottom line is that you should use whatever makes you most productive.  Just don’t forget point #2 in this list.

Geek Hardware:

1. Buy hardware with open source software support. This hardware will almost invariably have good closed source support as well, but open source support will give you more options and more control if you want it.
2. Do not skimp on your monitor, keyboard, or mouse.  If you are going to be using your computer heavily, the quality of the interfaces you use is very important to your health.
3. If you use more than one computer, get a KVM.  It will save you a ton of space on your desk.
4. If you use a router, get a dd-wrt compatible router.  The feature set will blow you away.
5. Conduct extensive research on every piece of hardware you are considering buying.  Good places to start are the Ars Technica Buyer’s Guide or Tom’s Hardware.

The second group consists of a wide variety of people in all kinds of professions that want nothing more than to use it to complete some task or to have fun.  They explicitly do not care about learning how computers work.  My mother falls into this category.  Here are the rules that I would give anyone in this group to help them achieve computer happiness:

Non-Geek Software:

1. Think twice before installing any piece of software.  Could an already-installed application do what you need?
2. Find and use software that will help you back up your data.  Apple’s Time Machine is a good way to do this.  (See Non-Geek Hardware #4.)
3. Keep a written record of all the software you install/remove and the time you install/remove it.
4. Use a password manager that allows you to select stronger passwords.
5. Do not use web applications unless the things you use them for aren’t sensitive.

Non-Geek Hardware:

1. Do not buy top of the line hardware.
2. Do not buy ultra cheap hardware.
3. Hardware features are less important than the software support.
4. Buy an external hard drive and use it to back up your important data.
5. Avoid expensive hardware service plans.

Ordinary Men by Christopher R. Browning is a book on Nazi Germany’s Reserve Police Battalion 101, which participated in the Holocaust. The primary discussion in the book is on how a group of ordinary, middle-aged Germans became mass murderers. He attempts to understand how this transformation took place, and he uses insights from the Milgram experiments and the Stanford Prison experiments. However, he is quick to point out in the forward of the book that “explaining is not excusing; understanding is not forgiving.”

The book was recommended to me by Lucas Layman after a discussion on the importance of the human element in computer security led to a discussion on the Milgram experiments and the Stanford Prison experiments. Certainly there are many elements of computer security and computer crime that can be better understood through studying human psychology. For example, the simple fact that as the men of Reserve Police Battalion 101 were removed from direct participation (e.g. pulling the trigger themselves) to indirect participation (e.g. leading Jews to death trains) they were more easily able to cope with their actions psychologically. Similarly, computer crime is easily disassociated because of the impersonal nature of dealing with computers rather than humans. However, after reading the book my strongest reaction has been broader than just computer security.

When I was in high school I had to read quite a few books on the Holocaust. It seemed that every year we read a different book on the subject, and I tired quickly of the extremes that were pushed. Nazi Germany in general and Hitler in particular have become famous for being the most extreme extreme. This is perhaps best identified by Godwin’s Law.

Ordinary Men suffers from over-extremism to some extent as well. For example, Browning causally refers to the Holocaust as the “most extreme genocide in human history” without offering much in the way of proof or comparison. The number of Native Americans systematically killed by Europeans and the number of Russians killed by Stalin’s regime could each easily exceed the numbers of Jews killed by the Holocaust. The rate of killing in Rwanda could easily surpass the rate of killing in the Holocaust. The brutality of groups like the Khmer Rouge and leaders like Genghis Kahn could be argued to be greater than that found in the Holocaust. Is it even possible to classify something like the “most extreme genocide in history?”

My point is that our only reaction to events like these cannot be the emotional one; we must attempt to understand why and how these things happen so that we can learn from them. We aren’t good at rationalizing emotions, and we are rarely able to draw objective conclusions based on them. However, if we can take a look at some facts, then we may be able to learn important lessons. For example, before the brutality caused by Nazi Germany and in former Yugoslavia, we see extreme hyperinflation. Do we know anywhere else in the world where that is happening right now? I think so. This is something to be concerned about.

More generally security is a field that suffers from extremely emotional reactions. The air travel response to the September 11th attacks is a good example. How many of these responses have been the result of reason rather than emotion? How many of them have actually improved airport security? These are questions that we will probably continue to struggle with for years because of the highly charged emotional response most Americans have to the September 11th attacks.

On the whole though, Browning does a good job of ensuring that we don’t view the people of Reserve Police Battalion 101 as caricatures of themselves. As a result, there are many lessons to be learned from this book. The Holocaust should not be thought of as an abstract evil thing, but instead as a real consequence of human plans and actions. As Browning says, “Ultimately, the Holocaust took place because at the most basic level individual human beings killed other human beings in large numbers over an extended period of time.” The book offers an objective take on how ordinary people are capable of such a thing. I found it to be a very worthwhile read.

Yesterday the FCC released their report on their decision against Comcast’s secret degredation of BitTorrent protocol traffic. The basic content of this ruling has been known since early August. It nominally states that Comcast violated federal rules for “reasonable network management.” Network neutrality proponents have been quick to applaud the FCC’s ruling. Certainly, this action violates a hands-off, network neutral approach. However, the extremely important and surprisingly overlooked subtext is that supporting the FCC’s ruling implicitly accepts that the FCC should regulate the operation of ISPs, and effectively, the Internet itself. The end result of regulating the Internet is to seriously muffle the creativity and innovation that has made the Internet great.

Some commentators are avoiding the discussion of the FCC’s jurisdiction in this matter, but it is absolutely the most important aspect of this ruling. The FCC’s five commissioners voted to take action 3 votes to 2. Both Commissioner McDowell and Commissioner Tate have released separate dissenting statements intimating that the FCC shouldn’t be involved in this type of decision. Commissioner McDowell wrote an editorial in the Washington Post several weeks ago defending the incredible growth of the Internet as the result of “the principle that engineers, not politicians or bureaucrats, should solve engineering problems.”

In fact, Comcast and BitTorrent had already agreed to work out an amicable solution to these engineering problems way back in March. Of course, the folks at Freedom to Tinker are right that this isn’t really a two party discussion between Comcast and BitTorrent, but the point is that Comcast was working towards fixing these problems well before the FCC took a regulatory action.

ISPs have always had the ability to solve network problems as they happen without fearing a fine. Government regulation would hamper these efforts. Politicians are concerned about this chilling effect. Kevin Martin, who is the Republican-appointed Chairman of the FCC and who voted in favor of taking action against Comcast, faced significant political pressure prior to the release of the opinion. House Minority Leader John Boehner wrote a letter to Martin to express “dismay” that he was “intend[ing] to interfere with the network management decisions of broadband providers, essentially regulating the Internet.”

Supporters of the FCC’s actions, such as Brett Frischmann, may find the FCC’s use of the phrase “reasonable network management” to provide sufficient wiggle room for analyzing actions on a case-by-case basis, but the phrase “reasonable network management” is not as innocuous as it may seem. Sure, there’s a lot of ambiguity in the word ‘reasonable,’ but adopting this phrase as a de facto standard would destroy creativity and innovation. Here’s what George Bernard Shaw had to say about reasonableness:

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

This has certainly been true of the Internet, where virtually every major advance seems to have come as a complete shock to the vast majority of experts in the field. Paul Graham talks about this a lot. Most recently he mentioned it in the context of fundraising for startups:

A good startup idea has to be not just good but novel. And to be both good and novel, an idea probably has to seem bad to most people, or someone would already be doing it and it wouldn’t be novel.

Don’t lose sight of this bigger picture like the FCC has: Regulating network neutrality doesn’t work out well for anyone in the long run because creativity and innovation depend on the ability to be “unreasonable” at times.

I know many readers of this blog also follow ThePrivacyPlace.org, but I wanted to ensure that those who simply follow this one where aware that there is a research survey currently being conducted at ThePrivacyPlace.org. I encourage everyone to participate as this is an excellent way to contribute to academic research and our understanding of online privacy concerns.

Cross posted from ThePrivacyPlace.org:

ThePrivacyPlace.Org Privacy Survey is Underway!

Researchers at ThePrivacyPlace.Org are conducting an online survey about privacy policies and user values. The survey is supported by an NSF ITR grant (National Science Foundation Information Technology Research) and was first offered in 2002. We are offering the survey again in 2008 to reveal how user values have changed over the intervening years. The survey results will help organizations ensure their website privacy practices are aligned with current consumer values.

The URL is: http://theprivacyplace.org/currentsurvey

We need to attract several thousand respondents, and would be most appreciative if you would consider helping us get the word out about the survey, which takes about 5 to 10 minutes to complete. The results will be made available via our project website (http://www.theprivacyplace.org/).

Prizes include $100 Amazon.com gift certificates sponsored by Intel Co. and IBM gifts.

On behalf of the research staff at ThePrivacyPlace.Org, thank you!

I was going to wait until Dan Kaminsky announced more details about this flaw at the Black Hat Briefings on August 6th, but Halver Flake’s recent post as essentially squeezed the toothpaste out of the tube on this one. Just look at what Dan has to say.

I’m not going to talk about Dan’s decision not to release the details of this attack as soon as possible or the merits of full disclosure in computer security. Although interesting, it is less interesting to me than the flaw itself.

I know not everyone who reads this blog is technically oriented. To those people, I encourage you to try and make your way through this (long) post. I will try to keep things as simple as possible and I can guarantee you that a better understand of this particular problem will not only give you a better understanding of computer security, but also a better understanding of how the Internet really works.

Let me take a few moments to provide some background. The Domain Name System (DNS) is the protocol that translates a website’s domain name (e.g. somebank.com) into the corresponding IP Address (e.g. 192.168.1.1). IP Addresses are used by routers and network infrastructure to deliver information from one place to another on the Internet. DNS has been around since the mid 1980′s. It is a critical part of the infrastructure of the Internet. When you type in a domain name or use a bookmark to visit your bank’s website, you are trusting that the DNS protocol will take you to the correct server and not to a well-designed phishing website that looks just like your real bank.

The recent flaw in DNS is a protocol-level design flaw, not a software bug. A protocol is merely a pre-defined set of steps done to achieve some objective. For example, when Alice introduces two of her friends, Bob and Chris, to one another for the first time, she would follow a social protocol of introduction. She may introduce Bob to Chris as her co-worker from the Human Resources department, and she may follow this by immediately introducing Chris to Bob as her friend from church. If Alice forgot to introduce Bob to Chris and Bob eventually had to introduce himself to Chris while Alice was standing there, then that failure on Alice’s part is analogous to a failure in a single piece of software. If there were a flaw in this protocol, then every introduction performed based on this social protocol would fail. That is the difference between a protocol-level flaw and a software bug.

Now we have gotten to the crux of the issue. There is a protocol-level flaw in DNS that allows a phisher to take over the actual domain name of the site that it is trying to imitate. This is a serious problem that led to an astonishing collaboration to patch the entire Internet. Even patching the entire Internet isn’t going to “solve” this problem. Why? Because the patches are just that: patches. The problem still exists in the protocol.

What exactly is this problem? (And here’s where I may lose anyone who’s not technically oriented, but I’ll try and keep this simple.) When a DNS server doesn’t know how to translate a domain name into an IP address, it asks another, more trusted, DNS server for the information. Of course, this happens quite frequently since any given DNS server can’t store all the correct DNS translations for the entire Internet all the time (and since these translations can change).

Each time a DNS server has to ask a more trusted DNS server for a domain name to IP address translation, it does so by providing a number called a Query ID (QID). Now, there used to be a ton of attacks based on these QID since they were sequential. This class of attacks basically consisted of an evil doer asking a DNS server to perform a translation on a domain name that it didn’t already have. The evil doer would then start sending forged responses with sequentially increasing QIDs. If the evil doer got the right one, a bad domain name to IP address would be cached. Once a translation is cached, most DNS software implementations will ignore other updates to that domain’s information.

There are many ways to poison a DNS cache. This particular problem was patched (not solved) by just not using sequential QIDs. If a random QID is used, then it becomes very difficult for the evil doer to respond before the real response arrives.

Another interesting way to poison a DNS cache is to send a fake resource record. This attack works because of a chicken-ad-the-egg problem that I deftly avoided in my earlier description of DNS. I said that when a DNS server doesn’t know the proper translation for a domain name, it asks a more trusted DNS server. How? How does it know a more trusted DNS server? Basically, it only knows trusted DNS servers by their domain name. So it has to resolve a domain name for the next step in the hierarchy. Let me give a simple example.

Let’s say you’re a DNS server trying to resolve checking.somebank.com and you don’t know how. Who are you going to ask? Well, you’re going to ask whatever domain name server is controlling somebank.com since somebank.com is the next step in the hierarchy. If you don’t know that one, you’re going to ask the .com root server. Of course, you would like to learn how to ask somebank.com how to resolve all of it’s subdomains (e.g. checking.somebank.com, savings.somebank.com, etc…) since that would be efficient. This is done through a DNS Resource Record (RR).

Although there are many kinds of DNS Resource Records, for this attack all you need to know is that when you make a query for a DNS translation, you can receive back an answer as well as an additional resource record that is intended to help speed up future queries. Now, it used to be possible to poison DNS caches directly with this because there was a flaw in the protocol that allowed these resource records to be totally unrelated to the original request.

For example, let’s say you’re a DNS server and you just sent out a query about checking.somebank.com. It used to be possible that you would receive a domain name to IP address translation for checking.somebank.com and an addition resource record telling you that you should cache ns.evildoer.com as a name server for future queries. This was patched (not “solved”) by requiring the additional resource records be related to the query. (Thus, you would only be able to get a DNS RR for a somebank.com name server.)

The most recent DNS protocol-level flaw is related to both the QID problem and the DNS RR problem. Here’s how I believe it works (and these details are already available to anyone with access to google and a few minutes):

1. Get a DNS server to look up a subdomain for the site that you want to compromise. For example, randomAAAAAA.somebank.com. The subdomain itself doesn’t really matter other than it shouldn’t exist.
2. Since the DNS server doesn’t have this domain name to IP address translation it will have to look up the answer. Now, the evil doer can’t reliably predict the QID since random QIDs are used. The vast majority of these lookups will correctly be answered by ns.somebank.com as non-existent subdomains with the right QID. However, the evil doer can still try and race ns.somebank.com to guess an answer.
3. The evil doer repeats step 2 and increments the random domain name every time. For example, the next domain name the evil doer might try could be randomAAAAAB.somebank.com. Since QIDs are just randomized and not cryptographically secure, the attacker may still have a mathematically reasonable chance at eventually guessing correctly and beating the real name server’s response. If that happens, then the real name server’s response is dropped and more importantly the attacker has earned the right to send a DNS Resource Record updating the name server for the bank. (i.e. The attacker gets to poison ns.somebank.com and make it point to their phishing site.)

It’s clever. It’s not easy to solve, so we’re going to play the patching game again and people are rushing to patch their DNS servers. Now, this post is not going to talk about the losing battle that is penetrate-and-patch. Although it would be fun to rant, that debate is no longer interesting since all the smart people are on the same team.

So why is the flaw (and perhaps computer security on the whole) interesting? The assumptions involved. Professor Spafford has a great quote about computer security and assumptions:

Finding vulnerabilities is simple; discover the assumptions a developer made, ad then violate those assumptions.

People have become accustomed to DNS working. They assume it will work. It’s not just users, but also developers that do this. Let’s take one example: OpenID.

For those who don’t know, OpenID is an identity system that enables users to store their identity information in one place. Instead of having usernames, passwords, addresses, and other account information stored separately at amazon.com, ebay.com, flickr.com, etc…, users would be able to store it (and update it) all in one place. It’s a really neat idea that could eventually provide useful services and save real people time. However, it was designed with the assumption that DNS just worked.

Kim Cameron points this out on his blog, but I think the best summary of the problem is by Tim Anderson:

Note that Cameron is not opposed to OpenID. Apart from anything else, he recognizes that this may well be the beginning of an identity revolution – part of a process, at the end of which we get a safer, less spam laden, less criminal-infested internet.

At the same time, he’s right. The whole OpenID structure hinges on the URL routing to the correct machine on the Internet. In other words, DNS. Now do some research on DNS poisoning. Scary.

Now, it strikes me that you can largely fix this by requiring SSL connections. In other words, have the OpenID URL be an https:// URL, and have the relying party (the website where you want to log in) check for a valid SSL certificate. Note thought that SSL must be used at every stage. OpenID lets you use your own URL as the identifier, but redirect to another OpenID identity provider. Both URLs must use SSL to maintain integrity.

Scary indeed. The OpenID developers have assumed reliable DNS. Now, Tim’s probably right that encryption is the solution to this problem, but I don’t think SSL would work. Even if there is a certificate for the site, most browsers fail to properly inform users what it means when an SSL certificate has changed or isn’t there now. Plus, people are trained to use the domain name and trust that it works.

So how can encryption help? Well, I think DNSSEC and IPSEC (or IPv6) would actually solve (not patch) the problem, but designing better protocols hasn’t been the real issue. DNSSEC and IPSEC have been around for a while. The problem is adoption. No one uses these protocols just like no one uses PGP for encrypting their email.

Metcalfe’s Law is holding most people back since they don’t want to be the only ones using the “other” network. This is another great example of why “road” or “highway” analogies don’t work for the Internet. If this were a pothole or even a collapsed bridge, we could fix the problem properly without really affecting most people. However, since this is the Internet, we can’t actually solve this unless everyone agrees to stop using DNS.

So we’re going to continue to see problems with old infrastructure protocols like DNS. As a result, phishing will continue to be a serious problem. The only way this will stop is if there is a problem so big that the monetary incentive to avoid the problem pushes everyone to change. Who wants to guess how big of a problem that would have to be?

Yesterday Barack Obama was at Purdue University to talk about national security. You can read the text of his remarks here.

Purdue University may seem like a strange place to talk about National Security for many people, but this location was well-chosen for several reasons. First, Clinton won Indiana in the primaries and although the state tends to vote republican in November, Obama needs to continue to bring the democratic party together. Second, Sen. Evan Bayh (D-IN) supported Clinton in the primaries. He’s a very popular former governor of the state who’s father was also in the Senate. Being able to receive his support is important for Obama. Third, Sen. Richard Lugar (R-IN) is a foreign policy and national security expert. Although Sen. Lugar was not at the event, he was spoken of with high praise. Fourth, Purdue University is home of CERIAS, one of the best cyber security research institutions in the world. It makes sense to talk about national security in a state that has such an influential voice in that area.

As to the actual event itself, I strongly encourage you to read Professor Gene Spafford‘s write up of his experiences at the event. He gives an overview of Obama’s speech and each of the three panels that followed. It is an excellent read if you are interested in national security, politics or computer security. Although there are many quotable sections of the post, I will refrain from quoting it in the hopes that my strong endorsement of it will encourage you to read the whole thing.

CNN is running an article about a 22 year old woman who is facing a probable sentence of six years for identity fraud. There are a couple of things to note in this story.

First, their victims were friends and family. This is a common form of identity fraud. More than a third of all victims of identity fraud know the person who victimized them. Why? The answer is access. Friends and family are more trusting and their identity information is simply more easily available. It may even be easier for criminals to use since many vendors may be willing to look the other way for a daughter using her mother’s credit.

Second, the article quotes a federal prosecutor using the phrase “identity fraud” rather than identity theft. This is extremely important because it more accurately describes the crime. We already have laws on the books for fraud. Fraud has been illegal for quite some time. Yes, there are technological issues in catching the criminals, but the situation is far better than it was a few yeas ago.

Jim Harper describes the difference in detail in his book Identity Crisis:

Silence of the Lambs was a 1991 movie starring Jodie Foster as FBI Special Agent Clarice Starling and Anthony Hopkins as the notorious and devious supercriminal Hannibal Lecter. At the end of the movie, Lecter overpowers ad kills two guards in order to escape from a special prison that has been built for him on the upper floors of a building. He changes into the uniform of one of the guards, hides the guard’s body and poses as that guard, badly injured but clinging o life. To complete the deception, Lecter tears the guard’s face off and places it over his own. The police wheel Lecter out of his prison on a gurey, underneath that gruesome mask. This is identity theft. Lecter has taken a key identifier from the dead and mutilated guard, who will never get it back.

Obviously, simply using an identifier is far different than stealing one. It is nice to see that the federal prosecutors are using the correct terminology and that it is making its way into the mainstream press.

I have trouble describing how disappointed I am that this bill has passed. The roll call vote is available here. I have written about FISA previously here and here.

Although there are many aspects of this bill that disappoint me, I would like to take a moment to talk about the one closest to my research: legal compliance in technology systems. This bill sets an incredibly bad precedent for anyone advocating legal compliance. Essentially, what the telecommunications companies did was blatantly against the law. However, this bill retroactively provides them immunity for their actions [1]. When the consequences for violating the law are removed retroactively, companies have an incentive to violate the law in the future.

The ethics in situations like this are already difficult for engineers to recognize. For a technologist like Mark Klein, setting up a room with a whole bunch of cables going into it is a normal daily aspect of their job. Most will not see the ethical implications. Most engineers at that level are not aware of the bigger picture. They may not be able to say for sure whether their action is a violation of the law. To speak out about such a thing already takes great personal courage.

The last thing engineers need to see is a case like this. They will recognize that even if they do risk their job to speak out about a possible legal problem, and even if that possible problem is recognized as such, it is now, with the passage of this bill, clearly possible that Congress will bend over backwards to let their employer off the hook.

To understand how difficult it was before this amendment was passed for someone like Mark Klein to do what he did, I urge you to read the introduction Cindy Cohn gave him at the EFF Pioneer Awards. Congress has just made it harder on the heroes. This is a disappointing day.

[1] Yes, I realize that this bill doesn’t directly provide for retroactive immunity. However, the bill sets up a sham court proceeding to determine whether or not the companies involved were told it was ok to do what they did by the President, which is already widely known to be true.

[Update: There's an extremely well-written article on the FISA Ammedment Act on ThreatLevel.]