Apple iMessage “censors” mention of Obama: international conspiracy…or software bug?

If you like conspiracy theories, you’ll love the latest stories going around about Apple iMessage.

The conspiracy, sorry, issue actually first hit the techies’ airwaves late last year.

It’s recently been revived in a politically intriguing form.

It goes like this: try sending the message I could be the next Obama[space] via the iMessage service from your iPhone or your iPad. (Replace [space] with a ” ” obviously)

The last word will be cut off!

And not just any last word: the George Bushes, for example, survive the privations of iMessage; so do Clinton, Reagan, and even William Henry Harrison.

Old Tippecanoe, as Harrison was known, was the shortest serving US president, cut down by pneumonia after just 32 days at the helm, but he doesn’t get cut short by iMessage.

Apparently, even natural born Americans can’t be the next Obama, or at least can’t tell anyone that they could be, at least while they’re iOS users.

Here’s natural born earthling and intrepid Naked Security researcher Graham Cluley trying it out:

You’ll have to take my word for it. He really was trying to say that he could be the next Obama, but couldn’t.

It’s not censorship, of course, nor anything conspiratorial, nor even an Easter Egg, as some people have speculated.

Software Easter Eggs are unexpected messages or features, intended to amuse, that turn up under unlikely conditions.

Although many Easter Eggs might be reasonably be considered “mostly harmless,” and some are indeed both fascinating and witty, they’re certainly best avoided in messaging software, or at least in the parts of messaging software that actually speak on your behalf.

Actually, and I hate to be the killjoy who brings you this news, Easter Eggs are probably best avoided altogether these days, especially if they are complex. (Microsoft’s Excel 97 included a hidden flight simulator!)

That’s because Easter Eggs are, pretty much by definition, little tested and under-scrutinised.

Those are two characteristics that modern software can do without now that vulnerabilities and exploits have commercial value and are actively sought by Good Guys and Bad Guys alike.

Anyway, you may stand down from puce alert.

The missing Obamas are caused by a good, old-fashioned bug.

Keen observers have noticed that if you cut-and-paste from the offending message bubble, you get your Obama back.

The most credible explanation I’ve seen is that is that the code that presents the message reckons that it will just fit on one line, and prepares a one-line bubble for the purpose.

But the code that actually formats the message reckons that it won’t quite fit on one line, and thus renders it with the last word on a second line.

In short, the word Obama is there; you just can’t see it.

You can imagine how this might happen: a bug that’s a relative of what’s called an off-by-one or fencepost error, because a fence that is X sections long actually needs X+1 fenceposts to finish it off.

Here’s a visual example of this sort of programming mistake:

/* Is this a one-line case? */
if (pixelsize(msg) <= pixelsononeline) {
   specialonelinemessage(msg);
}
. . .
/* Later, processing the message */
if (pixelsize(msg) >= pixelsononeline) {
   multilinerender(msg);
}

The two comparisons have a nasty discrepancy.

The first considers it a single-line message if it’s no longer than number of pixels available on one line.

The second test looks very similar, but expressed the other way around: it’s checking that the message won’t fit on one line instead of that it does.

But the opposite of “less than or equal to” is “greater than,” not “greater than or equal to.”

In our synthetic example, only a message that is exactly the same pixel length as a line will be treated differently by the two code fragments and trigger the bug; all other messages will be handled correctly.

By the way, that’s one reason why software testing is hard.

In this case, for example, it isn’t enough just to test lots of different messages of randomly-varying length; you also need a structured test where you generate and test messages at all possible pixel lengths.

It may not seem important here, but in code that manages memory, off-by-one errors often lead to buffer overflows, and those sometimes lead to exploits.

So, if you’re a software engineering manager and you do get to be the next Obama, consider trying to persuade Congress to offer some sort of tax relief to the QA guys!