Any effort to rebuild TSA and get airport security right in the U.S. has to start with two basic principles:

First, the TSA’s mission is to prevent a catastrophic attack on the transportation system, not to ensure that every single passenger can avoid harm while traveling. Much of the friction in the system today results from rules that are direct responses to how we were attacked on 9/11. But it’s simply no longer the case that killing a few people on board a plane could lead to a hijacking. Never again will a terrorist be able to breach the cockpit simply with a box cutter or a knife. The cockpit doors have been reinforced, and passengers, flight crews and air marshals would intervene.

Second, the TSA’s job is to manage risk, not to enforce regulations. Terrorists are adaptive, and we need to be adaptive, too. Regulations are always playing catch-up, because terrorists design their plots around the loopholes.

The rest of the article makes for great weekend reading.

I like that Kip Hawley is so open and willing to talk about airport security issues. I enjoyed his extensive interview with Bruce Schneier back in 2007. I don’t always agree with him, but his opinion is worth reading. I’m looking forward to the book.

Not so long ago, there was a familiar product called software. It was sold in stores, in shrink-wrapped boxes. When you bought it, all that you gave away was your credit card number or a stack of bills.

Now there are “apps”—stylish, discrete chunks of software that live online or in your smartphone. To “buy” an app, all you have to do is click a button. Sometimes they cost a few dollars, but many apps are free, at least in monetary terms. You often pay in another way. Apps are gateways, and when you buy an app, there is a strong chance that you are supplying its developers with one of the most coveted commodities in today’s economy: personal data.

Essentially, the Wall Street Journal is saying that there’s no such thing as a free lunch. Those apps cost something: data. Is this as valuable as cash? Maybe. It’s certainly more of a risk for the companies that make the apps, but it could pay off big. Here’s one estimate from the article:

The “app economy,” which includes Facebook as well as smartphone apps, is estimated to have generated $20 billion in revenue in 2011 by selling downloads, advertising, “virtual goods” and other products, according to estimates from Rubinson Partners, a market researcher.

The WSJ article hits on a lot of big points, many of which are common themes in the security and privacy community. However, it also reminded me of a post from Marco Arment about TextMate 2. The creator of TextMate offered a free upgrade to TextMate 2 for the people who bought the first version. That was years ago. Marco wants to pay for TextMate 2 to ensure that its creator can continue to afford to work on the program.

Although paying for TextMate 2 may seem totally separate from the Facebook business model, there’s an important connection here:

By virtue of its size and user base of 800-million-plus people, Facebook is at the heart of the personal data economy. Popular apps can quickly go “viral” there and gain millions of users—but can also flame out just as quickly. This explains why some apps seek to cash in by gathering as much data as possible and hoping to find ways to make money from it.

Let’s say that someone creates a Facebook app that you really love, but maybe it just doesn’t go ‘viral’ or the creators aren’t able to turn all that data they have access to into cash. What option do you have to ensure that they will keep the app working? After the big influx of initial users, what other data could be collected to keep the app developers working on it?

You don’t have to think of yourself as a programmer to create some moderately complicated programs in Excel. Also, with modern computers available to us, cryptography is easier to play with than you might think. I hope we see more projects like this.

One of the main problems with the current PKI model is the lack of control over CAs and their subsidiaries. There are literally hundreds of organizations spread around the world that are allowed to issue certificates for any domain name and some of them are operated by governments that practice Internet surveillance and censorship.

Worth reading.

Miller, a former NSA analyst who now works as a researcher with consultancy Accuvant, created a proof-of-concept app called Instastock to show the vulnerability. The simple program appears to merely list stock tickers, but also communicates with a server in Miller’s house in St. Louis, pulling down and executing whatever new commands he wants. In the video above, he demonstrates it reading an iPhone’s files and making the phone vibrate. Miller applied for Instastock’s inclusion in the App Store and Apple approved the booby-trapped app.

The rest of that article includes more details on the code signing flaw Miller exploited, but I want to focus on a slightly different aspect of this story: responsible disclosure. Essentially, in responsible disclosure, when a researcher discovers a flaw in proprietary software, they immediately report it to the company responsible and setup a reasonable timeframe for fixing the problem before publicly disclosing the flaw.

Miller first contacted Apple about this problem on October 14th. I’m not sure that three weeks is really enough time to resolve a problem like this. I know he didn’t give all the details, and I know Apple has a reputation for not fixing security bugs until they become public (or perhaps well after they have been public for months…). Still, Miller would have a lot more sympathy with me if he reported the problem to Apple privately and gave them time to resolve the error. Another thing that would have made me a little more sympathetic is if he and Apple had agreed to a timeframe on resolving this problem prior to disclosing the flaw, though I’m not sure Apple would ever agree to something like that. Publicly acknowledging flaws of this nature isn’t really in their DNA.

Despite the flaw in Apple’s code signing, they have been able to respond by removing the exploited app from their app store and canceling Miller’s developer license. (Note: There’s some hypocrisy on Apple’s part here since canceling a developer license is a bit different from their treatment of other iOS security researchers.) Is this good enough for security? Everything in security is a tradeoff, so where does this response fall? It annoys me that there’s a bug in Apple’s code signing, but maybe the setup of the iOS App Store is enough of a response.

The original article points out that a similar issue in Android has resulted in a spate of malware for that platform. I’m not sure a similar thing will happen with iOS. Sure, Apple won’t be able to detect these apps in their review process, but they can always just remove them from the store after they’ve been found in the wild. I would probably prefer to see the code signing exception resolved, but I’m not sure what the tradeoffs really are. It’s hard to make security decisions that way.

Lastly, I should mention that this story is rather one-sided as of now. I haven’t seen anything from Apple about all of this yet. If you’ve seen something from Apple, please leave a comment.

Entitlements are a binary solution – if there’s a hole anywhere in it that malware authors find, then there’s really not much Apple can do until they issue a full operating system patch. We call this kind of solution “brittle” – it requires everything to have been written perfectly, for every contingency, or it fails completely.

Solving security problems proactively is extremely challenging. If there’s a single hole, then all your effort is for nothing. A quick, appropriate reactive response is often the best tradeoff for security. Here’s Wil again:

Code auditing and sandboxing are non-biomimicry – nature doesn’t try to audit every line of code, she tries to fail gracefully. Certificates alone offer a graceful failover – if a developer signs up with Apple and provides false info and manages to trick people into downloading her malware, well, we can just throw a switch and she’s done.

Security shouldn’t be all-proactive, but neither should it be all-reactive. Some proactive measures are worth the tradeoff. The fact that Apple performs a baseline examination of applications sold through their Mac App Store does eliminate obvious security problems, but such an approach is never going to catch every single security problem. For that, the best solution will be reactive, and an application white list enforced with certificates is a reasonable approach.

Corporate privacy concerns are more nuanced than government privacy concerns. You can argue that people can just switch to a competitor, as Schmidt does, but how practical is that? Some companies do quite a bit to lock you in. You can argue about creepy advertising, but there’s a real tradeoff there. Some people like seeing relevant ads in certain contexts.

Government privacy concerns are pretty straightforward. They have the guns, so to speak. Even massive corporations like Google cannot prevent the government from accessing your information if the law allows it. Given the state of data privacy laws in the U.S., this is a pretty serious problem for almost every application that uses cloud computing.

Because there are so many stories about how bad Flash is from a security standpoint, I haven’t really spent much time linking to them. However, Steve Bellovin, a computer security pioneer and a Professor of Computer Science at Columbia, wrote a fantastic post about the security problems caused by Flash:

From a technical perspective, it’s simply wrong for a design to outsource a critical access control decision to a third party. My computer should decide what sites can turn on my camera and microphone, not one of Adobe’s servers.

Definitely read the whole thing. Bellovin ends his post with this:

No wonder the NSA’s Mac OS X Security Configuration guide says to disable the camera and microphone functions, by physically removing the devices if necessary.

I’m not sure what role the operating system should play here, but it’s fascinating to think about. How should things like the camera and microphone be controlled? Webcams are clearly an important area for privacy.

Lastly, Bellovin’s post is based on research done by Feross Aboukhadijeh at Stanford, which is worth reading if only because it is a pretty compelling case of responsible disclosure.

We are generally satisfied with the privacy design of Silk, and happy that the end user has control over whether to use cloud acceleration. But this new technology highlights the need for better online privacy protections. As companies continue to innovate in ways that make novel uses of–and expose much more personal data to–the internet cloud, it’s critical that the legal protections for that data keep up with changes technology.

Read their whole article. It breaks down the primary privacy concerns and how Amazon Silk actually handles those situations. If you don’t regularly follow the EFF, they aren’t super easy to please when it comes to protecting users’ privacy, so this is a reasonably strong endorsement.

Given the physical requirements and inherent importance of an exit row seat, I would feel more comfortable if I knew the person sitting there could at least do a pushup and not just be collecting a reward for being a repeat customer.

These are the kind of systematic disconnects that just crack me up.

Flight attendants tell us to turn off all electronic devices under the guise they could interfere with the plane’s navigation system, meaning that if the terrorists really wanted to cause some damage, all they had to do was read their Kindle during takeoff.

Granderson sort of implies that we should at least attempt to enjoy the absurdity as the amusement that it is. I don’t agree. Waste and inconvenience on this scale isn’t amusing. Security is a tradeoff, and I don’t think we’re making the right decisions. The risk of being the victim of a terrorist on an airplane is ridiculously low.

There are reasons we’re not making rational decisions about airport security, and most of them are probably best explained by the fact that we’re all human. Humans just don’t make rational decisions about some types of risk. Dan Ariely has basically made his entire career about irrational decisions people make. Bruce Schneier’s next book is going to focus on how people make decisions involving trust.

Still, we don’t really understand why people do are so poor at making these decisions. Worse, we don’t know how to improve this sort of decision making. The absurdity of airport security isn’t amusing; the root causes of this problem are probably one of the most important research topics for the next few decades.