Three years ago, a dear friend called me around 1AM on a random, unassuming Friday and asked what I was going to work on next. I had received great offers from the usual suspects, I told him. Then I off-handedly mentioned how no one from Apple had gotten in touch.

He thought about it for a moment. “Have you e-mailed Steve?”

At 1:46AM, I e-mailed Steve.

I turned 23 a couple of months ago, and I want to work on things that I can be passionate about. Apple is the only company in this industry still making products that people find inspiring. That they give a shit about.

I could do great things at Apple.

Early the next morning I received a phone call; a couple of weeks later, an offer. I took it without thinking twice, and it was one of the best decisions of my life.

Steve brought a sense of childlike wonder to a crowd of millions. What the world lost with his passing cannot be replaced. But his genius, his vision, and the single greatest thing he’s ever built all live on.

Here’s to the crazy one.

Nine months after the Spirit rover sank into a Martian sand trap, NASA says the troubled traveler will have to remain stationary in order to survive the Red Planet’s winter.

These fucking Martians keep leaving their deadly sand traps everywhere. No regard for life or property. Can’t we, like, send John McCain up there to keep these guys in line?

But then I get an e-mail from a friend, who saw on Slashdot that Engadget reported that ZDNet Asia has an interview with Nicholas Negroponte, or something, and it’s been getting a bunch of press. Now, last time Nicholas got a bunch of press for an interview, it was for calling his employees terrorists; I wondered with slight trepidation what bombshell he dropped this time. Here it is, in its inglorious entirety:

Putting a crank-shaft on the XO laptop was a mistake, but the biggest mistake was not having Sugar run as an application “on a vanilla Linux laptop”, said OLPC founder and chairman Nicholas Negroponte. “Sugar should have been an application [residing] on a normal operating system,” he told ZDNet Asia in an interview. “But what we did… was we had Sugar do the power management, we had Sugar do the wireless management–it became sort of an omelet. The BIOS talked directly with Sugar, so Sugar became a bit of a mess.”

And just like that, more than a year after I left the company, it became clear to me that OLPC can still raise my blood pressure. So let’s talk about Sugar.

When we started software development for the XO, I went on an internal anti-Sugar crusade. Long after everyone else had made up their minds about the need for a new learning-oriented GUI, I was still obnoxious and combative in trying to kill the idea before we began work on it. I wrote strongly-worded internal memos, I argued with Walter, and I got into countless many arguments with just about every Red Hat employee that worked on the project — a number of them won’t talk to me to this day. I tell you this to make it clear that this post is not about defending myself or my work. I was never a Sugar developer, I was never credited as such, and my contributions to Sugar are probably under 20 lines of code contained in a couple of critical bug fixes.

In trying to stop OLPC from putting its weight behind Sugar, my reasoning was fairly straightforward: it’s too hard for a tiny team to build a new GUI platform in a very short amount of time, and it’s silly to throw away the thousands of man years of effort that have gone into mainstream Linux desktop environments and the applications they run. Eventually, I realized I was pissing people off without managing to dissuade them, so I stood down. Sugar was built, and over time, is becoming an increasingly compelling platform.

And of course, Nicholas’ interview gem has nothing to do with anything I just said.

Here’s the problem: through a somewhat regrettable set of naming decisions, the name “Sugar” came to represent two entirely different things. It was the name for the new learning-oriented graphical interface that OLPC was building, but it was also the name for the entire XO operating system, one tiny part of which was Sugar the GUI, and the rest of which was mostly Fedora Linux.

Nicholas, evidently, still remains blissfully unaware of any of this. As is plain to see from his own words, what he considers to be the biggest mistake of the project has nothing to do with Sugar the GUI, and everything to do with the gross, hairy, complicated systems development work that OLPC was doing to support the XO’s special hardware features. And to be clear, I mean “short bus special”, not “shiny unicorn special”.

Let me explain something to you. For most of OLPC’s existence, we had about two guys working on Sugar the UI. They were GUI developers, with GNOME backgrounds. They were not at all the same people doing systems development work to support our hardware. No resources were taken away from systems development to do Sugar. If Sugar hadn’t happened at all, we would have still had to do all the systems work to get Linux working on the XO, and it would have still taken just as long. So if you’re looking for things to blame, Sugar is not the droid you are looking for.

In truth, the XO ships a pretty shitty operating system, and this fact has very little to do with Sugar the GUI. It has a lot to do with the choice of incompetent hardware vendors that provided half-assedly built, unsupported and unsupportable components with broken closed-source firmware blobs that OLPC could neither examine nor fix.

So we wound up with a keyboard whose keys get stuck. A dual-mode touchpad, capacitive and resistive, where one mode doesn’t work at all, and the other makes the cursor spontaneously jump around and sometimes shuts off the touchpad altogether, prompting OLPC kernel developers to beg for saner hardware in the next round. We had board engineering issues that made power management practically impossible. We had a custom display controller chip that was incomplete in some regards, and completely broken in others. We had an embedded controller that blocks keyboard events and stops machine suspend, and to which we — after a long battle — received the source, under strict NDA, only to find a jungle of nested if statements, twelve levels deep, and no code history. (The company that wrote the code doesn’t use version control, see. They put dates into code comments when they make changes, and the developers mail each other zip files with new versions.) And we had a wireless chip that is so far beyond fucked, it’s just about funny.

(Each of those words is a different link. Click them all, I dare you.)

Thinking back, there’s a hardware incident I remember particularly fondly: one of our vendors sent us a kernel driver patch which enhanced support for their component in our machine. They chose to implement the enhancement by setting up a hole which allowed any unprivileged user to take over the kernel, prompting our kernel guy to send a private e-mail to the OLPC tech team demanding that, in the future, we avoid buying hardware from companies whose programmers are, direct quote, “crack-smoking hobos”.

In the end, Nicholas’ bit of interview nonsense just doesn’t pass the smell test. Customers aren’t stupid. There’s close to a million XOs out there; if Sugar was OLPC’s biggest mistake, Windows on the XO would be selling like hotcakes. Let me remind you, then, that the number of Windows-based XOs that OLPC has sold is exactly zero.

So next time you hear Nicholas break out the egg metaphors and wave his hands about the Sugar that doomed it all, shrug and smile. Hell, If I were a meaner person, I’d ask Nicholas why it is that Windows — you know, the Windows from Microsoft, mercifully unstained with the mistake of Sugar — can’t even shut down an XO without throwing up a blue screen of death.

But I won’t ask. Because it’s warm and sunny in California, and I have a hot tub calling my name.

My thanks to Walter Bender for reading a draft of this post.

About a year ago, I left One Laptop per Child and decided to find a new adventure. Last August, I was admitted to the graduate program at MIT, and while I was fantastically excited to study with an extraordinary advisor, life had other plans. I did not enroll. But I’m still receiving quite a bit of e-mail asking what I’m up to these days, so perhaps a short update is in order.

I spent much of the last year devoted to my own research. I spun down various commitments, and took up a few others: I joined the advisory board for the Anti-Malware Testing Standards Organization, became a member of the technical working group for Harvard Berkman’s StopBadware, and joined the Security Response Team for Python, my programming language of choice.

Earlier this year I reprised my role chairing the Program Committee for the 2009 PyCon. I also added a small sideshow to the conference: a summit for dynamic language implementers, with participants from 12 different language groups. All my involvement with the Python community continues to be both humbling and inspiring; I have yet to find such a compelling mix of intelligence, humor and interpersonal warmth in another technical crowd.

But perhaps most importantly, I have — at long last — found my new adventure. After a great deal of deliberation, I moved to California and joined the local fruit vendor.

Today was my first day on the job, and I couldn’t be more thrilled.

Neuroenhancers are perfectly suited for the anxiety of white-collar competition in a floundering economy. And they have a synergistic relationship with our multiplying digital technologies: the more gadgets we own, the more distracted we become, and the more we need help in order to focus. The experience that neuroenhancement offers is not, for the most part, about opening the doors of perception, or about breaking the bonds of the self, or about experiencing a surge of genius. It’s about squeezing out an extra few hours to finish those sales figures when you’d really rather collapse into bed; getting a B instead of a B-minus on the final exam in a lecture class where you spent half your time texting; cramming for the G.R.E.s at night, because the information-industry job you got after college turned out to be deadening. Neuroenhancers don’t offer freedom. Rather, they facilitate a pinched, unromantic, grindingly efficient form of productivity.

The article is a good read covering a fascinating subject, and I’m only going to add two pieces of supplemental reading. If, like me, you found Talbot’s article overly anecdotal and painfully short on the science, you need to read Botox for the brain: enhancement of cognition, mood, and pro-social behavior and blunting of unwanted memories appearing in Neuroscience and Behavioral Reviews 32 (2008) 760-776. Due to the epic pain in the ass that is closed-access academia, you or your academic institution need to pay a boatload of money to Elsevier to read the paper, so I’m sticking it right here (PDF) until I’m asked to take it down.

And if the specific phrase Talbot uses at one point in the article — “mind hacking” — made you pause and reflect on just how fascinating a concept that is, my second link for you is a story. Cory Doctorow explores mind/body hacks in 0wnz0red, and it’s convincingly one of my all-time favorite pieces of short science fiction.

Ten days ago, comrade Nils e-mailed to let me know he was going to be at the conference. I couldn’t make it myself, being stuck in Europe for the moment, but ever since that e-mail, I’ve been giggling like a schoolgirl about what I expected Nils would do at Pwn2Own.

What he wound up doing far exceeded my expectations. First, Nils scored against Safari on OS X. Then he scored again, hitting Internet Explorer 8 on Windows 7 (despite ASLR, DEP, and friends), snapping everyone’s head to attention. I was anticipating this might take place; the hardcore Sotirov/Dowd paper set the stage for it last year and Nils is smart enough to do it, yet the fact he pulled it off is still indisputably impressive. But the part no one saw coming: he asked for a third slot and scored against Firefox 3 on OS X, leaving Chrome the only browser to escape unscarred.

One man, two operating systems, three fallen browsers? I have no choice but to officially award comrade Nils the Ivan Krstić Seal of Mad Fucking Props.

And we now return to your regularly scheduled programming.

(Update, March 23rd: I originally believed he scored against Firefox on Windows, which turned out not to be the case. It was on OS X.)

I’ve received this question with some frequency, and even gave a brief talk about it last year. The subject matter is rather nuanced, and providing an explanation that does it justice would take a lot of effort, so it’s been sitting on my “to properly write about when I have some time” pile for quite a while now. Unfortunately, it recently became clear to me that The Pile is mostly a black hole. Not wishing to sorely disappoint Greg the Grad Student, I sent him the following sketch of an answer.

If I had to grossly overgeneralize, I’d say people looking at language security fall in roughly three schools of thought:

1. The “My name is Correctness, king of kings” people say that security problems are merely one manifestation of incorrectness, which is dissonance between what the program is supposed to do and what its implementation actually does. This tends to be the group led by mathematicians, and you can recognize them because their solutions revolve around proofs and the writing and (automatic) verification thereof.
2. The “If you don’t use a bazooka, you can’t blow things up” people say that security problems are a byproduct of exposing insufficiently intelligent or well-trained programmers to dangerous language features that don’t come with a safety interlock. You can identify these guys because they tend to make new languages that no one uses, and frequently describe them as “like popular language X but safer”.
3. The “We need to change how we fundamentally build software” people say that security problems are the result of having insufficiently fine-grained methods for delegating individual bits of authority to individual parts of a running program, which traditionally results in all parts of a program having all the authority, which means the attack surface becomes a Cartesian product of every part of the program and every bit of authority which the program uses. You can spot these guys because they tend to throw around the phrase “object-capability model”.

Now, while I’m already grossly overgeneralizing, I think the first group is almost useless, the second group is almost irrelevant, and the third group is absolutely horrible at explaining what the hell they’re talking about.

(If I was trying to be less overly general, I’d mention that in some instances the groups overlap substantially, and some subsets of these groups, such as the subset of group 2 that’s working on SFI and sandboxing, are relevant and occasionally produce good work.)

In terms of a very incomplete reading list for getting to know more about the subject, I recommend starting with Mark Miller’s PhD thesis, then looking at his work on Caja (paper, website) which aims to provide a way to securely write JavaScript without changing the language spec or the existing runtimes, and in the end having a glance at David Wagner’s work on Joe-E. All of those links fall into the “let’s change programming” group 3.

For a bunch of papers in the “mathematicians do it provably correctly” group 1 (though most not focused on security), see the publications section of the Alloy website.

Finally, for the “practice safe hex” group 2, take a look at Cyclone (paper, website), NaCl (paper, website) and Vx32 (paper, website).

Combined, these will give you enough references to chase the subject matter as far down the rabbit hole as you dare descend. Good luck, and may the gods have mercy on your soul.

While I hope to offer some insights that the technologists in the audience haven’t heard before, this is also my first security talk in a few years that doesn’t require much of a security background. Which is to say, the only prerequisite is a bit of curiosity. The talk is open to the public — hope to see you there!

When: This Thursday, March 5th, 7PM
Where: Harvard Science Center, room 112, 1 Oxford Street, Cambridge, MA (Map)
What: The Bitter Tale of Desktop Security: Our 35-year War
Abstract: It’s 2009. About 75% of all corporate machines are infected with at least one piece of malicious code. We’re seeing the emergence of weapons-grade botnets, designer trojans, and smart mobile malware. The black hat community is graduating from a ragtag army of rebels without a cause to a group of well-paid professionals engaging in research-quality work to rake in profits and evade detection. The entrenched players in the security industry have been predictably slow to respond. Now, seemingly bewildered by the new security landscape, they are increasingly claiming that salvation lies in restrictive new systems which threaten to transform your computer into little more than a glorified abacus. There must be a better way.

This session doesn’t require a security background: we will turn to history to try and explain why none of our machines are secure. We’ll then look at the problems of legacy and authority and explain why the road to a secure desktop is fraught with such toil and peril.

An article last Sunday about Rahm Emanuel, the White House chief of staff, misspelled the surname of the then-governor of Illinois who talked with Mr. Emanuel about the vacant Senate seat in his state. He is Rod R. Blagojevich, not Blogojevich.

An understandable mistake.