Published Mar 10, 2005

If you applied to b-school, you probably had the fairly mediocre experience of using ApplyYourself, a service that allows you to apply, and track the status of your applications, in the most inefficient way possible. This year, some smart boys figured out how to get their admit decisions weeks early by exploiting a security hole in ApplyYourself. Harvard has decided to reject everyone it thinks took advantage of this hole. I’m not sure that’s right; there’s more nuance here than meets the eye.

The process of the exploit, as described, is pretty simple: just change the address of the page you’re looking at slightly and you get the supposedly-secret admit decision. Somebody figured out this exploit and posted the process to forums on the BusinessWeek site, and a number (over 100?) of applicants supposedly used the exploit to check their decisions. There’s really several sets of people invloved in this process, each of whom needs to be considered seperately:

  1. The individual who initially discovered the exploit
  2. The applicants who took advantage of the exploit
  3. ApplyYourself, which had security holes

#1: The Discoverer of the Exploit

One distinction between “black hat” hackers and benevolent, security-focused “white hat” hackers is, to vastly oversimplify things, that the “white hat” hacker will often inform the vendor of an application, or ASP of a Web site, of an exploit before describing the exploit in public. I can understand “fooling around” and finding a hole in a Web site, but, ethically, the first thing that the intial discoverer should have done was to inform ApplyYourself. If the ASP had no positive response, the hacker should have informed the business school. Only then should the exploit have been released into the wild. The initial discoverer committed, by any measure, an ethical breach, and his or her admittance should be retracted.

#3: ApplyYourself

I’m dealing with this stakeholder second, because the technical issues are of great interest here, and this is the best forum in which to discuss these issues.

As is pointed out elsewhere, the exploit is, itself, pretty trivial. It’s also potentially the sign of worse things. You see, there’s really three kinds of bugs:

  1. There’s the kind of bugs you get when the program behaves, but not as desired. A trivial example of this is a Web page that’s supposed to have a red background; if a colorblind programmer gives the page a green background, well, that’s a functioning page that isn’t, however, functioning as specified. That’s a bug.
  2. There’s the kind of bugs you get when the programmer makes a typo. Then things go boom.
  3. Then there’s the architectural flaw — that’s when the people who wrote the program didn’t think through how the program would work. This is a dangerous kind of bug to find, because one example of bad architecture is often a sign of others, because the base cause of this bug is bad planning, lazy thinking, or a slapdash approach (or, sometimes, insufficient budget).

The ApplyYourself bug is pretty clearly an example of bug type 3. The security in this system just hasn’t been thought out completely enough and implemented in a systematic and granular enough way. Were I an admissions officer, I would expect ApplyYourself to commission an independent external security audit, and release substantial updates for next year.

The corrolary of this is that I would not trust ApplyYourself’s information on who had and hadn’t seen the admissions information, at least until I saw the outcome of that security audit. And this point is important to our next constituency:

#2: The Students Who Took Advantage of the Exploit

Can we really know who looked at whose admit decisions at this point? It’s irresponsible to simply reject anybody who you haven’t positively identified as having viewed their admit decision. A good approach might be to approach people suspected of having used the exploit, but whose illicit access to the system cannot be proved, and give them the opportunity to retract their applications, with no ill effects.

Even assuming we can be 100% sure who used the exploit, retracting admission may still not be the best decision. There’s little to say for the non-technically-oriented individual who read about the exploit and, out of pure impatience, eagerness, or whatever, used the exploit. Well, it’s pretty obvious that, if the admit decision hasn’t been made available to you, it’s not supposed to be available to you. Business involves making judgement calls, and b-school students need to show good judgement. Using this exploit this is most likely not an example of good judgement. This constituency should have the sin of bad judgement added to their files, and their admission reconsidered with this negative information included. It would probably also be best to briefly interview these appicants to learn more about their judgement and character. It’s been said that nobody was ever fired for blogging, that people fired for their blogs were fired for showing bad judgement. Let’s not reject applicants for fooling with URLs, let’s, instead, reject them for showing bad judgement.

But there’s a part of this constituency that might have a good excuse for their behavior. This subgroup contains software engineers and Web developers. For people in this subgroup, it’s usual to tinker with Web sites and applications that you use; it’s just like a carpenter looking at the joins on a table to see how it was made. Nobody would ever say, sorry, you’re a carpenter, you can’t do that. Fooling with other programs is a learning technique for programmers. It’s also a big part of security: trained people find holes in programs all the time, file proper bug reports, and get the problem fixed, making the world better for everyone. It’s unreasonable to expect someone who has hacked away at software for years to suddenly stop, especially when that hacking behavior was previously considered positive and ethical. The sin of bad judgement doesn’t stick here, although there could be questions of why experienced software developers didn’t attempt to contact ApplyYourself or their business school of choice with news of the exploit.

So, an apparently simple situation is more complicated in the end. There’s no obvious answer, apart from a security audit at ApplyYourself and a rewrite of some of their code. Ed Felten suggests that people shouldn’t be punished for doing things they might not have known were wrong; hopefully, future b-school applicants will learn from this exploit and consider their best judgement when they find themselves in postion in which they can gain access to otherwise-restricted information. Equally hopefully, business schools admissions staff will be understanding, reasonable, and consistent in considering the many new and innovative ways in which the Internet will allow b-school applicants to show bad judgement.