June 22, 2010

Programmer's Dilemma: Baby-Proofing vs. Giving Guns to Monkeys

One of my best friends from college once described a previous job in the financial industry as something akin to "giving guns to monkeys."

He felt that the product he sold, although it was something that could reap tremendous benefits for his customers if used properly, was something that more often than not harmed customers' livelihoods because the tool was too unwieldy and naunced for the average person to use correctly.

Like my friend in the financial industry, programmers are faced with a similar quandry - do we give our users enough rope to potentially hang themselves (more freedom) or do we provide a more authoritarian, constrained, "baby-proofed" experience (less freedom?)

All programmers are UX designers

Giving guns to monkeys and baby-proofing aren't about bugs or errors in the software. The concepts are both about making judgement calls in user experience design, and it's not just the UX gurus who have to worry about this sort of stuff - every programmer does.

Here's a technical example which illustrates my point:

I'm in the midst of creating an open source library for seamlessly parsing RSS/Atom feeds for legacy .NET 2.0-3.5 projects, where we don't have access to .NET 4.0's built in SyndicationFeed classes.

One of my test cases is the Hacker News RSS feed (http://news.ycombinator.com/rss), and when I tried to execute a basic HttpWebRequest against it, the method failed because apparently Hacker News' feed is not fully RFC-complaint and thus HttpWebRequest raises an error as a defense mechanism in order to prevent HTTP response split attacks from occurring.

Microsoft responded to a legitimate security problem with a binary solution - either you turn off unsafe header parsing and run the risk of a split response attack or you simply don't process data from sources with malformed headers. They baby-proofed it.

And what, pray tell, does Microsoft recommend for us developers who want to use HttpWebRequest to download feeds from sources like Hacker News?

"If you find a site that exposes this behavior [non-RFC-compliant HTTP headers], contact them and ask them to fix it."

At no point did this behavioral decision grace the desk of a UX person at Microsoft (that's my assumption at least,) nor should it have. It's a user experience issue, but it's one that affects other programmers trying to leverage Microsoft's .NET framework in their own projects. Therefore the user experience decisions are made by the very programmers who maintain this portion of the framework.

One can hardly fault Microsoft for erring on the side of caution when it comes to security; in fact, the decision to make HttpWebRequest throw an error when a potentially unsafe header is detected is probably the right call.

I suspect a lot of developers honestly don't care to download content from sources with non-compliant headers. However there are a number of developers who want the freedom to make calls to those sources, and since Microsoft made it somewhat difficult to disable this security mechanism there's now an enclave of programmers who all use the same configuration hack to reverse Microsoft's decision, which ultimately isn't something Microsoft wants either.

This decision is one where not enough freedom was given to end-users - one whitespace character in the Content Length (should be Content-Length) HTTP header shouldn't force .NET programmers to deny their own application/service's end-users the ability to consume RSS feeds like Hacker News.

So what do you think? How much freedom should be afforded to the people who use our libraries, APIs, applications, and services? Is it better to baby-proof or give guns to monkeys?

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..