A brief but important edit (Oct 31, 2012 ~11PM MDT) to any visitors that may have taken notice of my rather brash letter to the CPSC: I should correct that near as I can tell Buckyballs is not shuttering their doors. I screwed up in my fit of inappropriate (but correctly directed) rage. It was a knee-jerk reaction on my part and–as best as I can tell without hearing directly from Buckyballs–completely false. I was told that they were and read the front page post in that context, angry enough that I wasn’t thinking clearly. For that, I publicly apologize to everyone. I’m sorry about my shoot-first, ask-later behavior. However, I’m still not sorry about the premise of my letter. How I feel about the CPSC hasn’t changed since I first heard about the “voluntary” stay of sales several months ago. I think the agency’s behavior is a terrible misappropriation of taxpayer money, and I think they should themselves be placed under some form of oversight to which they are ultimately held responsible and must answer directly to the public.

However, there is still some truth to my anger. Upon re-reading the statement on getbuckyballs.com, I can only surmise that our favorite types of magnets may be removed in their entirety. What they’ll be replaced with is anyone’s guess, but I imagine that it’ll be something lower powered and “less dangerous” (for some value of perceived danger)–and also less fun. While it doesn’t equate to shuttering the company’s doors, and moving into another product line is certainly a wise idea financially, it does mean that the Buckyballs we used to know and love are likely dead. Gone. Forever.

Regardless, I have retained my letter as I originally wrote it. This means that there’s a large degree of embellishment on my part, but I was upset when I wrote it and under the (mistaken) impression that Buckyballs were no more. Although, I guess that last part is still true to a lesser degree.

Hey, if the CPSC can embellish the facts (okay, okay, completely lie) about the degree of harm brought to the offspring of inept parents who thought it would be funny if their children devoured magnets like Halloween chocolates by conflating the number of injuries, I can embellish what I like, too. My mistakes aside (and I’m expecting to be corrected on this matter by the Buckystaff when they receive the copy I sent them–undoubtedly upset with my factual errors ☺), I still stand by the basic premise: The CPSC is out of control and needs to be reigned in as an organization. Rather than ignoring real, material threats to children’s lives, they’re targeting successful, popular industries. Buckyballs may not yet be gone, but there are a few smaller vendors that did close up shop earlier this year. The narrative is therefore at least partially correct in spirit even if my statements don’t match the immediate facts.

I won’t hazard a guess why the CPSC wants to shut down magnetic toy companies so badly, but I certainly feel–as a geek–that my consumption habits are being unfairly targeted because the CPSC doesn’t want me to have fun. If they really did care about children, they’d spend more time educating parents and less time banning products that have even a slight potential of misuse. To the CPSC: There is a stark difference between products that present a material and immediate hazard to consumers and ones that are only dangerous if they are misused. A gas grill that causes its propane tank to explode when lit is a material, immediate hazard, and represents a fundamental design flaw. Magnets (or guns, or knives, or doors, or hazardous chemicals) that cause harm when misused do not represent a design flaw; they represent instead the ineptitude of the people who have purchased them.

This letter should be considered to be in the public domain. You may use this letter in part or in whole if you desire to write your own response to the CPSC.

Dear CPSC,

I want to thank you in your efforts against Buckyballs and other high-powered magnet distributors. According to the announcement on getbuckballs.com it would finally appear that they’re closing their doors, ridding the free world of dangerous items that should be kept out of the hands of children whose parents’ vocabulary lacks the word “responsibility,” and most importantly out of the hands of responsible adults who understand the term but may or may not have children of their own.

It’s excellent news that we have a government agency working hard during these economically difficult times spending a great deal of effort forcing businesses out of business due to spurious charges and sending some 2,000+ people straight to the unemployment offices. After all, what difference is a couple thousand more people on unemployment going to make on the national debt? Not much, of course, so it likely doesn’t matter. Certainly not to an agency that doesn’t have to make payroll–and doesn’t especially care if it shuts down businesses that do.

What does matter is the absolutely absurd campaign the CPSC has been running against companies selling high powered magnets. Yes, it’s a tragedy whenever children die or must undergo a painful operation because they foolishly swallowed something that should have been kept out of their mouths in the first place. But it’s more disconcerting when a single, un-elected board can decide what businesses are effectively allowed to continue operating and which ones cannot. Worse, when a business can be shut down simply because a relatively small handful of people have levied complaints against them with the support of a couple of fanatical physicians, we are poised to lose many more of our already dwindling freedoms. Yet, there is an almost pathological imbalance between the actual danger presented by magnets and the response of the CPSC contrasted with other products. The CPSC isn’t working to ban buckets, skateboards, bicycles, swimming pools, or motor vehicles, each of which kills far more children per year than rare-earth magnets have in their some 3 or so years of market exposure.

As a consumer who considers himself reasonably informed and educated, these actions puzzle me and strongly hint at a less than impartial response on the CPSC’s behalf. Is this the result of a political motive against what was once a $20 million a year industry? Does the CPSC treat, unequally, the packaging industry responsible for creating buckets simply because they have stronger lobbyists or donate to the right campaigns? Or is the CPSC staffed by individuals who have no background in any of the natural sciences and therefore see magnets as a type of “black magic” that need to be banned simply because they have no idea how they work?

The CPSC represents the interests of consumers, but I can’t help myself from feeling that my voice–and the voice of many other happy consumers of various magnetic toys over the years–has been squelched because of an exceptionally noisy minority. This is the danger when an appointed–not elected–board holds a disproportionate amount of power over the marketplace. The majority has its rights stripped completely because of the ineptitude of the few.

I don’t have children. I’m not planning on having children. I have on my desk as I write this letter a box of Buckyballs and there are no less than three warnings visible: Two on the product box and one on the plastic sleeve in which it was originally shipped. Further, there are at least two additional warnings, one on the orange plastic container holding the magnets and one inside the instructions and product literature. Yet under my bathroom sink, I have harsh cleaners that are undoubtedly highly toxic if ingested and none of them have more than one warning label per bottle. The primary difference? The household cleaners have child-proof caps on them. Why couldn’t the CPSC have negotiated with the magnetic toy industry to ship their goods in child-proof containers as a reasonable compromise?

I can’t answer this question without unnecessary speculation, and I suspect it’s a mix of egotism, a knee-jerk reaction to a largely imagined threat, and political favoritism toward industries that can afford political asylum better known in our great country as “lobbyists.”

Given this, it seems to me that the warnings on these magnets and your response to the danger presented by them are both highly disproportionate to the actual harm they’ve created versus the actual dangers of other products. This product was not marketed to children in any capacity; my first set was purchased via ThinkGeek as a toy for adults (14+), and I’m well aware of the hazards of magnets (though I admit I’m more worried about potential data loss on magnetic disk drives than any material hazard presented to myself by these magnets). It’s a crying shame that a single four letter agency operating under the guise of consumer safety can wield more power and strip consumers of more freedom than certain three letter agencies whose business often necessitates the use of such power (CIA, FBI, even the IRS).

Of course, the Constitution doesn’t protect magnets, so I cannot claim that it’s an inalienable human right to own magnets. What a shame! Had the CPSC been created around the time of the Wright brothers, I suspect human flight would still remain a thing of fairy tales–to say nothing of the automobile, bicycle, horse riding, sports… I could go on.

I’m angry, frustrated, and gravely disappointed at the coddled society we’ve become thanks in no small part to the increased momentum we have spiraling toward an out of control nanny state sponsored by government agencies like the CPSC. While children remain relatively unprotected by very real threats to their safety like those presented by other products, we’re at least kept safe from those that present the least hazard. A reasonable society would have resorted to consumer education and awareness. Yet we are not a reasonable society any longer; we ban first, then tie up affected parties for months (or years) in expensive legislation, often (ab)using the turtle’s pace of the Department of Justice as a means of wearing the defendant’s finances thin. I thank my lucky stars I’m not in an industry that produces material goods that could be subject to such scrutiny.

I look forward to the day the CPSC bans toys containing dihydrogen monoxide. It’s a truly horrid substance responsible for dozens of drowning deaths each year and can harbor dangerous diseases if left to stagnate. I wonder then what the rationale behind such a move might be? If we don’t change course and reign in an out of control agency, then I suspect we may very well find out in 10-20 years.

If this were a perfect world, I’d be overjoyed instead to see the CPSC’s staff standing in the unemployment line rather than the employees of an American business driven OUT of business by the strong arm of the nanny state.

Best Regards,

Benjamin

A spurt of curiosity this evening–more specifically, one of those circumstances we each have from time to time wherein a handful of unrelated thoughts flutter about the conscious mind like a pair of butterflies flitting from flower to flower–consumed me sufficiently that I decided to do a brief Google search on prepared statements. I’m unsure where such a motive originated, but I’m fairly convinced that it was at least tangentially related to some misinformation I’ve heard of late related to web programming advice and also possibly due to my surprise that few commercial PHP bulletin board packages actually use prepared statements.

Before I begin, let’s consider for a moment that last and most disconcerting statement: Few commercial PHP forums use prepared statements. To the uninitiated, this might seem to be a matter of nick-picking unimportant to the real world. To the rest of you, it may come as a sad commentary on the state of modern programming and commercial software (perhaps, fittingly, as a commentary on the average run-of-the-mill PHP programmer). Prepared statements certainly aren’t new, and while they’ve been a part of PHP for a number of years now, it’s infuriating that they hardly see common use.

PHP first shipped PDO with PHP 5.1 (available as a PECL extension for PHP 5.0, circa 2004-2005). Intriguingly, for systems that don’t provide PDO support (or the appropriate drivers for PDO), the MySQLi and PostgreSQL functions and classes have provided prepared statements for quite some time, and the SQLite 3 drivers have provided a prepare() method since PHP 5.3. Commercial bulletin boards, like vBulletin and IPB, have seen many revisions in the years since, and several free/open source packages including phpBB have been part of similarly major overhauls. Yet the overwhelming majority of them still make no use of prepared statements. Humorously, as of this writing, vBulletin does provide a misleadingly-named sql_prepare method in its database class, but it doesn’t emulate prepared statements–it simply provides an escape wrapper with data type introspection and casting.

PDO has been available for nearly 8 years and many RDBMS drivers for PHP have offered prepared statements for at least that long (longer in the case of PostgreSQL if memory serves correctly). Yet every year or two, new major versions of popular PHP message boards are released, and every major release sees the same legacy database code under the hood. Perhaps it’s intentional. Perhaps the developers still want to support PHP 4.x in spite of the fact that it went EOL in 2008. Perhaps they just don’t know any better. Who knows!

Why Prepared Statements?

A prepared statement or parameterized statement, as it is occasionally known by in DBA parlance, is a specially-formatted SQL string that utilizes placeholders, either question marks (?), special named parameters (such as “:name”), or other database-specific strings, to indicate to the database or the driver where data is to be inserted. This has the benefit that, in theory at least, any data managed by a prepared statement is unlikely to serve as a vector for SQL injection attacks. The reason this works is because most drivers dispatch the prepared statement and its data separately on the wire and process them independently providing a certain degree of isolation. But wait, there’s more! Because of the implementation nature of prepared statements on most platforms, the query planner can often optimize and partially compile the statement such that, if it runs again, much of the legwork has already been completed and the query can run faster. Software like forums or blogs often execute the same query multiple times–with different data–so one might think it would be a natural fit. If it’s such a good thing, why do so many popular packages forgo such a benefit?

While I can’t answer for many developers, I think I know what at least part of the answer might be. First, for enormous code bases like vBulletin (and phpBB to a lesser extent), virtually no effort is made to separate the application logic from the underlying model. I’ll be fair in my distinction: The presentation layer is thankfully separated from the mess in the form of templates, but the remaining code is a bowl of spaghetti not unlike that of many of the very first PHP applications (and Perl!) that first graced the Internet over a decade ago. Because the model (and, by extension, the SQL) is so deeply entrenched in the functional logic of the application, reworking it to use prepared statements–and consider, also, that many of these queries are generated programmatically–would be a tremendous undertaking of many man-hours. Cleaning up the code properly such that it is more of a structurally sound framework (think MVC) is most certainly out of the picture. It isn’t impossible, of course, but when you consider that some functions in many of these software packages have persisted since the dawn of time, such refactoring becomes the thing of fairy tales.

To illustrate some of my displeasure, vBulletin version 4.2 still provides an iif function which is little more than a wrapper for the ternary operator (?:) in PHP. The ternary operator has been around since at least PHP4, yet there it is, in all its glory, a legacy function still available from the early days of PHP3 when such a beast didn’t exist!

One might think that it would simply be a matter of adding some logging code to old function calls, tracing the source that called them, and then reworking the culprit code to use built in language features. It might even take less than an afternoon.

The Drawbacks Programmer Mistakes

While prepared statements (parameterized queries for those of you who are embarrassingly excited by more elaborate verbiage) aren’t a panacea (I did it again) for all things SQL injection-like, they’re a good mitigation strategy, but it’s important to use them with caution. As Jason Lam states on the ISC Diary, “I still remember 4-5 years ago when SQL injection just started to become popular, the common mitigation suggested [was] to use prepared statement [sic] as if [they were] a magic bullet. As we [now] understand the SQL injection problem better, we realize that even prepared statement can be vulnerable to SQL injection as well.”

Well, yeah. This is where I smack my forehead. Maybe I’m being overly critical as I re-read a post from 5 years ago, because I’ve had the tremendously good fortune of witnessing some magnificently terrible code in my time as a web application developer.

Mr. Lam goes on to explain the insertion of unchecked user input, but I can’t shake the feeling that there is an implicit overtone in the article that it is somehow the fault of prepared statements. Perhaps more accurately, the article is faulting most of us for having championed prepared statements as a welcome solution to a very common and widespread problem. Realistically, though, it’s not an issue with prepared statements–they work just fine. It’s an issue with developers inappropriately using the tools at their disposal and doing so in a manner that simply transfers the vulnerability from query() to prepare() by forgetting to properly manage incoming data. Though, I should say that I’m inclined to suggest that programmatically assembling a prepared statement is somewhat counter-productive. More on this later.

Ironically, while doing some research for this article, I ran across a couple of posts on Stack Overflow that presented this problem of unchecked user input as one of the primary drawbacks of prepared statements. Really? Drawbacks? If you’re not using named parameters or placeholders for your query data, you’re probably not using prepared statements correctly! But drawbacks? Gee, maybe we were a little too vigilant in telling people to use prepared statements–so much so that they did a find/replace for query and swapped it with prepare. (I’m being facetious; so, to head off any comments to the contrary, it’s not at all possible to simply swap some text, because prepared statements do require a little more work.)

The problem I have with labeling unchecked user input as a drawback of prepared statements is that it is no longer a “real” prepared statement whenever such data is concatenated with the resulting query. Yes, it is still a prepared statement, insofar as calling prepare() on the driver’s end, but it’s no longer being used like a prepared statement. Here’s a hint to new developers, particularly PHP developers since a huge percentage of them are guilty of doing stupid things like this: Never concatenate unchecked input in any query–prepared or otherwise. If you’re using a prepared statement, use it like a damned prepared statement. The moment you start piping data into the query string itself, it’s no longer going to have the benefits of a prepared statement. (I’ll give you a special exception if you’re using LIMIT and concatenating integers with your queries since not all of you may be running MySQL 5.0.7 or later.)

Will the Real Prepared Statement Please Step Forward?

In my mind, and trust me, it’s a very strange place in here, a prepared statement is one that may contain parameters and is “prepared” ahead of time for reuse (that is, compiled) by the driver or the RDBMS (usually the RDBMS). Nothing more, nothing less. The instant some unfiltered data is slapped on to the end of the query, it’s no longer a pure prepared statement; instead, it becomes a mistake. Again: Prepared statements are parameterized queries that are usually compiled by the backend for a little extra speed. A query can contain anything else that the programmer adds into it, but fundamentally, a prepared statement is something that dictates a very specific structure. It certainly cannot overcome the mistakes of a naive developer who, believing that a prepared statement will magically fix all of their (singular they, sorry linguistic purists) security-related woes, use such a tool in addition to dangerous techniques like concatenating unchecked input. Another way to look at it is thus: If prepared statements are prepared (that is, compiled) by the database for reuse, and the developer is concatenating a dynamic value to the statement, the entire benefit of preparing (compiling) that statement is immediately lost, because the RDBMS has to re-compile the statement every single time it’s sent along the wire. Please, don’t do this.

Of course, there may be reasons not to use prepared statements all the time. For one, prepared statements in MySQL versions prior to 5.1 can no longer be managed by the query cache which may impact performance (High Performance MySQL, 2nd ed., p229). DBMSs that don’t support prepared statements can, in PDO at least, can have them emulated by the PDO driver at the cost of some pre-processing performance, and using older PHP functions like the popular-but-now-deprecated mysql_* ones just outright don’t support anything but basic queries (they also don’t use the binary interface, making them somewhat slower). If you’re using only a single query with absolutely no intention of reusing it, prepared statements may incur some overhead since the query must be compiled. Furthermore, for MySQL at least, if you’re not using stored procedures, the database has no way to share compiled prepared statements among multiple connections. Yet, while a prepared statement is no substitute for caution–particularly with programmatically-generated queries–it is a useful tool in the developer’s arsenal to protect against attacks like SQL injection. Plus, if you make it a habit to use PDO (you should), not only do you get emulated prepared statements for databases that don’t support them, you also get to use the modern MySQL APIs under the hood and some consistency, which says a lot in the PHP world.

Tangentially, this is also why it boggles my mind that many sites (banks, news agencies, airlines, and even some game companies) limit what characters the user can enter for their password, and how so many companies with an online presence often have draconian limits of less than 16 characters, inclusive. Seriously: If you’re correctly storing a secure hash of the password (HMAC, bcrypt, scrypt, or at least SHA256 or similar), you don’t need to store the password directly, nor does it matter if the password is 5 or 500 characters. It’s going to be comprised of a fixed length of some limited set of ASCII characters representing hexadecimal numbers which can be stored without much fuss. The 1990s were over two decades away. I think it’s time we stopped writing code like Y2K is still a viable problem.

Also, let’s start using prepared statements a little more often.

As I mentioned early on in part one (you may read it here), comments like this are somewhat frequent on the “newbie” forum over at the Arch Linux forums, although the one I linked is probably the mildest of the lot. While they follow the same motif, they range from individuals voicing veiled frustration over the fact that Arch doesn’t seem to “work” like their favorite distro, that it requires too much effort, or that Debian/Ubuntu/<insert distro here> is so much easier (for some value of easy). Fortunately, the majority of these posts are filtered out quickly by the moderators and dealt with accordingly (see the “Topics Going Nowhere” forum for samples). It’s one of the reasons I love the Arch community–the wheat is separated from the chaff early on, and consequently, most of the threads that live beyond a day or two tend to be useful, interesting, or informative.

Now, fair warning: I’ll be illustrating my point with a fair amount of allegory. There are also a few rather broad generalizations ahead, and I’m aware of this. I also don’t address related issues like self-sustenance or the benefits of having broad, practical knowledge (I’ve always wanted to make my own cheese, for instance). This is intentional.

So, let’s begin.

The problem, fundamentally, is not one that’s endemic to any one Linux distro in particular. It’s actually a consequence of society coddling the fools and bringing up the helpless. Before you feel offended, let me clarify that I don’t mean to sound brash. It isn’t the fault of those who are helpless per se. An efficient, productive society creates specialized niches, and sooner or later there’s a threshold that’s crossed where it’s no longer possible for any one individual to know everything they need to know in order to function without outsourcing some of their daily activities.

I realize that the word “outsourcing” has developed exceedingly negative connotations recently, particularly in the US, but it’s the only term that fits. Outsourcing isn’t inherently wrong, nor is it evil. In fact, you might be surprised to learn that you do it all the time. When you go to the grocery store, you’re buying products that have essentially been outsourced for you: Rather than baking your bread, you outsource the baking to the store and exchange some currency for the finished product. Rather than farming your own wheat or milling your own flour, you purchased bagged flour at the store. An efficient society is one where the individual can focus on other tasks (like programming) instead of being overly concerned about day to day needs (such as growing food). An efficient society therefore approaches a point where individual specialization is such that we’re all “helpless” to a point. For example, I’m not particularly mechanically inclined and wouldn’t know where to begin to look to fix a car, but I have family and friends who often look to me for help with technical matters (or building their own systems). We outsource to each other. Put another way, you and I outsource our issues in areas where we lack the expertise or the domain specific knowledge to those who have it.

As I alluded to earlier, this sort of helplessness isn’t a bad thing. It’s the hallmark of a productive, efficient society. However, it’s also important to know and understand these individual limitations before embarking into areas where one lacks the required knowledge. Ignorance is a refusal to learn; arrogance is a refusal to listen. Unfortunately, ignorance and arrogance often play a part in some of the discussions I’ve seen, and it’s all too common that the two traipse around together causing mischief where there otherwise should be none.

The problem then is that the efficiency of society–of outsourcing–has created a clime where a certain subset of the population accumulates the mistaken belief that their problems are the fault of others who are unwilling to help them. They fail to understand the difference between outsourcing a product, such as bread, and voluntary efforts like Arch Linux which require the consumer to be his or her own navigator in seas uncharted. Perhaps the most sinister thing about this lack of understanding is that it’s not primarily cognitive–the consumer in this scenario fully understands that open source projects are largely staffed by volunteers–but it is a form of devious dissonance that leads them to behave as though they’re still outsourcing. It therefore expresses itself as a deep seated inability to make the correlation between F/OSS (Free/Open Source Software) and volunteer labor versus outsourcing and paid-for products. I won’t cover it further here, but if you’re interested in a much more lengthy discussion along these lines, it would behoove you to read the excellent article Linux is not Windows.

I should point out that it’s one thing to say “Help! I don’t have a clue what I’m doing! Can someone point me in the right direction?” but it’s another thing entirely to say “Help! I can’t get my favorite feature to work. It worked fine on my previous platform. Can yours not do this too?” The former expresses ignorance combined with a willingness to learn–this is a good thing, because it’s easily correctable. The latter combines both ignorance and arrogance, culminating in a distinct unwillingness to do research while placing the blame on those who would otherwise offer their help.

But I digress.

To continue: Because of the efficiency and specialization that our society encourages–another good thing–there are some individuals who therefore think that their problem is not their own. The “problem ownership” is then shifted, in their minds, to the people trying to help. This is exacerbated by those who refuse to do any legwork on their own, and it is this personality type that often leaves with unresolved problems and a certain level of anger.

What this means for Arch but not limited to Arch is that there’s always going to be some small number of people who aren’t necessarily willing to help themselves. The clueful ones may eventually acknowledge the error of their ways, apologize, and possibly redeem themselves after some embarrassment. Others are beyond redemption, and when they find their repeated inquiries for help are no longer wanted on the Arch forums, they’ll eventually become a bother to someone else.

However, I think that at least a small part of the problem stems from the evangelism we Arch users periodically exhibit. (Yes, I’m guilty of this.) Because we tout the benefits of rolling-release distros and the simplicity of Arch often without the appropriate warnings attached, newbie users hear these and immediately develop an unrealistic ideal of what Arch is (and can never be) and then project that into their pleas for help. On at least two occasions I’ve seen this develop, and the easiest way to spot these types are from remarks such as “Arch is supposed to be the best rolling-release distro, but I’ve never had these problems with ${other_distro} before!”

The best solution, of course, is to amend our evangelism with warnings like “Arch isn’t for everybody,” but I doubt that would work. We’re all aware that most people gloss over warnings (myself included) whenever a specific threshold of positive remarks is reached. If one’s mind is made up that the road is paved in gold, little attention will be paid to the sign that reads “there be dragons!”

The next best solution is to educate in addition to evangelizing. If you know someone who’s interested in Arch, point them to the forums and the wiki, but be sure to emphasize that Arch is a do-it-yourself distro. Educate interested souls on the merits of problem solving and figuring things out. (Bonus points if you link them to the late Richard Feynman’s book The Pleasure of Finding Things Out as a tongue-in-cheek gesture.) If your friend is someone who isn’t particularly interested in or adept at solving problems, Arch is very likely not the best match. That’s not to say they may not benefit from learning Arch, but you’ll likely save them (and yourself) from some frustration in the event of mismatched expectations.

I really like Arch Linux, and I’d love it if everyone I knew used it. I also think that’s an unrealistic expectation, because I know that not everyone finds enjoyment from the same things I do. If you’re considering using Arch, you need to be aware that you’re going to run into problems. The difficulty of the problems you’re likely to encounter will be determined by your relative skill; the more skilled you are, the easier a potential problem will be to solve. There will also come a time when an update may break the system, and you must be ready to spend an hour or more without access to a graphical environment (shell only). It also helps to familiarize yourself with chrooting Arch in the event you have to rescue your system from a live CD. You must also read the front page news articles prior to an update process, because important information about potentially breaking changes is posted there (if applicable). If this sounds like too much work, you may have to concede defeat. Arch may not be for you.