Fanboys

April 20th, 2011

Marco Arment has this to say:

fan•boy |ˈfanˌboi|

noun

  1. informal derogatory: a term used to describe people who bought a product that competes with the one you bought, which is probably more popular than your choice, for reasons that you wish to discredit or diminish because you’re secretly afraid or upset that you made the wrong choice.

ORIGIN from fan + boy.

Several things irritate me about this. For a start, the pretence that it is about anything other than Apple fanboyism. Does this definition apply to the Kirk vs. Picard debate? If my buddy says that GNU Hurd is better than Linux, and I say he’s a fanboy, is that because I’m secretly worried that Hurd might be a better OS kernel? Of course not, this is about Marco defending himself and others like him against their critics. Strip away the aura of objectivity and it’s just an ad hominem. Admittedly one aimed at defending against another ad hominem, but two wrongs don’t make a right.

Like it or not, fans exist. A lot of them are boys. Conflating the two into a convenient label might be lazy, but it seems prima facie to be a valid term.

But I think there’s a deeper meaning to the charge of fanboyism, and one that would leave us all slightly poorer if we were to attempt to excise the concept from our consciousness. The fact is, we’re very bad at basing our conclusions on the evidence. Much worse than we think we are. If you think you don’t have biases in your reasoning based on particular companies, ideas or causes you have a soft spot for then you’re probably deluding yourself. One particular facet of this is confirmation bias: the tendency to give more weight to evidence that supports the conclusions you already believe. It seems to me that this is pretty close to what we mean when we dismiss someone as a fanboy.

Accusing someone of fanboyism may be lazy, and it may be overused. But there’s a difference between the fallacy of ad hominem argument and a rational accusation that someone is suffering from confirmation bias. If Marco’s suggesting that the distinction doesn’t matter then he’s dead wrong.

Book review: Modern Cryptanalysis

April 5th, 2011

Modern Cryptanalysis: Techniques for Advanced Code Breaking

The lack of the market for books on cryptography might be viewed as surprising. Given that the market can sustain over 200 books about PHP, how has a topic as sexy as cryptography not got more than a dozen or so books? It’s like the world saw Schneier’s Applied Cryptography and figured there wasn’t any point trying.

This isn’t actually that unreasonable. Schneier’s book might be showing its age these days, but trying to keep up with the leading edge of research is a game for mugs and crypto researchers, and neither one is in need of a textbook. The rest of us just need a primer on the principles of cryptography that covers the major protocols and widely-used algorithms without dumbing down, and if that’s what you’re after then Applied Cryptography is still the first and last book that need be on your list.

It does have one major hole, and that’s in the coverage of cryptanalysis. Admittedly, cryptanalysis is even further from the everyday reality of most developers than cryptograpy is: attempting to implement crypto algorithms yourself is risky and requires care, but attempting your own cryptanalysis of any non-trivial algorithm is a pointless exercise best reserved for a really rainy day, or just left to the experts. But I can’t have been the only one who feels very dissatisfied at knowing that something can be done, but not knowing how.

On the face of it, Modern Cryptanalysis is pretty much exactly the book I’ve been looking for all these years. It starts from modest assumptions about background knowledge, but covers real military-grade algorithms. It has good step-by-step tutorials and illustrates it with usable source code in Python. It’s reasonably priced (though certainly not cheap), and picks a good range of topics to get a reasonable overview of the field while still being a manageable length overall.

However, it left me feeling frustrated. A little too much time is spent on toy algorithms that are only of historical interest and are well covered by other books. It then attempts to teach the most basic mathematical background before ploughing into weighty topics in number theory such as factorisation and elliptic curves. In general I feel that the information on public-key systems was too much and too soon in the book: you can’t analyse RSA without postgraduate-level number theory. By the same token, not enough time was spent on symmetric block ciphers for my liking, as to me they strike a nice balance of being a rich topic that doesn’t require too much mathematical background for the casual reader to benefit from it.

Perhaps it was my relatively hurried reading of it, but I didn’t feel the explanations were quite clear enough, particularly in explaining linear and differential cryptanalysis. This was exacerbated by an extremely large number of typos, some of which occurred in mathematical expressions and obscured the meaning of the text.

Despite my reservations, this book actually does the job you most likely require of a book on cryptanalysis, which is to demystify it and give enough of a flavour that you know whether you want to read further. It’s not a classic, but it’s a fair starting point.

Programming in the real world: US lawmakers cause infinite loop

March 31st, 2011

From The Economist’s Democracy in America blog, it appears the US House of Representatives needs to institute code reviews:

The bill, the Government Shutdown Prevention Act, declares that the House’s budget proposal (HR1) will become law if the Senate does not pass a budget to fund the federal government for the rest of the year before April 6th. House leadership seemed to have inadvertently ignored the fact that the phrase “become law” contains the concepts “has been passed by the House” and “has been passed by the Senate”. The implication of the measure’s language was that the Senate would pass the House’s budget if it did not pass a budget, or that if the Senate did not pass a budget then the Senate would have passed the House’s budget.

I’ve been saying this for some time: Writing complex rulesets is hard, if they are to be followed rigorously. It’s much harder than most people think. Programmers aren’t necessarily as much better at this kind of stuff as they’d like to think, but they do have the advantage of quick unambiguous feedback, which builds scar tissue. Mostly what experienced programmers know that others don’t is the importance of being circumspect.