If the good that men do is oft interred with their bones, so be it, but in the meantime I feel a responsibility to correct some of the erroneous information being posted as comments to otherwise informative discussions at Reddit, Hacker News and Boing Boing. Apparently some people feel the need to self-aggrandize by opining on the guilt of the recently departed, and I wanted to take this chance to speak on behalf of a man who can no longer defend himself. I had hoped to ask Aaron to discuss these issues on the Defcon stage once he was acquitted, but now that he has passed it is important that his memory not be besmirched by the ignorant and uninformed. I have confirmed with Aaron’s attorneys that I am free to discuss these issues now that the criminal case is moot.

I was the expert witness on Aaron’s side of US vs Swartz, engaged by his attorneys last year to help prepare a defense for his April trial. Until Keker Van Nest called iSEC Partners I had very little knowledge of Aaron’s plight, and although we have spoken at or attended many of the same events we had never once met.

Should you doubt my neutrality, let me establish my bona fides. I have led the investigation of dozens of computer crimes, from Latvian hackers blackmailing a stock brokerage to Chinese government-backed attacks against dozens of American enterprises. I have investigated small insider violations of corporate policy to the theft of hundreds of thousands of dollars, and have responded to break-ins at social networks, e-tailers and large banks. While we are no stranger to pro bono work, having served as experts on EFF vs Sony BMG and Sony vs Hotz, our reports have also been used in the prosecution of at least a half dozen attackers.  In short, I am no long-haired-hippy-anarchist who believes that anything goes on the Internet. I am much closer to the stereotypical capitalist-white-hat sellout that the antisec people like to rant about (and steal mail spools from) in the weeks before BlackHat.

I know a criminal hack when I see it, and Aaron’s downloading of journal articles from an unlocked closet is not an offense worth 35 years in jail.

The facts:

• MIT operates an extraordinarily open network. Very few campus networks offer you a routable public IP address via unauthenticated DHCP and then lack even basic controls to prevent abuse. Very few captured portals on wired networks allow registration by any visitor, nor can they be easily bypassed by just assigning yourself an IP address. In fact, in my 12 years of professional security work I have never seen a network this open.
• In the spirit of the MIT ethos, the Institute runs this open, unmonitored and unrestricted network on purpose. Their head of network security admitted as much in an interview Aaron’s attorneys and I conducted in December. MIT is aware of the controls they could put in place to prevent what they consider abuse, such as downloading too many PDFs from one website or utilizing too much bandwidth, but they choose not to.  
• MIT also chooses not to prompt users of their wireless network with terms of use or a definition of abusive practices.
• At the time of Aaron’s actions, the JSTOR website allowed an unlimited number of downloads by anybody on MIT’s 18.x Class-A network. The JSTOR application lacked even the most basic controls to prevent what they might consider abusive behavior, such as CAPTCHAs triggered on multiple downloads, requiring accounts for bulk downloads, or even the ability to pop a box and warn a repeat downloader.
• Aaron did not “hack” the JSTOR website for all reasonable definitions of “hack”. Aaron wrote a handful of basic python scripts that first discovered the URLs of journal articles and then used curl to request them. Aaron did not use parameter tampering, break a CAPTCHA, or do anything more complicated than call a basic command line tool that downloads a file in the same manner as right-clicking and choosing “Save As” from your favorite browser.
• Aaron did nothing to cover his tracks or hide his activity, as evidenced by his very verbose .bash_history, his uncleared browser history and lack of any encryption of the laptop he used to download these files. Changing one’s MAC address (which the government inaccurately identified as equivalent to a car’s VIN number) or putting a mailinator email address into a captured portal are not crimes. If they were, you could arrest half of the people who have ever used airport wifi.
• The government provided no evidence that these downloads caused a negative effect on JSTOR or MIT, except due to silly overreactions such as turning off all of MIT’s JSTOR access due to downloads from a pretty easily identified user agent.
• I cannot speak as to the criminal implications of accessing an unlocked closet on an open campus, one which was also used to store personal effects by a homeless man. I would note that trespassing charges were dropped against Aaron and were not part of the Federal case.

In short, Aaron Swartz was not the super hacker breathlessly described in the Government’s indictment and forensic reports, and his actions did not pose a real danger to JSTOR, MIT or the public. He was an intelligent young man who found a loophole that would allow him to download a lot of documents quickly. This loophole was created intentionally by MIT and JSTOR, and was codified contractually in the piles of paperwork turned over during discovery.

If I had taken the stand as planned and had been asked by the prosecutor whether Aaron’s actions were “wrong”, I would probably have replied that what Aaron did would better be described as “inconsiderate”. In the same way it is inconsiderate to write a check at the supermarket while a dozen people queue up behind you or to check out every book at the library needed for a History 101 paper. It is inconsiderate to download lots of files on shared wifi or to spider Wikipedia too quickly, but none of these actions should lead to a young person being hounded for years and haunted by the possibility of a 35 year sentence.

Professor Lessig will always write more eloquently than I can on prosecutorial discretion and responsibility, but I certainly agree that Aaron’s death demands a great deal of soul searching by the US Attorney who decided to massively overcharge this young man and the MIT administrators who decided to involve Federal law enforcement.

I cannot speak as to all of the problems that contributed to Aaron’s death, but I do strongly believe that he did not deserve the treatment he received while he was alive. It is incumbent on all of us to figure out how to create some positive change out of this unnecessary tragedy. I’ll write more on that later. First I need to spend some time hugging my kids.

Edit 1: Fixed typo. Thank you @ramenlabs.

Posted from San Carlos, CA.

Posted from Peet’s Coffee, San Carlos, California

As I have repeated to a dozen reporters in the last 36 hours, there are three legs to the .secure tripod, Verify, Secure and Enforce.  Although we are able to mandate the security controls and protocols be put in place by servers under .secure with today’s technology, we do not have the ability to communicate this escalated level of protection to the browser.  Doing so is a critical component of providing the effortless end-to-end secure experience that I believe users deserve.

To that end we are working on chartering the Domain Policy Working Group.  We cannot announce the initial slate of members while legal work is still occurring, but I do appreciate the support that others have voiced for the project.

I have attached our very very very early draft below.  This document was meant to explore the opportunities provided to us by a protocol like DPF, and there is a lot of work to be done before it is ready for the IETF.  In the meantime, feel free to leave comments here to send them to alex at artemis.net.  If you are really inspired to help, then let us know at info at domainpolicy.org and we’ll let you know when membership slots open.

Please keep in mind that this protocol is meant to be usable on any TLD, and in fact part of Artemis’ business will be to host DPF and other security services on behalf of security-sensitive TLDs.  This protocol should also be usable by the incumbent TLDs, so it’s important to design something that can scale to .com size while not negatively affecting sites that do not opt-in to DPF services.

If you are one of the dozens of people who have found this blog you undoubtedly have heard of our controversial conversation-starting proposal to operate the .secure TLD.  I thought I would take this opportunity to discuss our motivations for going after this part of the namespace before diving into more technical details.

The Internet experience is completely broken for the vast majority of the world.  Of all of the problems that could lead one to this conclusion (I18N, governance, the inability to leave behind 1970’s technology) I would like to focus on an area somewhat within my expertise: trust and safety.  As you read this, on this planet someone is using a laptop on a café wifi network to pay a bill, over there that person is clicking on a link from an SMS message, and a lot of people are sending private information in an email.

If you interrupted any of these people and asked verbally if they trusted the Internet, or more specifically the technology they held in their hand that moment, they would likely hear the leading tone in your voice and answer “No.”  Yet apparently they each believe that the likelihood of a negative outcome is so low that there is no need to think before performing these actions.  Why do they think that?  In the developed world I would guess this “trust” derives from the trust we have been trained to put into all technology.  Do you carefully read a status message and push the correct button to keep your car from exploding?  Do you have to perform a risk assessment each time you cross a bridge?  No, you do not, because the engineers behind these types of products understand risk management under real world use and a great deal of thought is put into fool-proofing them against even a first decile consumer.

Should we blame them that they expect the same from us, the software and security engineers who build the shiny things they love?  When a normal, intelligent educated person picks up a $400 device with the computing power of Apollo-era NASA they naturally assume that somebody has taken care of problems like “click on the wrong link and my phone turns into a spam sending zombie”.  Sure, they read about malware, and hackers, and account take-over… “Heck, Aunt Julie had her identity stolen last year, and nobody figured out how.” I think it’s clear that even the most aware consumer still assumes that there is a man behind the curtain.

Which brings us to our topic, misplaced trust in the web.  This is a dialog that perhaps hundreds of thousands of people see each day:

Imagine that your uncle calls you, asking which button it is safe to push.  Where do you start the conversation?  An introduction to discrete mathematics?  A treatise on the difficulty of factoring large numbers across a finite field? An introduction to the X.509v3 standard?

I have deep sympathy for the browser engineers who maintain this code; they have been given the impossible job of creating a user experience that warns a user without bothering them and that allows a user to accept a risk they almost certainly do not understand.  We have come a long way from the completely obtuse dialogs of the past, but I doubt the average user is more likely to make the correct choice than they did with IE4.

One of the key goals of .secure is to invert the user’s security experience.  The human does not exist to serve the software.  Why does the user politely ask “I would like to go to my bank” and then need to interpret the 21^st century pixelated entrails to determine if they arrived at their destination safely?  The user is in charge; they tell the software what they want, and it’s our jobs to make the software listen.

Image by Susie Blackman

In my view, .secure is not a category, it is an expression of intent.  When a user types bank.secure, they are not saying “I want to go to the bank in the category of secure”, they are saying “I want to go to my bank securely”.  That means that all of the software standing between them and their destination needs to understand this intent, and then make the thousands of small decisions needed to make it so.   .Secure and the Domain Policy Framework are not the only ways to make that happen, but I believe they are the most expedient.

Those people likely felt more existential terror than the last security geek without a blog feels, although I do approach this project with a bit of trepidation.  There are already many fantastic security bloggers out there, and I doubt my voice is something the masses were pining for (“Why is there not more representation of bousie Western polo-shirt-wearing males of Greek descent among the security blogosphere?” they wail plaintively).

Still, if one is going to be a topic of conversation, one should be a part of that conversation.  Since it seems that my future endeavors will likely need more than 160 characters of justification I resign myself to learn the workings of the horseless carriage.

Somerset House