Blayne Sucks

I was going to wait until Dan Kaminsky announced more details about this flaw at the Black Hat Briefings on August 6th, but Halver Flake’s recent post as essentially squeezed the toothpaste out of the tube on this one. Just look at what Dan has to say.

I’m not going to talk about Dan’s decision not to release the details of this attack as soon as possible or the merits of full disclosure in computer security. Although interesting, it is less interesting to me than the flaw itself.

I know not everyone who reads this blog is technically oriented. To those people, I encourage you to try and make your way through this (long) post. I will try to keep things as simple as possible and I can guarantee you that a better understand of this particular problem will not only give you a better understanding of computer security, but also a better understanding of how the Internet really works.

Let me take a few moments to provide some background. The Domain Name System (DNS) is the protocol that translates a website’s domain name (e.g. somebank.com) into the corresponding IP Address (e.g. 192.168.1.1). IP Addresses are used by routers and network infrastructure to deliver information from one place to another on the Internet. DNS has been around since the mid 1980′s. It is a critical part of the infrastructure of the Internet. When you type in a domain name or use a bookmark to visit your bank’s website, you are trusting that the DNS protocol will take you to the correct server and not to a well-designed phishing website that looks just like your real bank.

The recent flaw in DNS is a protocol-level design flaw, not a software bug. A protocol is merely a pre-defined set of steps done to achieve some objective. For example, when Alice introduces two of her friends, Bob and Chris, to one another for the first time, she would follow a social protocol of introduction. She may introduce Bob to Chris as her co-worker from the Human Resources department, and she may follow this by immediately introducing Chris to Bob as her friend from church. If Alice forgot to introduce Bob to Chris and Bob eventually had to introduce himself to Chris while Alice was standing there, then that failure on Alice’s part is analogous to a failure in a single piece of software. If there were a flaw in this protocol, then every introduction performed based on this social protocol would fail. That is the difference between a protocol-level flaw and a software bug.

Now we have gotten to the crux of the issue. There is a protocol-level flaw in DNS that allows a phisher to take over the actual domain name of the site that it is trying to imitate. This is a serious problem that led to an astonishing collaboration to patch the entire Internet. Even patching the entire Internet isn’t going to “solve” this problem. Why? Because the patches are just that: patches. The problem still exists in the protocol.

What exactly is this problem? (And here’s where I may lose anyone who’s not technically oriented, but I’ll try and keep this simple.) When a DNS server doesn’t know how to translate a domain name into an IP address, it asks another, more trusted, DNS server for the information. Of course, this happens quite frequently since any given DNS server can’t store all the correct DNS translations for the entire Internet all the time (and since these translations can change).

Each time a DNS server has to ask a more trusted DNS server for a domain name to IP address translation, it does so by providing a number called a Query ID (QID). Now, there used to be a ton of attacks based on these QID since they were sequential. This class of attacks basically consisted of an evil doer asking a DNS server to perform a translation on a domain name that it didn’t already have. The evil doer would then start sending forged responses with sequentially increasing QIDs. If the evil doer got the right one, a bad domain name to IP address would be cached. Once a translation is cached, most DNS software implementations will ignore other updates to that domain’s information.

There are many ways to poison a DNS cache. This particular problem was patched (not solved) by just not using sequential QIDs. If a random QID is used, then it becomes very difficult for the evil doer to respond before the real response arrives.

Another interesting way to poison a DNS cache is to send a fake resource record. This attack works because of a chicken-ad-the-egg problem that I deftly avoided in my earlier description of DNS. I said that when a DNS server doesn’t know the proper translation for a domain name, it asks a more trusted DNS server. How? How does it know a more trusted DNS server? Basically, it only knows trusted DNS servers by their domain name. So it has to resolve a domain name for the next step in the hierarchy. Let me give a simple example.

Let’s say you’re a DNS server trying to resolve checking.somebank.com and you don’t know how. Who are you going to ask? Well, you’re going to ask whatever domain name server is controlling somebank.com since somebank.com is the next step in the hierarchy. If you don’t know that one, you’re going to ask the .com root server. Of course, you would like to learn how to ask somebank.com how to resolve all of it’s subdomains (e.g. checking.somebank.com, savings.somebank.com, etc…) since that would be efficient. This is done through a DNS Resource Record (RR).

Although there are many kinds of DNS Resource Records, for this attack all you need to know is that when you make a query for a DNS translation, you can receive back an answer as well as an additional resource record that is intended to help speed up future queries. Now, it used to be possible to poison DNS caches directly with this because there was a flaw in the protocol that allowed these resource records to be totally unrelated to the original request.

For example, let’s say you’re a DNS server and you just sent out a query about checking.somebank.com. It used to be possible that you would receive a domain name to IP address translation for checking.somebank.com and an addition resource record telling you that you should cache ns.evildoer.com as a name server for future queries. This was patched (not “solved”) by requiring the additional resource records be related to the query. (Thus, you would only be able to get a DNS RR for a somebank.com name server.)

The most recent DNS protocol-level flaw is related to both the QID problem and the DNS RR problem. Here’s how I believe it works (and these details are already available to anyone with access to google and a few minutes):

1. Get a DNS server to look up a subdomain for the site that you want to compromise. For example, randomAAAAAA.somebank.com. The subdomain itself doesn’t really matter other than it shouldn’t exist.
2. Since the DNS server doesn’t have this domain name to IP address translation it will have to look up the answer. Now, the evil doer can’t reliably predict the QID since random QIDs are used. The vast majority of these lookups will correctly be answered by ns.somebank.com as non-existent subdomains with the right QID. However, the evil doer can still try and race ns.somebank.com to guess an answer.
3. The evil doer repeats step 2 and increments the random domain name every time. For example, the next domain name the evil doer might try could be randomAAAAAB.somebank.com. Since QIDs are just randomized and not cryptographically secure, the attacker may still have a mathematically reasonable chance at eventually guessing correctly and beating the real name server’s response. If that happens, then the real name server’s response is dropped and more importantly the attacker has earned the right to send a DNS Resource Record updating the name server for the bank. (i.e. The attacker gets to poison ns.somebank.com and make it point to their phishing site.)

It’s clever. It’s not easy to solve, so we’re going to play the patching game again and people are rushing to patch their DNS servers. Now, this post is not going to talk about the losing battle that is penetrate-and-patch. Although it would be fun to rant, that debate is no longer interesting since all the smart people are on the same team.

So why is the flaw (and perhaps computer security on the whole) interesting? The assumptions involved. Professor Spafford has a great quote about computer security and assumptions:

Finding vulnerabilities is simple; discover the assumptions a developer made, ad then violate those assumptions.

People have become accustomed to DNS working. They assume it will work. It’s not just users, but also developers that do this. Let’s take one example: OpenID.

For those who don’t know, OpenID is an identity system that enables users to store their identity information in one place. Instead of having usernames, passwords, addresses, and other account information stored separately at amazon.com, ebay.com, flickr.com, etc…, users would be able to store it (and update it) all in one place. It’s a really neat idea that could eventually provide useful services and save real people time. However, it was designed with the assumption that DNS just worked.

Kim Cameron points this out on his blog, but I think the best summary of the problem is by Tim Anderson:

Note that Cameron is not opposed to OpenID. Apart from anything else, he recognizes that this may well be the beginning of an identity revolution – part of a process, at the end of which we get a safer, less spam laden, less criminal-infested internet.

At the same time, he’s right. The whole OpenID structure hinges on the URL routing to the correct machine on the Internet. In other words, DNS. Now do some research on DNS poisoning. Scary.

Now, it strikes me that you can largely fix this by requiring SSL connections. In other words, have the OpenID URL be an https:// URL, and have the relying party (the website where you want to log in) check for a valid SSL certificate. Note thought that SSL must be used at every stage. OpenID lets you use your own URL as the identifier, but redirect to another OpenID identity provider. Both URLs must use SSL to maintain integrity.

Scary indeed. The OpenID developers have assumed reliable DNS. Now, Tim’s probably right that encryption is the solution to this problem, but I don’t think SSL would work. Even if there is a certificate for the site, most browsers fail to properly inform users what it means when an SSL certificate has changed or isn’t there now. Plus, people are trained to use the domain name and trust that it works.

So how can encryption help? Well, I think DNSSEC and IPSEC (or IPv6) would actually solve (not patch) the problem, but designing better protocols hasn’t been the real issue. DNSSEC and IPSEC have been around for a while. The problem is adoption. No one uses these protocols just like no one uses PGP for encrypting their email.

Metcalfe’s Law is holding most people back since they don’t want to be the only ones using the “other” network. This is another great example of why “road” or “highway” analogies don’t work for the Internet. If this were a pothole or even a collapsed bridge, we could fix the problem properly without really affecting most people. However, since this is the Internet, we can’t actually solve this unless everyone agrees to stop using DNS.

So we’re going to continue to see problems with old infrastructure protocols like DNS. As a result, phishing will continue to be a serious problem. The only way this will stop is if there is a problem so big that the monetary incentive to avoid the problem pushes everyone to change. Who wants to guess how big of a problem that would have to be?

Yesterday Barack Obama was at Purdue University to talk about national security. You can read the text of his remarks here.

Purdue University may seem like a strange place to talk about National Security for many people, but this location was well-chosen for several reasons. First, Clinton won Indiana in the primaries and although the state tends to vote republican in November, Obama needs to continue to bring the democratic party together. Second, Sen. Evan Bayh (D-IN) supported Clinton in the primaries. He’s a very popular former governor of the state who’s father was also in the Senate. Being able to receive his support is important for Obama. Third, Sen. Richard Lugar (R-IN) is a foreign policy and national security expert. Although Sen. Lugar was not at the event, he was spoken of with high praise. Fourth, Purdue University is home of CERIAS, one of the best cyber security research institutions in the world. It makes sense to talk about national security in a state that has such an influential voice in that area.

As to the actual event itself, I strongly encourage you to read Professor Gene Spafford‘s write up of his experiences at the event. He gives an overview of Obama’s speech and each of the three panels that followed. It is an excellent read if you are interested in national security, politics or computer security. Although there are many quotable sections of the post, I will refrain from quoting it in the hopes that my strong endorsement of it will encourage you to read the whole thing.

CNN is running an article about a 22 year old woman who is facing a probable sentence of six years for identity fraud. There are a couple of things to note in this story.

First, their victims were friends and family. This is a common form of identity fraud. More than a third of all victims of identity fraud know the person who victimized them. Why? The answer is access. Friends and family are more trusting and their identity information is simply more easily available. It may even be easier for criminals to use since many vendors may be willing to look the other way for a daughter using her mother’s credit.

Second, the article quotes a federal prosecutor using the phrase “identity fraud” rather than identity theft. This is extremely important because it more accurately describes the crime. We already have laws on the books for fraud. Fraud has been illegal for quite some time. Yes, there are technological issues in catching the criminals, but the situation is far better than it was a few yeas ago.

Jim Harper describes the difference in detail in his book Identity Crisis:

Silence of the Lambs was a 1991 movie starring Jodie Foster as FBI Special Agent Clarice Starling and Anthony Hopkins as the notorious and devious supercriminal Hannibal Lecter. At the end of the movie, Lecter overpowers ad kills two guards in order to escape from a special prison that has been built for him on the upper floors of a building. He changes into the uniform of one of the guards, hides the guard’s body and poses as that guard, badly injured but clinging o life. To complete the deception, Lecter tears the guard’s face off and places it over his own. The police wheel Lecter out of his prison on a gurey, underneath that gruesome mask. This is identity theft. Lecter has taken a key identifier from the dead and mutilated guard, who will never get it back.

Obviously, simply using an identifier is far different than stealing one. It is nice to see that the federal prosecutors are using the correct terminology and that it is making its way into the mainstream press.

Recently we have seen several interesting developments in Mac OS X Security. Apple published a Leopard Security configuration guide (pdf) for experienced Mac OS X users. Apress published Foundations of Mac OS X Leopard Security. (Slashdot review here.)

However, I think the most interesting development has been the discussion of a SUID vulnerability by Matasano Chargen, among others. The vulnerability can be easily fixed by:

sudo chmod -R u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app

Along with the announcement that most of the work on the next version of OS X will be under-the-hood improvements, the discussions of what improvements Apple should make to OS X Security have been thriving. In particular, I like Dino Dai Zovi’s editorial on what improvements he would make.

Dino lays out five specific improvements he would make:

• Real ASLR (address space layout randomization). Library randomization with dyld loaded at a fixed location just doesn’t cut it.
• Full use of hardware-enforced Non-eXecutable memory (NX). Currently, only the stack segments are enforced to be non-executable. Welcome to the new millennium where buffer overflows aren’t only on the stack.
• Default 64-bit native execution for any security-sensitive processes. I don’t particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, Mail.app and just about everything else that has security exposure to run as a 64-bit process. Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
• Sandbox policies for Safari, Mail.app, and third-party applications. Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications. I love the scheme-based policies, by the way.
• Mandatory code signing for any kernel extensions. I don’t want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk. Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate.

Overall, this is an excellent list with one glaring omission: improve FileVault. There are many things that could be improved in this area, but I think the first two that come to my mind are integration with Time Machine and the ability to configure encryption for individual folders (other than the home folder) or entire disks. There are other, more technical problems with FileVault (such as the use of CBC mode encryption), but I think these are largely less important than living up to Apple’s reputation for making things easy to use. Right now, FileVault is not easy to use with Time Machine and it doesn’t serve the needs of those who need full disk encryption or those who really only want a few folders to be encrypted.

I would also like to pick a tiny nit on Dino’s list. I think Mandatory code signing for kernel extensions should be something that by default is enabled, but could be turned off manually as a part of the System Preferences by a user. There are still people who want the freedom to do whatever they want with their computer and although this may mean that they have enough rope to hang themselves, they still deserve that freedom.

Here’s a really nice down-to-earth screencast of the new features in Firefox 3, which will be released this month. I found this through Slashdot, but it is actually quite straightforward and you shouldn’t need a technical background to understand what’s going on here.

The screencast shows a nice overview of the new Firefox, but I wanted to focus on two very important security features that are new in Firefox 3: Website Identity and Malware protection. The website identity feature uses certificates and previous visits to inform the user who runs the website and whether or not the user has been there before. This is critical information that can both improve user confidence and prevent phising attacks.

The malware protection feature attempts to prevent sites from taking advantage of flaws in the browser or add-ons. This feature is similar to the Phising protection added in Firefox 2, but they are also integrating virus scanning and malware protection into the download manager.

The screencast doesn’t talk about Mac features, but since I use a Mac, I will mention the big ones briefly. Firefox 3 takes on more of the Mac user interface conventions when installed on a Mac. One of their big pushes was to make sure that their browser was a native application for each operating system it installed on, so this actually applies to Windows as well. Also, Firefox 3 has significantly improved memory management and speed on the Mac. This was improved across all operating systems, but it was a serious complaint in the Mac community because Safari was so much more efficient than IE or Firefox. For the interested, Daring Fireball has a much more detailed coverage of Firefox 3 for the Mac.

Obviously, I can’t cover all the features in a new release of something like Firefox with a single blog post, so if you want more information I recommend checking out lifehacker’s top ten list of new Firefox features. For those who are of a more technical persuasion and wanting more information, you can check out the Firefox 3 Product Requirements document here. Also for the serious geek, check out this post (somewhat old now) on Firefox 3 Memory Usage improvements.

[Edit: There's an excellent "Field Guide to Firefox 3" post here that explains all anyone would want to know and more about the new version of Firefox, which is released tomorrow, June 17th.]

Although I’m sure this is old news by now (I apologize – I have been extremely busy the last couple of months), I did want to post briefly to say that I was announced as the winner of Bruce Schneier’s Third Annual Movie-Plot Threat Contest. As I posted in that thread, I am surprised and pleased to have won. And honored. It’s nice to get a hat tip from people whom you respect and admire.

I encourage you to check out the other entries, which are extremely good. When the finalists were announced, the comment-based voting was very, very close. Here are the other entries:

• DNA adulteratometer
• SOS device
• Anti-laser-pointer eyeglasses
• “Alertness alert”

Lastly, my winning entry: Toothpaste test strips.

Ravan, one of the commenters in the announcement thread, pointed out that the FDA has a FAQ on toothpaste, which is rather interesting. Obviously, I based my entry on the fact that there was a recent scare and actually quite a few deaths related to contaminated toothpaste. I think these peripheral fears are exactly the kinds of things that can cause a lot of unnecessary terror on the part of the average person who simply doesn’t have time to keep up with the myriad of things out there that can cause harm. Even though no one in the United States died, the story about the contaminated toothpaste received extensive coverage.

The whole thing had a sort of Tylenol murders feel to it. What is it about human psychology that makes us so afraid of this type of threat when statistics can show other threats are far more dangerous? Bruce Scheier has been investigating this pretty regularly on his blog and I encourage you to read his essay on the topic if you are curious.

Although Ed Felten has recently gotten tons of press about his research group’s recent analysis of breaking hard drive encryption, I wanted to talk about some research that he’s done previously on electronic voting for several reasons. First, I mentioned voting in my last post. Second, I have blogged about electronic voting here before that. Third, it is an election year and seems pertinent. Fourth, I am still trying to catch up on some blogs that I follow and recently was able to watch Ed Felten’s presentation in the CERIAS Security Seminar series.

If you are unfamiliar with Ed Felten, I would like to provide some background. He’s a computer security researcher with extensive experience in authentication, secure Java programming, and digital rights management. He has recently also become a leader in analyzing security concerns relating to electronic voting. He is a fellow of the ACM and an EFF Pioneer Award winner. He is the author of a popular technology and public policy blog called Freedom to Tinker. He is also an excellent presenter.

His presentation for the CERIAS seminar is extremely good. I think it is probably accessible for those who are not well-versed in computer security terminology. Certainly, most of the talk is non-technical in nature. I strongly urge anyone reading this who has wondered just what the big deal surrounding electronic voting is all about to at least watch the first half of the presentation. It is an excellent introduction into the amazingly insecure fashion by which elections are held in America.

He talks about the history of electronic voting, some of the legislation that may affect electronic voting, the goal of verifying an election and how their research group has approached the problem. I’m not entirely sure that the importance of the problems can really come through in a sterile environment such as an academic presentation, but he certainly does a great job of motivating these problems on his blog. For example, the pictures on his blog he takes of unattended voting machines prior to election day. Of course, like any true academic, he provides references to their work so that you know where to look for more information if you are interested.

At the end of the talk he is asked a question about possible cryptographic methods that would allow a voter to obtain a receipt that they could later verify on a government website. I’m not entirely sure I like his answer. He says something like (Yes, I’m paraphrasing.), “There are attempts, but they aren’t ready for primetime.” This is a huge caveat and it almost seems to imply that the crypto isn’t quite there yet. Usually, it’s the humans that aren’t ready for the crypto. In this case there are some pretty interesting cryptographic schemes, and they lack the same thing most other cryptographic schemes lack: an easy-to-understand user interface. I’m sure Dr. Felten knows this and was just providing a concise answer, but if you are interested in more, I would read Dr. Rivest’s paper on Three Ballot Voting as a great place to start.

One of the most highly charged pieces of legislation that has been passed by Congress in recent years is the Protect America Act. Probably the only good thing about it is the sunset provision that ensures it will expire in its current form unless Congress acts to renew it or make it permanent. That debate will be soon; the act was extended yesterday for another 15 days.

I haven’t commented about this much because there’s been quite a bit of coverage of it in the mainstream media. If you have somehow managed to avoid that coverage, and landed on this blog (Hi Mom!) the 15-second summary of the Protect America Act is that it allows the NSA to skip the established process of getting a warrant to wiretap communications by using an entirely internal process of reviewing the need for the wiretap. The White House wants this legislation because they believe the current process of obtaining a warrant is too slow for present needs.

Furthermore, there will be debate on a second major initiative of the White House: retroactive immunity for the companies involved in recently allowing illegal wiretaps. The 15-second summary of this situation is that an AT&T employee blew the whistle on a secret room that was setup to see all the data sent over the Internet for AT&T and several other companies. There is a class-action lawsuit against the companies and the Bush administration would like to get them off the hook by making their actions legal after the fact.

If you would like a quick overview of the situation as of November to catch yourself up on what might be on the news in the next two weeks, check out this YouTube video:

There are many places to go for more information on these issues. The Center for Democracy and Technology has an excellent guide on the amendments. EPIC spotlights surveillance issues here. The EFF has more information on warrantless surveillance here.

However, the best resource and the primary reason I chose to make a blog post about this topic is the paper entitled “Risking Communications Security: Potential Hazards of the Protect America Act” by Steven Bellovin, Matt Blaze, Whitfield Diffie, Susan Landau, Peter Neumann, Jennifer Rexford that will appear in the Jan/Feb issue of IEEE Security and Privacy Magazine. If you only read one article linked from this post, the Risking Communications paper is the one to pick. Matt Blaze has a post about their article, as does Steven Bellovin.

Slashdot recently reported on an ArsTechnica article on the death of RealID. There are several things to take from this.

First, RealID is horrible from a privacy and liberty standpoint. This is well-known to anyone who actively concerns themselves with these sorts of issues. It is essentially a national ID card. Depending on how much of a privacy nut you are this seriousness of this could range from a simple invasion of your privacy to something straight out of 1984 or the Book of Revelation. I’m not sure I would take it to that extreme, but I do think the concept of a national ID card is a non-trivial invasion of privacy.

Second, RealID isn’t ecnonomical. The exact details of the security tradeoffs show that RealID is an extremely expensive trade-off. This is very important and subtly hard to understand. Instinct tells us that being able to identify everyone should allow us to determine those people who pose a threat and those who don’t. Unfortunately, reality doesn’t work like that if for no other reason than the simple fact that past behavior doesn’t always accurately predict future actions. Of course, there are many other reasons stated in the link above.

(BTW, This is really the only reason that RealID is dying. It was a massive unfunded mandate for the State governments. If it had been a pork barrel project with horrible security consequences but a nice paycheck for the State governments, then we might have a different story.)

Third, RealID may actually worsen national security. A single national database with the personal information of every citizen in the US is a juicy target for a lot of people with bad intentions. It is the ultimate honeypot, only using real data as opposed to fake data. A single process by which identification can be done is a monoculture with similar problems. I think the easiest analogy for people to understand is that throwing your support behind RealID as the identification card for any American is like putting your entire investment portfolio in one business. It’s just a lot safer to not have all your eggs in one basket.

So if RealID is so bad and it’s also “dying” why have I titled this post “The Non-Death of RealID”? Simply put, this sort of problem is like a bad penny. It keeps coming back because human instincts make it sound good. It keeps coming back because it affects personal liberty, which must always be defended. Security and Liberty aren’t things that you do once and forget about so the threats to these never really die.

There’s a BBC article that was posted this past Saturday entitled Big Brother is watching us all. I am leary of reading traditional media articles about privacy because many of them are inflammatory and most seem to provide and distorted view of what most reasonable privacy advocates are actually advocating. However, I was curious because it was the BBC and London is well-known to have extensive surveillance camera networks.

Despite my misgivings, the article does describe some technologies in a rational and accurate manner. I don’t know if the technologies described are right around the corner or if it will still take decades for them to be functional. The reality is probably somewhere in the middle. However, I do know that we’re nowhere close to being able to understand as a society the implications that some of these things, when functional, will have for us.

Of course, there is a great example of the traditional tripe usually found in mainstream media articles. It comes at the end of the article:

Using radio waves, you point [the device at] a wall and it tells you if anyone is on the other side. [Ian Kitajima's] company, Oceanit, is due to test it with the Hawaiian National Guard in Iraq next year, and it turns out that the human body gives off such sensitive radio signals, that it can even pick up breathing and heart rates.

“First, you can tell whether someone is dead or alive on the battlefield,” said Ian.

“But it will also show whether someone inside a house is looking to harm you, because if they are, their heart rate will be raised. And 10 years from now, the technology will be much smarter. We’ll scan a person with one of these things and tell what they’re actually thinking.”

He glanced at me quizzically, noticing my apprehension.

“Yeah, I know,” he said. “It sounds very Star Trekkish, but that’s what’s ahead.”

This is exactly the reason I dislike mainstream media articles about technology. No, there will not be a magic radio wave device that can read your mind and determine what you’re actually thinking in the next ten years. This is hogwash. One of the many reasons why is simple. The first step in building a device that can determine what someone is actually thinking is creating an algorithm or process that can determine what someone is actually thinking. Anyone who has ever been married can tell you how successful humans are at that sort of thing.

A quickly beating heart is indicative of many disparate things. Most of these are not “I am preparing to kill whomever is staring at me through my wall.” However, if you are a member of a SWAT team holding a device such as this in one hand and a machine gun in the other… Well, let’s just say that a hammer sees every problem as a nail.

A similar situation is described in Blink by Malcom Gladwell where a police officer had to make a split second decision based on bad instincts. The good news is that training can improve split second decisions in police officers. Thus, it is possible that proper training in the use of technology can prevent abuses and wasteful spending which might result from misunderstanding technology. The bad news is that we may not be able to train those in decision making positions rapidly enough to keep up with technology marketers (and clueless mainstream media journalists) who are trying to sell the next miracle device that will solve all your security problems.