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.
I haven’t linked to many air travel stories recently in part because there are simply so many of them that picking one to link to over the others is a challenge in and of itself. Recently, I came across an article by LZ Granderson at CNN that sort of summarizes the situation well:
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.
This week Amazon introduced their latest creation: the Kindle Fire. One of the features of the Kindle Fire is a new kind of web browser called Silk. Here’s a video explaining how Silk works:
Silk effectively splits a traditional web browser into a front end that’s running on the local machine and a back end that’s running in the cloud. Chris Espinoza describes it thusly:
The “split browser” notion is that Amazon will use its EC2 back end to pre-cache user web browsing, using its fat back-end pipes to grab all the web content at once so the lightweight Fire-based browser has to only download one simple stream from Amazon’s servers. But what this means is that Amazon will capture and control every Web transaction performed by Fire users. Every page they see, every link they follow, every click they make, every ad they see is going to be intermediated by one of the largest server farms on the planet. People who cringe at the data-mining implications of the Facebook Timeline ought to be just floored by the magnitude of Amazon’s opportunity here. Amazon now has what every storefront lusts for: the knowledge of what other stores your customers are shopping in and what prices they’re being offered there. What’s more, Amazon is getting this not by expensive, proactive scraping the Web, like Google has to do; they’re getting it passively by offering a simple caching service, and letting Fire users do the hard work of crawling the Web. In essence the Fire user base is Amazon’s Mechanical Turk, scraping the Web for free and providing Amazon with the most valuable cache of user behavior in existence.
From the technical descriptions of Silk that I’ve seen, this is pretty accurate. Espinoza later updated his post to say that he doesn’t believe this is a privacy concern:
(9/28 8:45 PST Removed “privacy and.” The piece is about data mining and aggregation, there’s no argument about privacy concerns at all, but people are reading that into it.)
I disagree. Only someone who doesn’t understand the current state of privacy law in the United States would make such a statement. Essentially, by splitting the browser such that all traffic flows through Amazon, they are operating as an ISP. ISPs have numerous privacy concerns. For example, what if the government asked Amazon to provide records of every user who visited a particular website? Currently, this request would fall under something called Third Party Doctrine. Tim Lee describes it as…
the legal principle that, in effect, you lose your Fourth Amendment rights when you relinquish information to a third party. The doctrine has become increasingly important with the rise of modern technology because we now entrust a host of private data — including our email, cell phone calling data, credit card transactions, and more — to private companies, and the third party doctrine would seem to suggest that Fourth Amendment protections would not extend to such information.
The government doesn’t need a warrant to obtain records disclosed to a third party. If it sounds incredible to you that the government wouldn’t need a warrant to obtain something as sensitive as everything you’ve done online with your new Kindle Fire, understand that the government can access your banking records without a warrant because your bank is a “third party” to the data. ISPs are third parties to Internet traffic, and Amazon would be a third party for all Internet traffic on your Kindle Fire. (For more information, please read Jim Harper’s description of how this situation came to be and what we could do about it.)
Om Malik, prompted by Espinoza’s post, got this response from an Amazon spokesperson:
Is Amazon able to peer into its customer usage behavior and use that to offer services based on that data. For instance if you see thousands of your customers going to buy SeeVees shoes from say a store like James Perse at a certain price, can you guys use that data to specifically tailor the Amazon store and offer up deals on those very same pair of shoes?” – the answer is no, as you can see in our terms and conditions, URLs are used to troubleshoot and diagnose Amazon Silk technical issues. Moreover, you can also choose to operate Amazon Silk in basic or “off-cloud” mode. Off-cloud mode allows web pages generally to go directly to your computer rather than pass through our servers. As a reminder, usage data is collected anonymously and stored in aggregate, and no personal identifiable information is stored. It’s also possible to completely turn off the split-browsing mode and use Amazon Silk like a conventional Web browser.
Notice that Amazon says they can’t “peer into customer usage behavior and use that to offer services based on that data.” If this reminds you of Dropbox’s original privacy claim that “All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password,” then you’re not alone. Christopher Soghoian showed that Dropbox could access your files. There are no technical limitations preventing Amazon from using customer usage behavior for whatever they want, just as there were no technical limitations preventing Dropbox from accessing your files. Amazon’s Silk browser will know what websites you visit and what you do on those websites. Amazon will have access to this data. What proof will users have that Amazon isn’t doing whatever they want with that data? Amazon’s terms and conditions basically amount to trust, but “trust me” isn’t enough. This data is too important: emails, financial records, medical records, relationships with friends, and everything else people do on the Internet.
Even if all your browsing data was anonymized prior to being sent to Amazon, anonymous data collection can still violate privacy principles. Bruce Schneier wrote a great article for Wired about anonymized data sets that were publicly released back in 2007. He made this point, which I think is particularly relevant for Amazon’s new Silk browser:
Like everything else in security, anonymity systems shouldn’t be fielded before being subjected to adversarial attacks. We all know that it’s folly to implement a cryptographic system before it’s rigorously attacked; why should we expect anonymity systems to be any different? And, like everything else in security, anonymity is a trade-off. There are benefits, and there are corresponding risks.
Security advocates don’t accept encryption algorithms that aren’t publicly available and haven’t gone through rigorous testing. Privacy advocates shouldn’t accept anonymization algorithms that aren’t publicly available and haven’t gone through rigorous testing. Arvind Narayanan and Vitaly Shmatikov demonstrated this well with the Netflix datasets.
Amazon also said that users could optionally cause Silk to operate as a conventional browser that wouldn’t use Amazon’s cloud to speed up the experience, but this option isn’t enabled by default. Defaults matter. Human psychology demonstrates this in numerous venues. Defaults are also particularly important for technology. The FTC has begun recommending a privacy by design approach, originally described by Ontarioʼs Information and Privacy Commissioner Anne Cavoukia, for technology companies like Amazon. Think tanks concur with this assessment. For example, the Center for Democracy and Technology said the following (emphasis mine):
The FTC should release a set of recommendations outlining the role that Privacy by Design can play in implementing a new set of comprehensive FIPs. These recommendations should emphasize the role of privacy impact assessments, privacy threshold analyses, the integration of PETs into product development, end-to-end lifecycle protection for data, and privacy as the default or as a clear, easy-to-understand alternative.
If Silk is set to the split-browser, cloud-based mode by default, then Amazon isn’t actively practicing privacy by design. No other browser operates like Silk. [Edit: This isn't true. As Charlie pointed out in the comments, Opera Mobile and Opera Mini use a split-browser architecture.] This is new and different, and it has important implications for privacy. Therefore, the privacy by design approach would be to operate as a conventional browser by default and provide users with an option to enable the split-browser, cloud-based mode if they wanted. However, it doesn’t appear as if that’s Amazon’s intention based on their comments to Om Malik.
Amazon has created a new technology with their Silk browser, and they should be applauded for building something new and different. Their Silk browser may speed up the web dramatically for Kindle Fire users, but users should know that there are tradeoffs involved to achieve that speed. In this case, the tradeoff is privacy. If the speed increase is substantial enough, then there are probably many people who would make that tradeoff when using their Kindle Fire. They could do their banking, emailing, or other sensitive surfing at a computer using their preferred security and privacy settings on a desktop browser. However, Amazon isn’t practicing privacy by design, and their terms and conditions are almost deceptive. Amazon should clearly state the technical safeguards put in place to ensure that user data is only used for trouble shooting, and the Silk browser should operate conventionally by default.
If your code gets hacked, are you the one on the hook? In the early decades of the software industry, the answer was usually “no.” Software licenses routinely disclaimed liability, and until recently, security flaws were considered to be just another fact of life. When problems were discovered, companies were expected to fix them quickly, but they were rarely on the hook for the resulting damage.
That’s changing rapidly. Recently, Sony faced a class action lawsuit for losing the private information of millions of users. And this week, it was reported that Dropbox is already being sued for a recent security breach of its own.
Read the whole thing; it’s not long.
I do want to pick a nit with part of the interview with Professor Alex Halderman of the University of Michigan:
Ars asked Alex Halderman, a computer science professor at the University of Michigan, to help us evaluate these options. He argued that consumer choice by itself is unlikely to produce secure software. Most consumers aren’t equipped to tell whether a company’s security claims are “snake oil or actually have some meat behind them.” Security problems therefore tend not to become evident until it’s too late.
I don’t disagree with the conclusion, but I do disagree with the rationale. (Yeah, I’m really picking a nit here…) It’s true that most consumers aren’t equipped to tell wether a company’s security claims are snake oil or not, but that doesn’t necessarily mean that a consumer choice approach is doomed to fail. The fact of the matter is that most consumers aren’t equipped to differentiate a high quality product from a low quality one in any field. The difference is that for most products we can effectively rely on the few consumers who are able to make that differentiation. I don’t know a thing about the best window treatment for a house, but with just a little digging I can find some reliably good advice one way or the other about a given product. Unfortunately, security is one of those products for which even experts are unable to provide reliable advice. It’s just inherently challenging to evaluate the security of a product. (Halderman talks about this later in the interview.)
If you’re interested in more information on these topics, I recommend Bruce Schneier’s extensive writings about both the challenge of evaluating security and the value of liability as a motivator for companies providing products that should be secured. Liability is one of the first things he mentions in his book Secrets and Lies: Digital Security in a Networked World. Perhaps the best summary of his views for the uninitiated is his recent TED talk.
One thing is for certain, the stakes are only going up as The Cloud (and iCloud) goes mainstream. So does this change the way I am going to use web based storage? Not really. The huge benefits I receive from cloud syncing make it worth the risk. Nevertheless, there are a few things you can do to protect yourself:
Lock up those online accounts with a strong password, not pencil;
Change your online passwords. I change mine every time the clocks change;
Don’t be stupid about what you store up there. Database of 1970’s baseball cards = Yes. Scanned tax returns = no.
If you upload anything sensitive, encrypt it yourself first on your Mac. I wrote about it in the book and there are a lot of online tutorials out there explaining how to do it.
So in response to this latest problem am I going to run out and cancel my Dropbox account? No. I think Dropbox learned its lesson. (At least this lesson). I still think, however, we are not far from The Big One.
I believe the majority of tech-savvy people would agree with this list, but unfortunately, it perpetuates a security myth that can be quite harmful: changing your passwords regularly can be quite detrimental to your overall security. As Bruce Schneier says:
The downside of changing passwords is that it makes them harder to remember. And if you force people to change their passwords regularly, they’re more likely to choose easy-to-remember — and easy-to-guess — passwords than they are if they can use the same passwords for many years. So any password-changing policy needs to be chosen with that consideration in mind.
Two things are far more important than changing your passwords regularly:
Choosing a really strong password, which Sparks mentions.
Not re-using that password at numerous locations.
Any policy on changing your passwords regularly conflicts with these two, more important, goals.
It might seem like a great idea to just choose a simple password, use it everywhere, and then change it regularly. After all, if you choose strong passwords and use a different one for every site you visit, then you’re going to have trouble remembering them. At least with a simple, easy-to-remember password that’s changing regularly the attackers would have to keep breaking it over and over again to have sustained access, right?
The problem is that attackers don’t necessarily want sustained access; they could just as easily be looking for a big one-time score. For example, it would be easier to get away with downloading every document you store in Dropbox and analyzing them later than it would be to sustain access to a Dropbox account for a year. Besides, how often does your sensitive information really change? Social Security Numbers almost never change.
When defending against a one-time score, using a simple password and changing it regularly is a system that fails ugly. The more stuff you ‘secure’ on the cloud using the same password, the more stuff could potentially be accessed in a short period of time based on a single incident at any one provider. Dropbox and Sony are just the recent examples, and they won’t be the last. I’ve written about this before, and I’m sure this post won’t be the last either.
Federal intelligence agencies are developing new software that can analyze the communications networks and travel activities of terrorists to help discover relationships between them.
The software being developed by the National Counterterrorism Center (NCTC), called DataSphere, is just one of several projects intelligence agencies developed in 2010 to aid in retrieval and analysis of intelligence information, according to the Office of the Director of National Intelligence’s (ODNI’s) 2010 Data Mining Report.
The subtitle of that article is “Report details data analysis software developed by intelligence agencies to connect the dots between suspected terrorists,” so it fits pretty well with this article from Bruce Schneier in 2006:
In the post 9/11 world, there’s much focus on connecting the dots. Many believe that data mining is the crystal ball that will enable us to uncover future terrorist plots. But even in the most wildly optimistic projections, data mining isn’t tenable for that purpose. We’re not trading privacy for security; we’re giving up privacy and getting no security in return.
Read the whole article. Schneier has written about this subject for years, and this is a great example of his argument. Data mining is a useful technology for some problems, but terrorism just isn’t one of them.
Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break.
This is a fundamental concept to cryptography in particular and to security in general. It’s worth knowing where it comes from if you’re going to cite it appropriately.
One of the most common pieces of bad security advice I’ve heard over the years is that we should never, under any circumstances, write our passwords down. This is bad advice for many reasons, but I’ve continued to see it from well-meaning individuals for years. One recent example, is this tweet from TechPolicy:
Saw in store…notebook to keep all of your online usernames/passwords in “one easy, convenient place!” Bad idea. http://yfrog.com/gzw4srj
Be sure to check out the picture that came with the tweet.
People continue to advise against writing down passwords because they do not fully understand the difference between cryptography and security. Cryptography is the only area in computer security where all the numbers and mathematics favor defense over attack, but only under heavily controlled circumstances. The ideal cryptographic scheme requires a completely random, unguessable, long password that’s memorized. Unfortunately, as any computer security expert will tell you, we don’t live in an ideal world. In reality, ideal passwords are hard to remember, and in many circumstances you will dramatically reduce your risk by using a completely random, unguessable, long password that’s written down on a piece of paper you keep in a secure location. As Bruce Schneier said many years ago:
We’re all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.
There are many more potential attackers that could attack you over the Internet than there are that could have physical access to a secure location in your home. That’s not to say that you’re not increasing your risk in other areas. The vast majority of crimes are perpetrated by people who know their victims, and many of them are immediate family members. These folks may have access to your wallet. Still, if they know you well, and you’re using a password you can easily remember, they would already have a leg up on guessing it simply by knowing you. In fact, many people share passwords with close friends and family members on a regular basis. If it’s easy to remember, whomever you shared your password with will have a good chance of remembering it.
Here’s my advice: Cut out a piece of graph paper and fill a 14 by 14 grid with random letters, numbers, and symbols. The best way to do this is to use a solid random password generator to generate 14 passwords of 14 characters in length. Then choose a column or a row as your password. You can go right to left or left to right (or up to down or down to up). You could even use several of these as different passwords for different things, which defeats another serious problem that results from not writing passwords down: using the same password for every site you visit. Secure this piece of paper in your wallet, and refer to it as needed. Eventually (maybe after some months) you’ll have memorized the password. Then you may be able to secure the paper somewhere safer.
Even if you don’t take that advice, I strongly urge you to use strong passwords and write your passwords down. The notebook that inspired the TechPolicy’s tweet may actually be the best solution if you are confident that you can secure that notebook from anyone who would reasonably be interested in attacking you.
If you still feel uncomfortable writing passwords down or if you would prefer a digital solution, use a program like 1Password. It encrypts all of your online passwords with a single local password. Agile Web Solutions has browser plugins for every major browser that will allow you to automatically fill in extremely long random passwords, a different one for every site, while you only have to use a single password to access them.
If you’re interested in another example of the confusion between cryptography and security, consider another common piece of bad security advice: security through obscurity is not security at all. Essentially, in cryptography, simply creating something that is not obvious, or somehow just ‘obscured,’ doesn’t guarantee that it is secure in a cryptographic sense. This is one of the most important rules behind the mathematics of cryptography. In fact, a truly secure cryptographic system should be so secure that even if an attacker knew the entire algorithm behind it, they would still not be able to break it. Opening the algorithm and eliminating any obscurity about what it does allows cryptographers from all around the world to critique every element of it to ensure that it is computationally infeasible to break it. This is why the best cryptographic algorithms in commercial use have open source implementations.
However, the usual intent behind the current use of the phrase “security through obscurity” is not correct. One goal of securing a system is to increase the work factor for the opponent, with a secondary goal of increasing the likelihood of detecting when an attack is undertaken. By that definition, obscurity and secrecy do provide some security because they increase the work factor an opponent must expend to successfully attack your system. The obscurity may also help expose an attacker because it will require some probing to penetrate the obscurity, thus allowing some instrumentation and advanced warning.
In point of fact, most of our current systems have “security through obscurity” and it works! Every potential vulnerability in the codebase that has yet to be discovered by (or revealed to) someone who might exploit it is not yet a realized vulnerability. Thus, our security (protection, actually) is better because of that “obscurity”! In many (most?) cases, there is little or no danger to the general public until some yahoo publishes the vulnerability and an exploit far and wide.
Note his emphasis throughout that security is about increasing or decreasing risk.
Cryptography is critical, and for it to work, cryptographers and security experts must follow certain rules and procedures. However, these rules and procedures do not always make sense to apply directly to real-world security problems. The needle in the haystack is depends entirely on being obscured to remain secure from detection. It’s a lot of work for the average Joe to find a needle in a haystack, but if you knew where it was, you could find it pretty easily. It’s not remotely “secure” in a cryptographic sense because there’s an entire class of devices that would be able to find it without much effort (magnets, metal detectors, etc…). Still, for most people, in most circumstances, finding a needle in a haystack remains as the figure of speech implies: unlikely to be found.
Remember: Cryptography is about mathematics; security is about risk management.
If you’ve never seen Bruce Schneier talk before, this is a great one to start with. The discussion isn’t particularly technical, and it’s in the style of the TED conferences. Thus, it would also be a great video to give to friends and relatives that don’t understand why security is such a big deal.
There’s something inevitable about “evercookies,” which is a javascript API that attempts to create extremely persistent cookies. Bruce Schneier mentioned them two days ago, and they have been covered by Ars Technica as well. I won’t link to the site directly because it creates an evercookie on your system if you visit it, but I will say that most of the methods used to create these cookies come from HTML5 storage mechanisms. I’ve been consistently surprised at how few privacy researchers are looking at the many new ways of storing local data with HTML5. Expect to see more of this sort of thing in the future.
Successfully defended my doctoral dissertation today. Thanks to all my committee members, colleagues, and friends for their support! 5 days ago
RT @SteveCase: Lugar's parting words: "Parties don't succeed if stop appealing to voters who disagree with them on some issues" http://t ... 1 week ago
RT @dhh: You are not your Twitter follower count and your 1,000 Facebook friends probably don't like you. 2 weeks ago
You know academic publishing is messed up when the Harvard Library is going broke: bit.ly/IkwWe33 weeks ago
