“Shoulder Dystocia,” said the Obstetrician, as we neared the end of my wife’s otherwise-routine delivery of our son last week. This meant nothing to me. My wife, on the other hand, freaked out. She’s a physician and had understood something I’d missed. My child’s head, which had only just emerged, began to visibly turn blue. I froze and, not for the first time in these medical situations, felt utterly useless.

What followed is best described as a highly coordinated dance. The Doctor started a set of rough and involved maneuvers, with stern orders to the nurse to apply pressure here, apply pressure there. The nurse pushed with one hand and grabbed the phone to call for help with the other. Within 30 seconds, before the additional help even arrived, a shoulder was out, one twist, and then the other. Our son cried and his color quickly turned pink. Cord clamped, scissors handed to me, I cut, doing my best not to shake from the adrenaline. The Pediatric team evaluated our son, and, 5 minutes later, he was in my wife’s arms. His left arm was visibly sore for a few hours. By end of day, though, the pediatrician was confident he had sustained no permanent damage.

So now, a few days later, I am beginning to understand. My son’s shoulder got stuck right after his head emerged. This happens in approximately 1% of births, though oftentimes the situation resolves itself. When it doesn’t, permanent nerve damage is a not-unlikely outcome, with reduced or even no use of the impacted arm. And, because the umbilical cord is compressed, the child cannot breathe. If my son hadn’t been delivered in the 5-10 minutes that followed, he could have suffered permanent brain damage or even died.

Instead, he is a perfectly happy 1-week old baby.

We’re so accustomed to things going well, we forget how quickly things can go wrong. We don’t often enough praise the folks in our society who have deep hands-on experience, with the training to react in a highly coordinated, rehearsed, scientifically proven manner in a matter of seconds. They’re the ones ensuring things go well. Most white-collar professionals, like myself, never need this kind of precise, automatic response. We see it in athletes, but we forget that doctors, pilots, soldiers, and a few others need it too. It’s a response so well learned it’s hard to imagine it could be anything but instinct. So we thank chance, fate, or some other mystical agent. We forget the role of these hands-on experts. We figure we can do without them.

Not so. In that one moment last week, decades of accumulated medical knowledge, analyzed by dozens of researchers poring over thousands of data points, condensed and taught to a team of doctors and nurses, rehearsed through years of training and ingrained through careful checklists, came together so that my son will never need to care that this ever happened. It’s awe-some, in the true sense of the word.

Here’s the BrowserID demo at the Mozilla All-Hands last week:

Given my prior work on email-based authentication (EmID, Lightweight Email Signatures, BeamAuth), you might think BrowserID was my brainchild. In fact, it really wasn’t. And, in a testament to the shrinking impact of academic publication venues, none of the BrowserID team had ever heard of my work on email-based authentication before I arrived at Mozila, even though Mozilla folks are quite well versed in the state of the art. But who cares: when I found out about the ongoing work and how we agreed on just about every design principle, I was incredibly excited. And when I realized the fantastic work the team had already done on defining a scaffolding and adoption path for the technology, I was super impressed.

BrowserID started with the Verified Email Protocol, designed by Mike Hanson and Dan Mills, who came up with the approach after extensive exploration of web-based identity approaches over the last two years. It’s a simple idea: users can prove to web sites that they own a particular email address. That’s how they register, and that’s how they log back in the next time they visit the site. BrowserID, the code and site, was initially bootstrapped by Lloyd Hilaiel and Mike Hanson. Shane Tomlinson and I joined the team in June. We now also have an awesome UX design team (Bryan and Andy) and the team continues to grow (yay Austin!)

So, that’s what I’m working on these days: BrowserID and other Identity+UserData efforts at Mozilla. I’m excited to be leading this technical effort. The team is amazing, and we’ve got big aggressive plans to help you control your identity and data on the Web.

On the night of September 10th, 2001, I was having drinks with an old friend (I’m having trouble remembering which friend!) in Chelsea, about 3 miles north of the World Trade Center. We stayed up late. We talked about world politics, terrorism, the Middle East. So when the alarm clock radio came on a bit before 9am (hey, I’m a software guy), with talk of a plane hitting a building, I thought I was having some messed-up dream based on the night’s conversation. By the time I turned on the TV, the second plane had hit. My mom called. “Mom, that’s a second plane, it’s not an accident.” I got a call from my sister who lived a few miles uptown, she was fine, too. I noticed a voicemail from my friend and coworker Josh. His wife, who worked in the WTC, was fine, as she was away on a trip. Then the cell phones went dead.

I threw on clothes and comfortable clothes. I watched the first tower collapse on TV. I grabbed a backpack, put on jogging shoes, and ran out of my apartment on 21st street, between 7th and 8th avenues. From my street I couldn’t see the towers, so I headed to 7th avenue. By the time I got there, all I could see was smoke. I had to ask someone on the street: “where’s the second tower?”

I started walking downtown, towards my office in TriBeCa, about a mile north of the WTC. I panicked for a moment: what if this was just the beginning and more was underway? I stepped into a convenience store, bought 3 candybars and 2 bottles of water. As I walked downtown, I passed cars stopped in the street, doors open, people standing with their radios turned on, straight out of some apocalypse movie. Then I started seeing people covered in dust. I made it to my office just south of Canal St, walked in, and logged on. I think I spent an hour clicking “respond”, writing “yes, I’m fine, more later.”

I found an unused IP address on one of our servers and set up a page to list “I’m ok” messages. Looks like the Internet Archive has a copy. I remember thinking I might be aggregating thousands of messages from around the city, though in the end it was obviously limited to my circle of friends. I guess I wanted to help, in any way I could.

Somewhere in there I chatted with co-workers, emailed our clients and partners, told them we were alright, asked how they were doing. One of our clients was on Wall Street and lost a number of friends.

In the mid afternoon, my friend Greg and I went up on the roof of our office building and talked, looking down Greenwich St towards WTC 7 surrounded by smoke of the collapsed towers. We went downstairs, heard on the radio that WTC 7 had collapsed, ran back up, and sure enough, it was gone. That night, Amanda, Greg, my sister and I crowded into my little apartment, ate frozen pizza and watched the news until we couldn’t anymore.

One of my best friends was stuck in Pennsylvania on a business trip. He wanted to be home in NYC, but couldn’t.

I gave my team the week off.

The next few days were odd.

I wasn’t able to fly out to the West Coast that Friday to see my friend Rodrigo’s new baby.

I stayed up nights listening to fighter jets flying overhead. I participated in far too many email arguments about “how to respond.” I was crazy and emotional. I made stupid, childish arguments. Within a few weeks, I would be calmer and, I think, more reasonable. I wish our leaders had also taken a moment to breathe.

People started going about their business again. There was the smell of burn in the air, but people tried not to talk about it. People were nice. Very nice. I went out a lot. I followed my friend Arjun to see indie bands on the lower east side. I didn’t want to stay in, ever, I needed to go out and be with people. I remember a faux-french band we saw, the guitarist wore an “I [heart] NYC” t-shirt he’d modified to say “J’[aime] NYC”. They didn’t mention the burning buildings. No one talked about it. Instead people went out of their way to be friendly, to reach out, to help.

That was, in some way, the saddest part of that experience. Everyone wanted to help. Doctors waited for the wounded, but none came. People lined up to give blood, but none was needed. People lined up to help downtown but there wasn’t room for everyone. So we tried to help each other, in small ways, every day.

I’ve got increased freedom, so I intend to use it. Starting today, I will not publish nor review papers destined for closed venues. Academic publications should be available for the world to read, to learn from, to build upon. If you’d like me on your program committee, if you’d like me to review a journal publication, if you’d like me to help with a paper, please understand that I will refuse if the conference/journal isn’t truly open. In the short term, this probably means I’ll only work with USENIX, and maybe IACR which appears to be moving towards true open-access.

My move isn’t exactly courageous. I have the luxury to make this decision, while many of my colleagues do not. I hope a few tenured professors make this move, though, as they have both the luxury and a good bit more influence than I do. Matt Blaze is starting down this path. Dan Wallach is helping tweak the IEEE approach. All of these efforts are incredibly important.

This is about free dissemination of knowledge. This is the point of the Internet. Academics who stand for discovery and learning should be outraged by the direction most publishers are taking today, and should at the very least encourage those publishers who are doing it well. Hesitating between ACM and USENIX? Go with USENIX. IACR holding a vote on open-access publishing? Make your voice heard.

In his speech to Harvard Med School graduates last week (stick with me here, this is relevant), Atul Gawande (author of the Checklist Manifesto), laid out, in his clearest and most convincing argument yet, how the practice of medicine needs to change:

The core structure of medicine emerged in an era when doctors could hold all the key information patients needed in their heads and manage everything required themselves. One needed only an ethic of hard work, a prescription pad, a secretary, and a hospital willing to serve as one’s workshop, loaning a bed and nurses for a patient’s convalescence, maybe an operating room with a few basic tools. We were craftsmen. We could set the fracture, spin the blood, plate the cultures, administer the antiserum. The nature of the knowledge lent itself to prizing autonomy, independence, and self-sufficiency among our highest values, and to designing medicine accordingly. But you can’t hold all the information in your head any longer, and you can’t master all the skills. No one person can work up a patient’s back pain, run the immunoassay, do the physical therapy, protocol the MRI, and direct the treatment of the unexpected cancer found growing in the spine. I don’t even know what it means to “protocol” the MRI.

Gawande tells colleagues they need to work as well-oiled teams. No heros, no cowboys. I believe, and surely I’m not the first, that the same path lies ahead for software engineers.

The open-source and free software movements caught on to this a long time ago. Sure, there are leaders (Richard Stallman, Linus Torvalds, Mitchell Baker.) But more importantly there are teams, incredibly agile teams of developers who rise to the occasion of the software itch that needs scratching. The coordination requirement on most software is usually not that of a medical team treating an emergency patient… except when it comes to releasing Firefox 4 to 100,000,000 users in 84 languages in a matter of days. You need a well-oiled open-source software machine run by a top-notch team, and that’s what Mozilla is.

There are no rock stars, or rather, everyone’s super impressive in their own way but no one is treated like a rock star. Because what matters is the team. This is incredibly refreshing for me, especially coming from academia where, though individual academics are highly collaborative by nature, there is a strong incentive to specialize, find a niche, and be the single rockstar in that niche, because that’s how you get promoted.

So I’m really enjoying Mozilla. And, we’re hiring, so if you want to work on one of the world’s most important pieces of digital infrastructure, drop me a line.

What started as a fun lunch with Sid and Alex quickly turned into passionate brainstorming with Mike, Pascal, and Lloyd on the Mozilla Labs team. I told them I wanted to deeply explore a few ideas I’ve written about and prototyped (here and here, for example) and more importantly to work on making the browser a true user agent working on behalf of the user. Mozilla folks are not only strongly aligned with that point of view, they’ve already done quite a bit to make it happen. Check out Mike Hanson’s post just a few days ago on using Web Applications for Service Discovery. And check out what the entire team just released: Open Web Apps. Not to mention the less closely related but still totally awesome work Sid and Alex are doing with Do Not Track. This is the first effort I know of that is successfully using technology to declare a preference (“please don’t track me”), which can then be leveraged by policy makers to ensure that it is respected. As a long-time student of the interplay between tech and policy, I love this hack.

My job will be to join this fantastic team and see what I can contribute. I suspect that will involve some privacy, some crypto, some data portability, and a lot of web hacking. I’ll continue to blog here at benlog.com, though when I speak here I’m speaking for myself only, not on behalf of my soon-to-be employer. And I’ll continue to hack a bit on Helios, my voting system, especially as it continues to inform how one might do advanced crypto in a web browser.

I’m super excited.

I’m taking two weeks off. I won’t be blogging or tweeting (much). I’ll be digging into a very thoughtful gift just received (what timing!): the Flour Bakery recipe book. If you live in Boston and you haven’t been to Flour, you’re simply missing out (or you don’t like baked goods, which is just too sad to think about.) This week’s goal, currant scones. Should be at least interesting, maybe delicious.

As to what I’m doing next… that’s for a blog post to be written 2 weeks from now. I’ve had some fantastic discussions with amazing people these last few weeks, and there are a few more conversations to be had before the picture is truly filled in. See you on the flip side of a few days spent with family and friends.

I want to build software for this thing. I’m really excited about the idea of a touch-screen computing platform that’s available for general use from a known brand who has successfully marketed unfamiliar devices to a wide audience.
[..]
It represents an incredible opportunity, but I can’t get excited about it because of Apple’s attempt to control who creates for it, and what they can create for it. Their policy of being the sole distributor of applications, and even worse, requiring approval on all applications, is insulting to developers.
[..]
I find it offensive on a very basic level, because I know that if such restrictions were in place when I was first learning to write software — mostly on Apple machines, no less — I would not have a career in the field.

John Lilly followed up brilliantly:

In a nutshell, what worries me about the trajectory of computing is not so much the emergence of tightly-controlled, non-tinkerable boxes, but the presumption that “normal people” don’t ever want to tinker, don’t want to be bothered with understanding how things work. I think it’s not true, really — certainly not for everyone — but I even think that this distinction between “normal people” and “tinkerers” or “techies” or “makers” is bogus at best, and really dangerously corrosive at worst.
[..]
It’s not like I was born an engineer — the instinct to fiddle with things isn’t something we’re born with. I became a tinkerer because I was exposed to surfaces that allowed — that invited — it. I figured out that I liked tweaking and building and creating because I got a bunch of chances to do that stuff, from hardware to software and everything in between. I knew I could do it because Dad modeled that behavior, but also because the stuff we had around the house was inspectable and malleable.
[..]
We all have the potential inside us to make things. But we’re not born into the world as makers — the world around us — the people in it and the artifacts in it — help us to discover what we can be.

I don’t know that I agree 100% with John: not everyone is a tinkerer. But, for sure, we need “surfaces that invite tinkering,” otherwise those who would be tinkerers might never discover it.

I was a tinkerer from an early age, but most of my tinkering in the physical world sucked, because, well, I don’t have good instincts about physics or analog things: I’m a digital kind of guy. So my egg-drop competition entries were overly complicated, my solar ovens were a perfect fit for a raw diet, my matchstick suspension bridges were unsafe at any speed, and my analog-circuit-based room-alarm systems would go off at random times in the middle of the night, or not at all, but at least would consistently end up blowing out the LED indicator (what do you mean you can’t connect the power source straight to the LED?)

I might have given up on tinkering, were it not for software… that was something else.

When my father brought home our first computer, a Thomson MO5, I was hooked. I spent hours transcribing BASIC programs from the 3 magazines I could find on the topic (this was Paris, France, not exactly Silicon Valley.) My dad took me to the office so I could talk to some Thomson engineers and debug my floppy disk drive. Later came the TO7, and eventually the Apple IIGS, my first “major” Pascal program to help my mother schedule carpooling (and my first taste of how hard it is to write a scheduling algorithm), my second “major” Pascal program to manage the Prom guest list. I wrote my final Geography report using a page-layout program on the Apple IIGS that probably cost me hours of extra time because of its bugs and the work-arounds I had to find, and got a worse grade for it because “not everyone can afford such fancy software, so we took off a couple of points” (for those of you still confused, THAT is socialism.) Not long after that I was applying to MIT and tinkering with one of the first e-commerce web sites. I love what I do, but would I have discovered this love without those first few lines of BASIC on that MO5 computer, written without anyone’s permission or knowledge?

Over time, though, I have become a little bit complacent about openness. I own an iPhone, and I’ve bought a few apps. I bought music on iTunes, and figured the DRM was not so problematic. I got a Kindle and bought some books. And then one day Apple’s DRM server went down and I couldn’t play music for a few hours. And Amazon decided to recall the book “1984″. And Apple decided to retroactively remove a bunch of apps they considered “not useful enough.” So I started thinking, maybe it’s time to get a different phone.

But I can’t. See, in the interim, I got unexpectedly locked in. I sync my calendar via MobileMe. I sync my music/TV shows via iTunes. Moving to something like a Palm Pre is going to take a significant effort. So how much worse will it be if I get an iPad, get some apps, and Apple decides to change the rules in a way that I don’t like? How locked in will I be then?

This change is happening gradually. At no point are you going to be shocked by an unfortunate Apple decision. You’ll enjoy your iPad, you’ll buy more apps, you’ll enjoy it even more. Apple will make a few decisions that inconvenience you, but you’ll deal. Until one day you’re inconvenienced enough that you might begin to look elsewhere. But you won’t be able to, because your data will be locked in. 3 years ago, we didn’t even have 3rd-party apps on the iPhone. Today, we have more than 100,000, and they’re all rushing to the iPad at warp speed. Change is happening.

One last point. A few months ago, I became a father. My wonderful little boy has an incredible appetite for life. Will he be a tinkerer? I don’t know, but if I had to bet I’d say yes. Will I be able to do for him what my father did for me? What will he tinker with, if everything in the house is a polished, professional, touch-but-don’t-tinker device? If he is to be a maker, a tinkerer, will he be able to fully explore his ideas if the rules of his digital universe are decided by the whims of Apple, Facebook, and Google?

I’m not sure. Maybe he will find a way, the way that kids do. Or maybe we, the generation that is witnessing this change, need to make sure that the rules of computing do not become a permanent, universal, inescapable sandbox.

One can have a number of arguments as to whether this is an efficient way to do research. Hint, it’s not, it’s terrible, it makes research fantastically expensive and slow. But I’m actually less concerned about that than I am about the principle: how is it okay for a naturally occurring substance that is part of me to be controlled by someone else? It’s ludicrous, and it violates a basic sense of personal freedom. Might a patent holder eventually have the right to charge me because my body is naturally producing a beneficial chemical derived from “their” gene?

So the ACLU is taking on this fight, and I commend them for it. This is a big deal. And the opposition to their action is going to be fierce, because the short-term financial interests in gene patenting are enormous. But this is the fight that matters for personal genomic freedom, efficient biomedical research, and generally finding a sane balance between necessary commercial incentives and basic freedoms. Patent a novel genome sequencing technique? Yes, by all means. Patent a gene itself so that no matter what other sequencing technique is invented, it can’t be used to sequence the “owned” gene? Insane, and wrong.

Over at CHIP (Children’s Hospital Informatics Program), we’re a bunch of folks who feverishly believe that Personally Controlled Health Records (PCHRs), records you get to share, protect, augment as you see fit, are going to be the IT platform of a new, more efficient health care system. You don’t have to believe me, you can just ask Clayton Christensen, the Harvard Business School professor who wrote the book(s) on disruptive technology. And Microsoft HealthVault and Google Health certainly seem to agree with that concept. My group’s project, Indivo, was the original PCHR that inspired the Google and Microsoft efforts (long before I arrived on the scene, so I take no credit.)

Recently, Google Health announced a deal where you can get your CVS pharmacy data into Google Health. That’s great… but can I get the data without involving Google Health if I want to? In other words, will CVS offer me a CSV (comma-separated values) file of my data so I can put it in my own spreadsheet or upload it to a competing PCHR?

I don’t know for sure, but from their web site it looks like they do not support that machine-readable data export. In other words, it’s your data, as long as you use Google Health. (Oh sure, you can export from Google Health, but what if you don’t like Google’s privacy policy?)

Adam Bosworth recently wrote about data liquidity in health records, and he’s right on. Data liquidity means that we stop with these one-off integrations, and start building common APIs and open data formats. Only then will we gain the efficiencies we seek from letting individuals truly control their personal health record.