Blayne Sucks

Currently, Twitter is the Internet’s dominant micro-blogging service. It has shown that micro-blogging is a distinctly different form of communication deserving of it’s own niche, and it has done so well with its own micro-blogging service that micro-blogging itself is perhaps better known as Twittering.

Of course, there is one small problem. Twitter is a closed platform. As Tim Bray put it:

The basic problem is that Twitter is centralized; that’s not how the Internet works.

A quick look at history tells us that open communication protocols win in the long run. When you call someone on the phone, you aren’t limited to people using the same telephone service provider. When you email someone, you aren’t limited to people who are using the same Internet service provider. Even actual blogging has standardized norms (RSS and Atom) that allow people using blogger, WordPress, LiveJournal, or any other blogging mechanism to easily follow blogs on other platforms. (Though, cross-blog commenting is still a bit of a problem.)

Although I could talk about the Network Effect or Metcalfe’s Law, for the purposes of this post, I will focus on the key security design problem facing Twitter. This is not to say that the Network Effect and Metcalfe’s Law aren’t important. They are. I’m just talking about another, unrelated reason that supports the need for diversity in the micro-blogging industry.

A recent incident is an exemplar of the real problems caused by a centralized protocol like Twitter. An attacker was able to hijack several high-profile Twitter feeds, including Barack Obama’s campaign feed and the official Fox News feed. How did this happen? Well, it turns out that there was a security design flaw on the Twitter site that allowed rapid login attempts. This allowed an attacker to use a dictionary attack against the Twitter account of a member of Twitter’s support staff. Once the password was guessed, the attacker was able to get access to any feed in all of Twitter-dom.

The key security flaw in any centralized protocol is that such protocols are monocultures. Bananas are a great example of the danger of monocultures. Bananas are an extremely important crop worldwide, but the vast majority of bananas grown are of the Cavendish variety. Why? Because the tastier Gros Michel bananas were wiped out by a disease. They were all essentially genetically identical. There was almost no diversity in the banana ecosystem. As a result, they were unable to adapt to the disease, and since the same problem exists with the Cavendish, we’re still one bad disease away from a worldwide shortage of bananas.

The same problem exists for micro-blogging. If you want to micro-blog, you effectively need a Twitter account. Twitter is so dominant that almost all micro-bloggers are using Twitter, which makes it a monoculture. Because Twitter is a monoculture for micro-blogging, the micro-blogging itself is one bad security incident away from obliteration. Also, if Twitter were to go belly up (which is not, as Tim Bray discussed, outside the realm of possibility for an Internet-based company), then, effectively, the entire micro-blogging industry would be eliminated.

At this point you might say, “Wait! Twitter has an open API!” This is not the same as open source, and it does not eliminate the threats posed by monocultures. It does mean that it is very easy to add functionality to the Twitter protocol, but it does not mean that you can participate freely without a Twitter account.

Micro-blogging needs a viable open source alternative to create a federated micro-blogging protocol. Tim Bray proffered Laconica and one of the commenters in his thread mentioned the soon-to-be open source Jaiku, which was recently shutdown by Google.

Whatever happens, a federated micro-blogging protocol would be far more robust than the current Twitter monoculture. If I were to add a single gutsy prediction to the list over at Freedom to Tinker, it would be that a major security incident at Twitter allows an open source alternative to gain a foothold in micro-blogging. It may not happen this year, but I think it’s inevitable with any monoculture.

Last month, Jim Harper started an interesting discussion on regulation around the holidays. Although I was hiding from my computer in an attempt to take a vacation at the time I have finally caught up with the discussion. If you happen to have missed this as well, I think it’s well worth reading.

Jim started the discussion with an excellent blog post over on Cato@Liberty about ‘real’ regulation. If you haven’t read it, here’s a juicy tidbit:

What Burnett meant when she called for a “real” regulator, of course, was “the regulator I can imagine.” The regulators people imagine are foresighted, interested only in the public good, they’re resistant to lobbying, and they run efficient organizations. But these characteristics are simply imaginary.

Tim Lee followed this up with a post on the Technology Liberation Front extending the discussion to regulation of technology. Again, if you haven’t read it, here’s a juicy tidbit:

Too many advocates of regulation seem to have never considered the possibility that the FCC bureaucrats in charge of making these decisions at any point in time might be lazy, incompetent, technically confused, or biased in favor of industry incumbents. That’s often what “real regulators” are like, and it’s important that when policy makers are crafting regulatory scheme, they assume that some of the people administering the law will have these kinds of flaws, rather than imagining that the rules they right will be applied by infallible philosopher-kings.

The FCC is designed to ensure (theoretically) that these bureaucrats are independent, but if you take a look at what is actually happening, then it becomes clear that independence is in many ways imaginary. The FCC’s website describes the organization of the Commissioners as follows:

The FCC is directed by five Commissioners appointed by the President and confirmed by the Senate for 5-year terms, except when filling an unexpired term. The President designates one of the Commissioners to serve as Chairperson. Only three Commissioners may be members of the same political party. None of them can have a financial interest in any Commission-related business.

News today that FCC Chairman Kevin Martin will resign on Inauguration Day makes the FCC an even more interesting topic for discussion. With this resignation, Obama will have nominated all five of the serving FCC Commissioners by this summer. Also, it goes without saying that the FCC will be regulating some important aspects of our society, including the Digital TV transition that’s slated for February.

Obama’s choice for FCC Chairman is Julius Genachowski. Wikipedia describes him as “an American business executive with experience in telecommunication and technology issues.” This ideal of not having a financial interest in Commission-related business isn’t starting off well. Of course, that’s Wikipedia, so maybe it’s not trustworthy. Let’s look at Reuters’ description:

Genachowski was chief counsel for Reed Hundt, an FCC chairman under former President Bill Clinton. He also held various positions at Internet search and media company IAC/InterActiveCorp (IACI.O) and several firms investing in technology, including Rock Creek Ventures and LaunchBox Digital.

Again, it sorta feels like this is a man with financial interests in technology. Business Week even lauds his “business sense” as a key benefit that he brings to the table. But let’s take a step back from this individual appointment. I really don’t know much about Genachowski other than what’s been reported in the news, and I certainly don’t want to pick on him as an individual that’s emblematic of the larger problem with “real” regulation.

My point is simply to consider this: Is it really possible to find anyone who has the knowledge needed to help run a regulatory organization like the FCC that doesn’t have a financial interest in Commission-related business? If it isn’t outright provably impossible, then at the very least I think there’s a strong argument to be made that it is impossible. Sure we may wish that it weren’t so, but if wishes were fishes, we’d all be casting our nets. Of course, I’m open to your thoughts in the comments.

Malcom Gladwell’s recent New Yorker article compares “the quarterback problem” to the challenge of finding a good teacher. It’s an interesting article, but it is, perhaps, too narrow in its focus.

For those who don’t know, the quarterback problem is defined as the extremely difficult task of selecting a quarterback to play in the NFL from the pool of college football quarterbacks. It’s deceptively challenging to do this because there’s so much data available and so many ways to rank college football quarterbacks. However, the college football game is so different from the NFL game that success at the college level seems to have very little correlation, or perhaps no correlation, to success at the professional level.

One of the best examples of this is the comparison of Peyton Manning and Ryan Leaf, who were both extremely successful college quarterbacks drafted first and second in the 1998 NFL draft. Most experts thought it was a toss-up as to which of these two would have a better career. Of course, it’s clear to everyone now that Peyton Manning is a lock for the Hall of Fame while Ryan Leaf is famous for being a complete bust in the NFL.

The key element of the quarterback problem is that past results simply aren’t useful in predicting future success. Gladwell argues that this is also true of selecting good teachers. He claims that the usual metrics used to measure hiring and promotions for teachers, such as master’s degrees, teaching certifications, and other cognitive standards, are just as useless in attempting to determine a good teacher as college football statistics are in trying to determine a successful NFL quarterback.

Another important element of the quarterback problem is that the difference between ‘good’ and ‘bad’ is extremely large, potentially several orders of magnitude. There are very few ‘good’ quarterbacks in the NFL. There aren’t even very many quarterbacks decent enough to serve as an emergency backup. The quarterback position in the NFL may be the single toughest position to play in all of professional sports. Gladwell argues that the same is true of teachers:

Suppose that Mrs. Brown and Mr. Smith both teach a classroom of third graders who score at the fiftieth percentile on math and reading tests on the first day of school, in September. When the students are retested, in June, Mrs. Brown’s class scores at the seventieth percentile, while Mr. Smith’s students have fallen to the fortieth percentile. That change in the students’ rankings, value-added theory says, is a meaningful indicator of how much more effective Mrs. Brown is as a teacher than Mr. Smith.

It’s only a crude measure, of course. A teacher is not solely responsible for how much is learned in a classroom, and not everything of value that a teacher imparts to his or her students can be captured on a standardized test. Nonetheless, if you follow Brown and Smith for three or four years, their effect on their students’ test scores starts to become predictable: with enough data, it is possible to identify who the very good teachers are and who the very poor teachers are. What’s more—and this is the finding that has galvanized the educational world—the difference between good teachers and poor teachers turns out to be vast.

It follows that if you want a school system filled with good teachers, then you have to be willing to identify the poor teachers and get rid of them. This is the only solution to the quarterback problem. It’s a brutal process for both the teachers and the administration. Time Magazine recently had a cover story on Michelle Rhee’s unusual approach to improving schools in the nation’s capital, which is attempting to implement this brutal process.

Rhee wants to solve the quarterback problem the only way possible: by mitigating its effects. Simply put, if you can’t identify good teachers without seeing how they perform in the classroom, then you have to hire a bunch of teachers, watch their classroom performance, identify those that are succeeding, and reward them. Similarly, you have to identify teachers that are failing and eliminate them. Time’s article does a good job explaining why doing these two things is extraordinarily complicated in the teaching industry.

Of course, this is exactly how they solve the quarterback problem in the NFL. On-field performance is everything. Many of the best quarterbacks were identified as such by their play in real NFL games as backups for injured quarterbacks. Matt Cassel is a great example. In college, he never started a game and served as a backup for Carson Palmer and Matt Leinart. He was drafted into the NFL and played as a backup for Tom Brady, who suffered a season-ending injury in the first game of the 2008 season. Brady’s injury made Matt Cassel a starting quarterback for the first time since high school, which would undoubtedly determine his future in the NFL. If he played well, he would likely be rewarded with a starting role for another team during the off season. If he played poorly, he would fall into the nameless abyss of all the other failed NFL quarterbacks.

After reading Gladwell’s article, I had to wonder, how many other professions are like that? Surely the quarterback problem isn’t just limited to teachers and NFL quarterbacks. The first thing that came to my mind was a Paul Graham essay about great programmers, which is really a must-read for anyone in the software industry. In it, Graham talks about the nature of great programmers, and summarizes the problem of identifying them by saying, “The problem is, if you’re not a hacker, you can’t tell who the good hackers are.” Fred Brooks also talks about the vast difference between a great programmer and an average programmer in The Mytical Man-Month. Here’s Fred Brooks on great software designers:

The differences are not minor – it is rather like Salieri and Mozart. Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.

Clearly, selecting a software engineers fits the definition of the quarterback problem. It would be very interesting to study how the extreme challenge of creating a start-up company performs as a system for identifying great programmers.

Apparently, some people believe there’s a quarterback problem in selecting good lawyers. Although, I have no particular experience with this, I think the environment in which lawyers at big law firms operate is strikingly similar to the ideal solution to the quarterback problem. There’s an incredibly small percentages of lawyers who end up making partner at a big law firm, which indicates to me that there’s a quarterback problem in trying to hire a big law firm partner.

I’ve also seen the suggestion that selecting a mate is a version of the quarterback problem, but I personally think that’s taking things too far. I don’t think that people really have an objective idea of what a good mate is, let alone what metrics to use in measuring potential mates. Furthermore, the role of being a “mate” really isn’t the same thing as having a job.

I believe the quarterback problem is potentially much more prevalent than people currently recognize. I also think that the solution to the quarterback problem is clearly defined. The two important lessons to learn and apply from the quarterback problem:

• Don’t be afraid to give people a chance. They might surprise you.
• Don’t be afraid to make a change when things aren’t working out.

These two steps are the best known solution to the quarterback problem. What other fields could benefit from implementing them? If you have any suggestions for other areas where this problem seems to occur, please mention them in the comments.

As a technologist with a strong interest in computer security, privacy, and public policy, I am naturally drawn to the topic of electronic voting. I have written about electronic voting several times before, including this piece on Ed Felten’s work. Recently, I have seen lists of things things could have gone wrong and some lists of things that actually did go wrong. I have even seen a hilarious account of the worst case scenario, but the most interesting accounts that I’ve seen have been personal accounts of computer science professors who volunteered to operate the polls as election workers.

Avi Rubin, a Professor of Computer Science at Johns Hopkins and director of the ACCURATE Voting center, wrote a post describing his experience working the polls and posted it only minutes before most news outlets announced that Barack Obama will be the 44th President of the United States. Professor Rubin is the author of the book Brave New Ballot, an excellent book on the dangers of electronic voting machines that I have reviewed here. His experience at the polls in Maryland describes the very practical and non-technical aspects of just what a poll worker does during the day.

Steven Bellovin, a Professor of Computer Science at Columbia, also wrote about his experience as an election official. Professor Bellovin is another well-respected authority on computer security whose post focuses on the non-technical details of the responsibilities of poll workers in New Jersey. Andrew Appel, a Professor of Computer Science at Princeton, also wrote about the use of voting machines in New Jersey.

Both New Jersey and Maryland used Direct-record electronic voting machines, which have a myriad of security concerns that have been detailed extensively elsewhere. Essentially, DREs store the official record of an election in an electronic form rather than a paper form. If you are interested in some of the problems with DREs and proposed solutions to those problems, then you should check out the USACM’s page on electronic voting.

You may be asking yourself: Why would a computer science professor volunteer to work a poll as an election official? It’s not like there’s anything technical going on there. Well, any computer security expert will tell you that the first line of defense must be physical access. This means that you can have all technology you want, all the cryptography you want, and spend all the money you have and still not be secure without common sense. There was a great video on No-Tech Hacking at DefCon in 2007 which covers what I’m talking about.

Physical access is one of the key problems with DREs: thousands of people must have physical access to the machines themselves to cast their vote. The environment is filled with opportunities for absolutely simple no-tech hacking. Even if these systems weren’t notoriously bad in terms of the technology used, the physical access alone makes these devices difficult to secure.

The challenges of physical access and the stakes of a Presidential election are both great reasons that computer science professors are interested. It’s a unique opportunity to see how these machines are actually used, and some of their observations are excellent. Their posts are worth reading if you’re interested in electronic voting or computer security: Avi Rubin’s post; Steven Bellovin’s post.

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!