NXP, which makes the Mifare transit cards used in several countries, has sued Radboud University Nijmegen (in the Netherlands), to block publication of a research paper, "A Practical Attack on the MIFARE Classic," that is scheduled for publication at the ESORICS security conference in October. The new paper reportedly shows fatal security flaws in NXP's Mifare Classic, which appears to be the world's most commonly used contactless smartcard.

I wrote back in January about the flaws found by previous studies of Mifare. After the previous studies, there wasn't much left to attack in Mifare Classic. The new paper, if its claims are correct, shows that it's fairly easy to defeat MIFARE Classic completely.

It's not clear what legal argument NXP is giving for trying to suppress the paper. There was a court hearing last week in Arnheim, but I haven't seen any reports in the English-language press. Perhaps a Dutch-speaking reader can fill in more details. An NXP spokesman has called the paper "irresponsible" but that assertion is hardly a legal justification for censoring the paper.

Predictably, a document purporting to be the censored paper showed up on Wikileaks, and BoingBoing linked to it. Then, for some reason, it disappeared from Wikileaks, though BoingBoing commenters quickly pointed out that it was still available in Google's cache of Wikileaks, and also at Cryptome. But why go to a leak-site? The same article has been available on the Web all along at arxiv, a popular repository of sci/tech research preprints run by the Cornell University library.

[UPDATE (July 15): It appears that Wikileaks had the wrong paper, though one that came from the same Radboud group. The censored paper is called "Dismantling Mifare Classic".]

As usual in these cases of censorship-by-lawsuit, it's hard to see what NXP is trying to achieve with the suit. The research is already done and peer-reviewed,. The suit will only broaden the paper's readership. NXP's approach will alienate the research community. The previous Radboud paper already criticizes NXP's approach, in a paragraph written before the lawsuit:

We would like to stress that we notified NXP of our findings before publishing our results. Moreover, we gave them the opportunity to discuss with us how to publish our results without damaging their (and their customers) immediate interests. They did not take advantage of this offer.

What is really puzzling here is that the paper is not a huge advance over what has already been published. People following the literature on Mifare Classic – a larger group, thanks to the lawsuit – already know that the system is unsound. Had NXP reacted responsibly to this previous work, admitting the Mifare Classic problems and getting to work on migrating customers to newer, more secure products, none of this would have been necessary.

You've got to wonder what NXP was thinking. The lawsuit is almost certain to backfire: it will only boost the audience of the censored paper and of other papers criticizing Mifare Classic. Perhaps some executive got angry and wanted to sue the university out of spite. Things can't be comfortable in the executive suite: NXP's failure to get in front of the Mifare Classic problems will (rightly) erode customers' trust in the company and its products.

UPDATE (July 18): The court ruled against NXP, so the researchers are free to publish. See Mrten's comment below.

On July 2nd, Viacom's lawsuit against Google's YouTube unit saw a significant ruling, potentially troubling for user privacy. Viacom asked for, and judge Louis L. Stanton ordered Google to turn over, the logs of each viewing of all videos in the YouTube database, showing the username and IP address of the user who was viewing the video, a timestamp, and a code identifying the video. The judge found that Viacom "need[s] the data to compare the relative attractiveness of allegedly infringing videos with that of non-infringing videos." The fraction of views that involve infringing video bears on Viacom's claim that Google should have vicarious copyright liability–if the infringing videos appear to be an important draw for YouTube users, this implies a financial benefit to Google from the infringement, which would weigh in favor of a claim of vicarious liability.

As Doug Tygar has observed, the judge's optimistic belief that disclosure of these logs won't harm privacy seems to be based in part on the conflicting briefs of the parties. Viacom, desiring the logs, told the judge that "the login ID is an anonymous pseudonym that users create for themselves when they sign up with YouTube" which without more data "cannot identify specific individuals." After quoting this claim and noting that Google did not refute it, the judge goes on to quote a Google employee's blog post arguing that "in most cases, an IP address without additional information cannot" identify a particular user.

Each of these claims–first, that the login IDs of users are anonymous pseudonyms, and second, that IP addresses alone don't suffice to identify individuals–is debatable. I haven't reviewed the briefs that led Judge Stanton to believe each of the assertions. I suppose that his conclusions are reasonable in light of the material presented. It might be the case that the briefs should have led him to a different conclusion. Then again, as the blog post quoted above suggests, Google has at times found itself downplaying the privacy risks associated with certain data. A victory in this argument, causing the judge to take a more expansive view of the possible privacy harms, might have been a mixed blessing for Google in the longer run.

In any case, when he combined the two claims to compel the turnover of the logs, the judge made a significant mistake of his own. Agreeing for the sake of argument that login IDs alone don't compromise privacy, and that IP addresses alone also don't compromise privacy, it doesn't follow that the two combined are equally innocuous. Earlier cases like the AOL debacle have shown us that information that may seem privacy-safe in isolation can be privacy-compromising when it is combined. The fact of combination–the fact that some viewing by a particular login ID happened at a certain IP address, and conversely that a viewing from a particular IP address occurred under the login of a particular user–is itself a potentially important further piece of information. If the judge thought about this fact–if he thought about the further privacy risk involved in the combination of IPs and login IDs–I couldn't find any evidence of such consideration in his ruling.

Google wants to be permitted to modify the data to reduce the privacy risk before handing it over to Viacom, but it's not yet clear what agreement if any the parties will reach that would do more to protect privacy that Judge Stanton's ruling requires. It's also not yet apparent exactly how the judge's protective order will be constructed. But if the logs are turned over unaltered, as they may yet be, the result could be significant risk: YouTube's users would then face extreme privacy harm in the event that the data were to leak from Viacom's possession.

[As always, this post is the opinion of the author (David Robinson) only.]

Our research on cold boot attacks on disk encryption has generated lots of interesting discussion. A few misconceptions seem to be floating around, though. I want to address one of them today.

As we explain in our paper, laptops are vulnerable when they are "sleeping" or (usually) "hibernating". Frequently used laptops are almost always in these states when they're not in active use – when you just close the lid on your laptop and it quiets down, it's probably sleeping.

When a laptop goes to sleep, all of the data that was in memory stays there, but the rest of the system is shut down. When you re-open the lid of the laptop, the rest of the system is activated, and the system goes on running, using the same memory contents as before. (Hibernating is similar, but the contents of memory are copied off to the hard drive instead, then brought back from the hard drive when you re-awaken the machine.) People put their laptops to sleep, rather than shutting them down entirely, because a sleeping machine can wake up in seconds with all of the programs still running, while a fully shut-down machine will take minutes to reboot.

Now suppose an attacker gets hold of your laptop while it is sleeping, and suppose the laptop is using disk encryption. The attacker can take the laptop back to his lair, and then open the lid. The machine will reawaken, with the same information in memory that was there when you put the machine to sleep – and that information includes the secret key that is used to encrypt the files on your hard disk. The machine may be screen-locked – that is, it may require entry of your password before you can interact with the desktop – but the attacker won't care. All he cares about is that the encryption key is in memory.

The attacker will then insert a special thumb drive into the laptop, yank out the laptop's battery, quickly replace the battery, and push the power button to reboot the laptop. The encryption key will still be in memory – the memory will not have lost its contents because the laptop was without power only momentarily while the battery was out. It doesn't matter how long the laptop takes to reboot, because the memory contents are fading only momentarily while the battery is out. When the laptop boots, software from the thumb drive will read the contents of memory, find the secret encryption key, and proceed to unlock the encrypted files on your hard drive.

In short, the adversary doesn't need to capture your laptop while the laptop is open and in active use. All he needs is to get your laptop while it is sleeping – which it is probably doing most of the time.

Last week, Comcast offered a defense in the FCC proceeding challenging the technical limitations it had placed on BitTorrent traffic in its network. (Back in October, I wrote twice about Comcast's actions.)

The key battle line is whether Comcast is just managing its network reasonably in the face of routine network congestion, as it claims, or whether it is singling out certain kinds of traffic for unnecessary discrimination, as its critics claim. The FCC process has generated lots of verbiage, which I can't hope to discuss, or even summarize, in this post.

I do want to call out one aspect of Comcast's filing: the flimsiness of its technical argument.

Here's one example (p. 14-15).

As Congresswoman Mary Bono Mack recently explained:

The service providers are watching more and more of their network monopolized by P2P bandwidth hogs who command a disproportionate amount of their network resources. . . . You might be asking yourself, why don’t the broadband service providers invest more into their networks and add more capacity? For the record, broadband service providers are investing in their networks, but simply adding more bandwidth does not solve [the P2P problem]. The reason for this is P2P applications are designed to consume as much bandwidth as is available, thus more capacity only results in more consumption.

(emphasis in original). The flaws in this argument start with the fact that the italicized segment is wrong. P2P protocols don't aim to use more bandwidth rather than less. They're not sparing with bandwidth, but they don't use it for no reason, and there does come a point where they don't want any more.

But even leaving aside the merits of the argument, what's most remarkable here is that Comcast's technical description of BitTorrent cites as evidence not a textbook, nor a standards document, nor a paper from the research literature, nor a paper by the designer of BitTorrent, nor a document from the BitTorrent company, nor the statement of any expert, but a speech by a member of Congress. Congressmembers know many things, but they're not exactly the first group you would turn to for information about how network protocols work.

This is not the only odd source that Comcast cites. Later (p. 28) they claim that the forged TCP Reset packets that they send shouldn't be called "forged". For this proposition they cite some guy named George Ou who blogs at ZDNet. They give no reason why we should believe Mr. Ou on this point. My point isn't to attack Mr. Ou, who for all I know might actually have some relevant expertise. My point is that if this is the most authoritative citation Comcast can find, then their argument doesn't look very solid. (And, indeed, it seems pretty uncontroversial to call these particular packets "forged", given that they mislead the recipient about (1) which IP address sent the packet, and (2) why the packet was sent.)

Comcast is a big company with plenty of resources. It's a bit depressing that they would file arguments like this with the FCC, an agency smart enough to tell the difference. Is this really the standard of technical argumentation in FCC proceedings?

Last week an anonymous person published a file containing half a million images, many of which had been gathered from private profiles on MySpace. This may be the most serious privacy breach yet at MySpace. Kevin Poulsen's story at Wired News implies that the leak may have been deliberate payback for MySpace failing to fix the vulnerability that allowed the leaks.

"I think the greatest motivator was simply to prove that it could be done," file creator "DMaul" says in an e-mail interview. "I made it public that I was saving these images. However, I am certain there are mischievous individuals using these hacks for nefarious purposes."

The MySpace hole surfaced last fall, and it was quickly seized upon by the self-described pedophiles and ordinary voyeurs who used it, among other things, to target 14- and 15-year-old users who'd caught their eye online. A YouTube video showed how to use the bug to retrieve private profile photos. The bug also spawned a number of ad-supported sites that made it easy to retrieve photos. One such site reported more than 77,000 queries before MySpace closed the hole last Friday following Wired News' report.

...

MySpace plugged a a href="http://grownupgeek.blogspot.com/2006/08/myspace-closes-giant-security-hole.html">similar security hole in August 2006 when it made the front page of Digg, four months after it surfaced.

The implication here, not quite stated, is that DMaul was trying to draw attention to the flaw in order to force MySpace to fix it. If this is what it took to get MySpace to fix the flaw, this story reflects very badly on MySpace.

Anyone who has discovered security flaws in commercial products knows that companies react to flaws in two distinct ways. Smart companies react constructively: they're not happy about the flaws or the subsequent PR fallout, but they acknowledge the truth and work in their customers' interest to fix problems promptly. Other companies deny problems and delay addressing them, treating security flaws solely as PR problems rather than real risks.

Smart companies have learned that a constructive response minimizes the long-run PR damage and, not coincidentally, protects customers. But some companies seem to lock themselves into the deny-delay strategy.

Now suppose you know that a company's product has a flaw that is endangering its customers, and the company is denying and delaying. There is something you can do that will force them to fix the problem – you can arrange an attention-grabbing demonstration that will show customers (and the press) that the risk is real. All you have to do is exploit the flaw yourself, get a bunch of private data, and release it. Which is pretty much what DMaul did.

To be clear, I'm not endorsing this course of action. I'm just pointing out why someone might find it attractive despite the obvious ethical objections.

The really interesting aspect of Poulsen's article is that he doesn't quite connect the dots and say that DMaul meant to punish MySpace. But Poulsen is savvy enough that he probably wouldn't have missed the implication either, and he could have written the article to avoid it had he wanted to. Maybe I'm reading too much into the article, but I can't help suspecting that DMaul was trying to punish MySpace for its lax security.

Radiohead's name-your-own-price sale of its new In Rainbows album has generated lots of commentary, especially since comscore released data claiming that 62% of customers set their price at zero, with the remaining 38% setting an average price of $6, which comes to an average price of $2.28 per customer. (There are reasons to question these numbers, but let's take them as roughly accurate for the sake of argument.)

Bill Rosenblatt bemoaned the low price, calling it a race to the bottom. Tim Lee responded by pointing out that Rosenblatt's "race to the bottom" is just another name for price competition, which is hardly a sign of an unhealthy market. The music market is more competitive than before, and production costs are lower, so naturally prices will go down.

But there's another basic economic point missing in this debate: Lower average price does not imply lower profit. Radiohead may well be making more money because the price is lower.

To see why this might be true, imagine that there are 10 customers willing to pay $10 for your album, 100 customers willing to pay only $2, and 1000 customers who will only listen if the price is zero. (For simplicity assume the cost of producing an extra copy is zero.) If you price the album at $10, you get ten buyers and make $100. If you price it at $2, you get 110 buyers and make $220. Lowering the price makes you more money.

Or you can ask each customer to name their own price, with a minimum of $2. If all customers pay their own valuation, then you get $10 from 10 customers and $2 from 100 customers, for a total of $300. You get perfect price discrimination – each customer pays his own valuation – which extracts the maximum possible revenue from these 110 customers.

Of course, in real life some customers who value the album at $10 will name a price of $2, so your revenue won't reach the full $300. But if even one customer pays more than $2, you're still better off than you'd be with any fixed price. Your price discrimination is imperfect, but it's still better than not discriminating at all.

Now imagine that you can extract some nonzero amount of revenue from the customers who aren't willing to pay at all, perhaps because because listening will make them more likely to buy your next album or recommend it to their friends. If you keep the name-your-own-price deal, and remove the $2 minimum, then you'll capture this value because customers can name a price of zero. Some of the $10-value or $2-value people might also name a price of zero, but if not too many do so you might be better off removing the minimum and capturing some value from every customer.

If customers are honest about their valuation, this last scenario is the most profitable – you make $300 immediately plus the indirect benefit from the zero-price listeners. Some pundits will be shocked and saddened that your revenue is only 27 cents per customer, and 90% of your customers paid nothing at all. But you won't care – you'll be too busy counting your money.

Finally, note that none of this analysis depends on any assumptions about customers' infringement options. Even if it were physically impossible to make infringing copies of the album, the analysis would still hold because it depends only on how badly customers want to hear your music and how likely they are to name a price close to their true valuation. Indeed, factoring in the possibility of infringement only strengthens the argument for lowering the average price.

By all accounts, Radiohead's album is a musical and financial success. Sure, it's a gimmick, but it could very well be a smart pricing strategy.

Wednesday was the kickoff meeting of the Commission on Cyber Security for the 44th Presidency, of which I am a member. The commissionhas thirty-four members and has four co-chairs: Congressmen Jim Langevin and Michael McCaul, Admiral Bobby Inman, and Scott Charney. It was organized by the Center for Strategic and International Studies, a national security think tank in Washington. Our goal is to provide advice about cyber-security policy to the next presidential administration. Eventually we'll produce a report with our findings and recommendations.

I won't presume to speak for my fellow members, and it's way too early to predict the contents of our final report. But the meeting got me thinking about what government can do to improve cyber-security. I'll offer a few thoughts here.

One of the biggest challenges comes from the broad and porous border between government systems and private systems. Not only are government computers networked pervasively to privately-owner computers; but government relies heavily on off-the-shelf technologies whose characteristics are shaped by the market choices of private parties. While it's important to better protect the more isolated, high-security government systems, real progress elsewhere will depend on ordinary technologies getting more secure.

Ordinary technologies are designed by the market, and the market is big and very hard to budge. I've written before about the market failures that cause security to be under-provided. The market, subject to these failures, controls what happens in private systems, and in practice also in ordinary government systems.

To put it another way, although our national cybersecurity strategy might be announced in Washington, our national cybersecurity practice will be defined in the average Silicon Valley cubicle. It's hard to see what government can do to affect what happens in that cubicle. Indeed, I'd judge our policy as a success if we have any positive impact, no matter how small, in the cubicle.

I see three basic strategies for doing this. First, government can be a cheerleader, exhorting people to improve security, convening meetings to discuss and publicize best practices, and so on. This is cheap and easy, won't do any harm, and might help a bit at the margin. Second, government can use its purchasing power. In practice this means deliberately overpaying for security, to boost demand for higher-security products. This might be expensive, and its effects will be limited because the majority of buyers will still be happy to pay less for less secure systems. Third, government can invest in human capital, trying to improve education in computer technology generally and computer security specifically, and supporting programs that train researchers and practitioners. This last strategy is slow but I'm convinced it can be effective.

I'm looking forward to working through these problems with my fellow commission members. And I'm eager to hear what you all think.

The New York Times Sunday Magazine has a fascinating piece that interviews and discusses Columbia Records' hiring of Rick Rubin as their new studio chieftain. Rubin has been a well-known music producer (among other things, he orchestrated the famous mash-up of Aerosmith and Run-DMC and worked with Johnny Cash later in his life), and is quoted in the article saying many things that Freedom-to-Tinker readers will find familiar.

<!–more–>For example, on DRM and spyware:

By the time [Columbia executive] Barnett first approached Rubin about coming to Columbia, Rubin had already decided that he would have nothing more to do with Columbia Records. This was because of the company's handling of the Rubin-produced Neil Diamond record "12 Songs" in 2005. Diamond was a hero of Rubin's, and he spent two years working on the album, persuading Diamond to record acoustically, something he hadn't done since the '60s.

"The CD debuted at No. 4," Rubin told me at Hugo's, still sounding upset. "It was the highest debut of Neil's career, off to a great start. But Columbia — it was some kind of corporate thing — had put spyware on the CD. That kept people from copying it, but it also somehow recorded information about whoever bought the record. The spyware became public knowledge, and people freaked out. There were some lawsuits filed, and the CD was recalled by Columbia. Literally pulled from stores. We came out on a Tuesday, by the following week the CD was not available. Columbia released it again in a month, but we never recovered. Neil was furious, and I vowed never to make another album with Columbia."

Still, Columbia managed to hire this guy and he's now pretty much running the show. He thoroughly acknowledges that the music industry's real problem is that its former business model isn't going to work in the future and the solution is about completely changing the pricing model to be cheap enough and the quality of service to be good enough that piracy will no longer be rational for consumers.

Rubin has a bigger idea. To combat the devastating impact of file sharing, he, like others in the music business (Doug Morris and Jimmy Iovine at Universal, for instance), says that the future of the industry is a subscription model, much like paid cable on a television set. "You would subscribe to music," Rubin explained, as he settled on the velvet couch in his library. "You'd pay, say, $19.95 a month, and the music will come anywhere you'd like. In this new world, there will be a virtual library that will be accessible from your car, from your cellphone, from your computer, from your television. Anywhere. The iPod will be obsolete, but there would be a Walkman-like device you could plug into speakers at home. You'll say, 'Today I want to listen to ... Simon and Garfunkel,' and there they are. The service can have demos, bootlegs, concerts, whatever context the artist wants to put out. And once that model is put into place, the industry will grow 10 times the size it is now."

...

Rubin sees no other solution. "Either all the record companies will get together [for a unified subscription model] or the industry will fall apart and someone like Microsoft will come in and buy one of the companies at wholesale and do what needs to be done," he said. "The future technology companies will either wait for the record companies to smarten up, or they'll let them sink until they can buy them for 10 cents on the dollar and own the whole thing."

I've always thought that something like this could be a successful business model. Of course, enforcing such a scheme (i.e., ensuring that the music dries up if you don't keep spending your cash) requires a DRM strategy, which clearly isn't going to fly.  Is there an alternative?  How good would a music service have to be that you would have no incentive to store local copies? If I'm totally comfortable keeping my email and calendar "out there" on the Internet, why shouldn't I be comfortable keeping my CD collection (1500+ and growing) out there as well?

The article goes on to quote other industry experts on the difficulties of getting a subscription model correct, but I have to admire Rubin on his focus:

"I don't want to waste time," he said, sounding a little frustrated. "The existing people will either get smart, which is a question mark. Or new people will understand what a resource the music business is and change it without us." Rubin paused. "I don't want to watch that happen."

It's hard to argue with that. The primary focus of the article was on how Rubin is all about refining and polishing the music, and it's great to know that somebody like that will help bring out the best in our artists. I just hope they can really sort out this whole business model thing in a technologically feasible fashion. My fear is that yet another new snake-oil company with yet another DRM scheme will promise to "solve" the piracy problem, when we all know that the real solution lies instead in completely rethinking the business model. Make the price cheap enough and the quality of the service compelling enough, and people will prefer it to the hit-or-miss world of piracy.  Let's hope it can be a hit.  (Until then, I'll stick with buying CDs.)

Last week Skype, the popular, free Net telephony service, was unavailable for a day or two due to technical problems. Failures of big systems are always interesting and this is no exception.

We have only limited information about what went wrong. Skype said very little at first but is now opening up a little. Based on their description, it appears that the self-organization mechanism in Skype's peer-to-peer network became unstable. Let's unpack that to understand what it means, and what it can tell us about systems like this.

One of the surprising facts about big information systems is that the sheer scale of a system changes the engineering problems you face. When a system grows from small to large, the existing problems naturally get harder. But you also see entirely new problems that didn't even exist at small scale – and, worse yet, this will happen again and again as your system keeps growing.

Skype uses a peer-to-peer organization, in which the traffic flows through ordinary users' computers rather than being routed through a set of central servers managed by Skype itself. The advantage of exploiting users' computers is that they're available at no cost and, conveniently, there are more of them to exploit when there are more users requesting service. The disadvantage is that users' computers tend to reboot or go offline more than dedicated servers would.

To deal with the ever-changing population of user computers, Skype has to use a clever self-organization algorithm that allows the machines to organize themselves without relying (more than a tiny bit) on a central authority. Self-organization has two goals: (1) the system must respond quickly to changed conditions to get back into a good configuration soon, and (2) the system must maintain stability as conditions change. These two goals aren't entirely contradictory, but they are at least in tension. Responding quickly to changes makes it difficult to maintain stability, and the system must be engineered to make this tradeoff wisely in a wide range of conditions. Getting this right in a huge P2P system like Skype is tricky.

Which brings us to the story of last week's failure, as described by Skype. On Tuesday August 14, Microsoft released a new set of patches to Windows, according to their normal monthly cycle. Many Windows machines downloaded the patch, installed it, and then rebooted. Each such machine would leave the Skype network when it shut down, then rejoin after booting. So the effect of Microsoft's patch release was to increase the turnover in Skype's network.

The result, Skype says, is that the network became unstable as the respond-quickly mechanism outran the maintain-stability mechanism; and the problem snowballed as the growing instability caused ever stronger (but poorly aimed) responses. The Skype service was essentially unavailable for a day or two starting on Thursday August 16, until the company could track down the problem and fix a code bug that it said contributed to the problem.

The biggest remaining mystery is why the problem took so long to develop. Microsoft issued the patch on Tuesday, and Skype didn't get into deep trouble until Thursday. We can explain away some of the delay by noting that Windows machines might take up to a day to download the patch and reboot, but this still means it took Skype's network at least a day to melt down. I'd love to know more about how this happened.

I would hesitate to draw too many broad conclusions from a single failure like this. Large systems of all kinds, whether centralized or P2P, must fight difficult stability problems. When a problem like this does occur, it's a useful natural experiment in how large systems behave. I only hope Skype has more to say about what went wrong.

Exploiting Online Games, a book by Gary McGraw and Greg Hoglund, is being released today. The book talks concretely about security problems and attacks on online games. This is a fascinating laboratory for exploring security issues.

I wrote the book's foreword. Here it is:

It's wise to learn from your mistakes. It's wiser still to learn from the mistakes of others. Too often, we in the security community fail to learn from mistakes because we refuse to talk about them or we pretend they don't exist.

This book talks frankly about game companies' mistakes and their consequences. For game companies, this is an opportunity to learn from their own mistakes and those of their peers. For the rest of us, it's an opportunity to learn what can go wrong so we can do better.

The debate over full disclosure goes back a long way, so there is no need to repeat the ethical and legal arguments we have all heard before. For most of us in the security community, the issue is simple: Experts and the general public both benefit from learning about the technologies that they depend on.

In today's world, we are asked all the time to bet our money, our time, our private information, and sometimes our lives on the correct functioning of technologies. Making good choices is difficult; we need all the help we can get.

In some fields, such as aviation security, we can be confident that problems will be identified and addressed. Nobody would tolerate an aircraft vendor hiding the cause of a crash or impeding an investigation. Nor would we tolerate a company misleading the public about safety or claiming there were no problems when it knew otherwise. This atmosphere of disclosure, investigation, and remediation is what makes air travel so safe.

In game design, the stakes may not be as high, but the issues are similar. As with aviation, the vendors have a financial stake in the system's performance, but others have a lot at stake, too. A successful game – especially a virtual world like World of Warcraft – generates its own economy, in several senses. Objects in the game have real financial value, and a growing number of people make their living entirely or partially via in-game transactions. In-world currency trades against the dollar. Economists argue about the exact GDP of virtual worlds, but by any meaningful definition, virtual economies are just as "real" as the NASDAQ stock exchange.

Even nonplayers can have a lot at stake: the investor who bets his retirement account on a game company, the programmer who leaves a good job to work on a game, the family that owns the Indian restaurant across the street from the game company's headquarters. These people care deeply about whether the technology is sound. And would-be customers, before plunking down their hard-earned money for game software or a monthly subscription, want to know how well a game will stand up to attack.

If aviation shows us the benefits of openness, e-voting illustrates the harms caused by secrecy. We, the users of e-voting systems – citizens, that is – aren't allowed to know how the machines work. We know the machines are certified, but the certification process is itself shrouded in mystery. We're told that the details aren't really our concern. And the consequences are obvious: Designs are weak, problems go unfixed for years, and progress is slow. Even when things do go wrong in the field, it's very hard to get a vigorous investigation.

The virtue of this book is not only that it talks about real-world problems but also that it provides details. Some security problems exist only in theory but evaporate when real systems are built. Some problems look serious but turn out not to be a big deal in practice. And some problems are much worse than they look on paper. To tell the difference, we need to dig into the details. We need to see precisely how an attack would work and what barriers the attacker has to get over. This book, especially the later chapters, offers the necessary detail.

Because it touches on the popular, hot topic of massively multiplayer games, and because it offers both high-level and detailed views of game security, this book is also a great resource for students who want to learn how security really works. Theory is a valuable tool, but it does its best work when wielded by people with hands-on experience. I started out in this field as a practitioner, trying to learn how to get things done and how real systems behaved, before expanding my horizon to include formal computer science training. I suspect that many senior figures in the field would say the same. When I started out, books like this didn't exist (or if they did, I didn't know about them). Today's students are luckier.

Perhaps some vendors will be unhappy about this book. Perhaps they will try to blame the authors for the insecurity of their game software. Don't be fooled. If we're going to improve our security practices, frank discussions like the ones in this book are the only way forward. Or as the authors of this book might say, when you're facing off against Heinous Demons of Insecurity, you need experienced companies, not to mention a Vorpal Sword of Security Knowledge.

We all make mistakes. Let's learn from our mistakes and the mistakes of others. That's our best hope if we want to do better next time.