December 6, 2022

On distracted driving and required phone searches

A recent Arstechnica article discussed several U.S. states that are considering adding a “roadside textalyzer” that operates analogously to roadside Breathalyzer tests. In the same way that alcohol and drugs can impair a driver’s ability to navigate the road, so can paying attention to your phone rather than the world beyond. Many states “require” drivers to consent to Breathalyzer tests, where that “requirement” boils down to serious penalties if the driver declines. Vendors like Cellebrite are pushing for analogous requirements, for which they just happen to sell products.
[Read more…]

Apple, FBI, and Software Transparency

The Apple versus FBI showdown has quickly become a crucial flashpoint of the “new Crypto War.” On February 16 the FBI invoked the All Writs Act of 1789, a catch-all authority for assistance of law enforcement, demanding that Apple create a custom version of its iOS to help the FBI decrypt an iPhone used by one of the San Bernardino shooters. The fact that the FBI allowed Apple to disclose the order publicly, on the same day, represents a rare exception to the government’s normal penchant for secrecy.

The reasons behind the FBI’s unusually loud entrance are important – but even more so is the risk that after the present flurry concludes, the FBI and other government agencies will revert to more shadowy methods of compelling companies to backdoor their software. This blog post explores these software transparency risks, and how new technical measures could help ensure that the public debate over software backdoors remains public.
[Read more…]

An analogy to understand the FBI's request of Apple

After my previous blog post about the FBI, Apple, and the San Bernadino iPhone, I’ve been reading many other bloggers and news articles on the topic. What seems to be missing is a decent analogy to explain the unusual nature of the FBI’s demand and the importance of Apple’s stance in opposition to it. Before I dive in, it’s worth understanding what the FBI’s larger goals are. Cyrus Vance Jr., the Manhattan DA, states it clearly: “no smartphone lies beyond the reach of a judicial search warrant.” That’s the FBI’s real goal. The San Bernadino case is just a vehicle toward achieving that goal. With this in mind, it’s less important to focus on the specific details of the San Bernadino case, the subtle improvements Apple has made to the iPhone since the 5c, or the apparent mishandling of the iCloud account behind the San Bernadino iPhone.

Our Analogy: TSA Luggage Locks

When you check your bags in the airport, you may well want to lock them, to keep baggage handlers and other interlopers from stealing your stuff. But, of course, baggage inspectors have a legitimate need to look through bags. Your bags don’t have any right of privacy in an airport. To satisfy these needs, we now have “TSA locks”. You get a combination you can enter, and the TSA gets their own secret key that allows airport staff to open any TSA lock. That’s a “backdoor”, engineered into the lock’s design.

What’s the alternative? If you want the TSA to have the technical capacity to search a large percentage of bags, then there really isn’t an alternative. After all, if we used “real” locks, then the TSA would be “forced” to cut them open. But consider the hypothetical case where these sorts of searches were exceptionally rare. At that point, the local TSA could keep hundreds of spare locks, of all makes and models. They could cut off your super-duper strong lock, inspect your bag, and then replace the cut lock with a brand new one of the same variety. They could extract the PIN or key cylinder from the broken lock and install it in the new one. They could even rough up the new one so it looks just like the original. Needless to say, this would be a specialized skill and it would be expensive to use. That’s pretty much where we are in terms of hacking the newest smartphones.

Another area where this analogy holds up is all the people who will “need” access to the backdoor keys. Who gets the backdoor keys? Sure, it might begin with the TSA, but every baggage inspector in every airport, worldwide, will demand access to those keys. And they’ll even justify it, because their inspectors work together with ours to defeat smuggling and other crimes. We’re all in this together! Next thing you know, the backdoor keys are everywhere. Is that a bad thing? Well, the TSA backdoor lock scheme is only as secure as their ability to keep the keys a secret. And what happened? The TSA mistakenly allowed the Washington Post to publish a photo of all the keys, which makes it trivial for anyone to fabricate those keys. (CAD files for them are now online!) Consequently, anybody can take advantage of the TSA locks’ designed-in backdoor, not just all the world’s baggage inspectors.

For San Bernadino, the FBI wants Apple to retrofit a backdoor mechanism where there wasn’t one previously. The legal precedent that the FBI wants creates a capability to convert any luggage lock into a TSA backdoor lock. This would only be necessary if they wanted access to lots of phones, at a scale where their specialized phone-cracking team becomes too expensive to operate. This no doubt becomes all the more pressing for the FBI as modern smartphones get better and better at resisting physical attacks.

Where the analogy breaks down: If you travel with expensive stuff in your luggage, you know well that those locks have very limited resistance to an attacker with bolt cutters. If somebody steals your luggage, they’ll get your stuff, whereas that’s not necessarily the case with a modern iPhone. These phones are akin to luggage having some kind of self-destruct charge inside. You force the luggage open and the contents will be destroyed. Another important difference is that much of the data that the FBI presumably wants from the San Bernadino phone can be gotten elsewhere, e.g., phone call metadata and cellular tower usage metadata. We have very little reason to believe that the FBI needs anything on that phone whatsoever, relative to the mountain of evidence that it already has.

Why this analogy is important: The capability to access the San Bernadino iPhone, as the court order describes it, is a one-off thing—a magic wand that converts precisely one traditional luggage lock into a TSA backdoor lock, having no effect on any other lock in the world. But as Vance makes clear in his New York Times opinion, the stakes are much higher than that. The FBI wants this magic wand, in the form of judicial orders and a bespoke Apple engineering process, to gain backdoor access to any phone in their possession. If the FBI can go to Apple to demand this, then so can any other government. Apple will quickly want to get itself out of the business of adjudicating these demands, so it will engineer in the backdoor feature once and for good, albeit under duress, and will share the necessary secrets with the FBI and with every other nation-state’s police and intelligence agencies. In other words, Apple will be forced to install a TSA backdoor key in every phone they make, and so will everybody else.

While this would be lovely for helping the FBI gather the evidence it wants, it would be especially lovely for foreign intelligence officers, operating on our shores, or going after our citizens when they travel abroad. If they pickpocket a phone from a high-value target, our FBI’s policies will enable any intel or police organization, anywhere, to trivially exercise any phone’s TSA backdoor lock and access all the intel within. Needless to say, we already have a hard time defending ourselves from nation-state adversaries’ cyber-exfiltration attacks. Hopefully, sanity will prevail, because it would be a monumental error for the government to require that all our phones be engineered with backdoors.

Applications and Appliances: A Conversation with Jonathan Zittrain

Professor Jonathan Zittrain is well-known for his concern that the general-purpose computer may be disappearing. The recent rise of app stores is putting his fears in a new light. After trading some thoughts about the issues in the blogosphere, he and I sat down at our respective keyboards for a conversation about the future of computing. This is a lightly edited version of our exchange.

JG: I suppose the place to start is with your concern about “appliances”: single-purpose devices like the TiVo. What’s wrong with boxes that do one thing and do it well?

JZ: Nothing’s inherently wrong with single-purpose devices. The worry comes when we lose the general-purpose devices formerly known as the PC and replace it with single-purpose devices and “curated” general-purpose devices.

JG: In the last few years, the appliance has taken on a new face, thanks to downloadable apps. An appliance with an app store is no longer just a single-purpose device: it can do all kinds of things. But that, you’ve argued, doesn’t really fix the fundamental problem.

JZ: It may look like the best of both worlds, but I worry it’s the worst of both worlds.

JG: I wanted to focus on your critique of the Mac App Store. This one is interesting because it sells programs that run, not on a closed device like the iPhone but on a traditional, general-purpose computer. The day that Apple activated the Mac App Store, it didn’t reduce the Mac’s generativity one iota. Every Mac in the world was just as capable of doing everything it used to be able to do, just as easily. All Apple added was a new way to install programs: so they made the Mac even easier to use, without reducing its power. But you’re skeptical. Why?

JZ: Let’s see how much of an advantage a developer sees from having an app in the App Store vs. “sideloaded,” even on a Mac OS that doesn’t require jailbreaking for sideloading. To the extent that users are looking to the App Store for their wares, it’s a de facto limit on generativity even if not a literal one. But I agree that the real worry is if Mac OS should become routinely configured not to allow sideloading at all.

JG: So let’s take up some of the countervailing arguments. One that’s high on a lot of people’s lists is the idea that an app store is more secure because it’s more tightly controlled. And of course, security is on of the major reasons you cite in your book The Future of the Internet for why computer makers and users may be tempted to turn their back on open, generative systems. What do you think the Mac App Store does for security, if anything?

JZ: As a security measure, I give the Mac App Store three out of five stars. That’s because the software it is likely to turn away is more gray market sludge ­ sloppily written or poorly documented ­ than outright badware. There’s nothing to stop a software developer from registering under a cat’s paw, especially to offer a free app, and then build a bomb into the app .­ It could appear exemplary while Apple tests it and users then use it, until a designated H-hour at which point all bets are off.

JG: I might not be so quick to dismiss the security benefits. We know that Apple does run static analysis tools against iOS App Store submissions. And then there’s sandboxing. Regular programs have substantially free run of the computer, but Mac App Store programs are severely restricted in what they can see and do. It’s as if they’re playing safely with soft rubber toys in a glass-encased sandbox: your solitaire game isn’t going to suddenly overwrite your spreadsheets. Doesn’t that have some significant security benefits?

JZ: Sandboxing can prevent some damage from an app bound and determined to wreak havoc, but sandboxing is a phenomenon independent of the App Store: Mac OS could implement it with or without Apple screening the software up front.

JG: True. But sandboxing and Apple’s code review go together. The code review ensures that programs are placed in the smallest appropriate sandbox for their needs. Apple will only let the application have permissions if really needs them to do its job: there’s no reason for a stock ticker to save files to arbitrary places. Without the up-front review, how many developers would voluntarily agree to play only in the sandbox?

JZ: The real question at the intersection of security and freedom is whether the user has an opportunity to choose to override the sandbox’s boundaries. If the user can’t do it, then a bunch of functionality is foreclosed unless Apple chooses to allow it ­ and Apple can be fooled as easily as anyone else by a truly bad actor. If the user can do it, there’s no particular need for the App Store.

JG: This is a question about routine practice and interface design. If I rarely need to override the sandbox’s limits, then when an app comes to me and asks for additional privileges, my eyebrows are more likely to go up.

JZ: Don’t forget that Apple reserves the right not only to prevent software distributions up front, but also retroactively: software can be removed from machines that have already downloaded it. Perhaps helpful in some limited cases of security troubles, but all the more troublesome as regulators realize that cats can be put back into bags.

JG: Well, if we’re thinking about retroactive nuking, Apple has shown that it can uninstall even user-installed programs. After the Mac Defender malware started tricking Mac users into installing it, Apple came out with an operating system update that uninstalled it. Yes, Apple gave users a dialog box with a choice, but technologically, there’s no reason it had to. Do you see a difference between this and the Mac App Store?

JZ: Only in how this evolves our conception of code and who “owns” it: if the app lives in the cloud, our expectations are that it’s a service, and a service can change from day to day. If it’s on our own machines we feel like we own it, and look skeptically — and vendors tread carefully — over attempts to modify it without clearing it with us first.

JG: How much of this is about the fact that this is Apple’s app store we’re talking about? Do you feel differently about app stores that aren’t offered by the same company that controls the hardware and the operating system? So take something like Valve’s highly successful Steam, which is basically an app store for games. It runs on both Windows and Mac, and it handles all of the payment and DRM for the game developers.

JZ: I worry less if there’s not vertical integration, but there’s still a concern if, through natural monopoly, we end up with a single gatekeeper or a mere handful of them. Hence Facebook’s platform as a worry, despite (or because of!) it being not tied to any one OS or browser.

JG: I’d like to bring in an idea from your book: “Red” and “Green” PCs. Your computer would have two “virtual machines,” which couldn’t easily affect each other. The Green one would be for important data and would only run software you were confident in; the Red one would be easy to reset back to a safe point.

JZ: Well, as I say in the book:

“Someone could confidently store important data on the Green PC and still use the Red PC for experimentation. Knowing which virtual PC to use would be akin to knowing when a sport utility vehicle should be placed into four-wheel drive mode instead of two-wheel drive, a decision that mainstream users could learn to make responsibly and knowledgeably.”

JG: I read that and thought it sounded like a good idea. And it was pretty much the first thing I thought of when Apple announced the Mac App Store. Everything you install manually is like the Red PC; everything you install from the Mac App Store is like the Green PC. You have a safe mode for greater security, and an unsafe mode for greater generativity. Since you’re a fan of the Red/Green hybrid between open and closed, why not the Mac App Store hybrid?

JZ: The Red PC isn’t the same as a sandbox. Software developers in a Red/Green environment still only write one piece of code, and it doesn’t have to be otherwise vetted. The whole point of the red zone is to contain any bad effects of iffy code. The point of a sandbox is to mitigate the risks of iffy code, by limiting its functionality outright. This is a subtle but important point. The Mac App Store with a sandbox requirement means that a competent, legitimate developer who wants to do things beyond the sandbox either has to plead a special case or write two versions of the code: one for the Store and one not for the Store.

JG: Can’t this argument be turned back against the Red/Green model? The competent, legitimate developer who wants to write code that indexes and optimally compresses your Word documents needs to plead a special case to whoever controls the green certification. She doesn’t even have the choice to write both red and green versions of her code.

JZ: My conception of the green model is not that it’s guarded by a third party, but that the user gets to place iffy apps into a place where, if they blow up, stuff in the green zone doesn’t get hurt.

JG: I keep coming back to the fact that participation in the Mac App Store is voluntary. And this isn’t just voluntary in the sense that participation in the iOS App Store is “voluntary” because no one held a gun to your head and forced you to write iPhone games. You have no good alternative to the iOS App Store if you want your app to run on an iPhone, but you can perfectly easily write, sell, and distribute software that users install on Macs in the time-honored fashion: clicking on an installer or dragging an icon into the Applications folder. How can adding the Mac App Store as an additional option be a net loss?

JZ: Well, that’s the question. If sideloading is trivial, I’m in your corner. But one wonders why any developer would take the 30% hit in profits to distribute through the App Store if he or she could put it on a Web site and sell it through sideloading. (And, when did the front become the side?!)

JG: Is this really a case against truly voluntary app stores? Put another way, should we be digging in to prevent Apple from offering the Mac App Store, or should we be digging in to prevent Apple from turning off the ability to install programs manually?

JZ: I see it more as a spectrum than a dichotomy. Compare the Mac App Store with a program that provided an Apple Good Housekeeping seal for good code. They’re functionally the same, but wildly different in practice thanks to the power of the default.


Jonathan Zittrain is a Professor of Law at Harvard Law School and the author of The Future of the Internet: And How to Stop It

James Grimmelmann is an Associate Professor at New York Law School.

Tracking Your Every Move: iPhone Retains Extensive Location History

Today, Pete Warden and Alasdair Allan revealed that Apple’s iPhone maintains an apparently indefinite log of its location history. To show the data available, they produced and demoed an application called iPhone Tracker for plotting these locations on a map. The application allows you to replay your movements, displaying your precise location at any point in time when you had your phone. Their open-source application works with the GSM (AT&T) version of the iPhone, but I added changes to their code that allow it to work with the CDMA (Verizon) version of the phone as well.

When you sync your iPhone with your computer, iTunes automatically creates a complete backup of the phone to your machine. This backup contains any new content, contacts, and applications that were modified or downloaded since your last sync. Beginning with iOS 4, this backup also included is a SQLite database containing tables named ‘CellLocation’, ‘CdmaCellLocaton’ and ‘WifiLocation’. These correspond to the GSM, CDMA and WiFi variants of location information. Each of these tables contains latitude and longitude data along with timestamps. These tables also contain additional fields that appear largely unused on the CDMA iPhone that I used for testing — including altitude, speed, confidence, “HorizontalAccuracy,” and “VerticalAccuracy.”

Interestingly, the WifiLocation table contains the MAC address of each WiFi network node you have connected to, along with an estimated latitude/longitude. The WifiLocation table in our two-month old CDMA iPhone contains over 53,000 distinct MAC addresses, suggesting that this data is stored not just for networks your device connects to but for every network your phone was aware of (i.e. the network at the Starbucks you walked by — but didn’t connect to).

Location information persists across devices, including upgrades from the iPhone 3GS to iPhone 4, which appears to be a function of the migration process. It is important to note that you must have physical access to the synced machine (i.e. your laptop) in order to access the synced location logs. Malicious code running on the iPhone presumably could also access this data.

Not only was it unclear that the iPhone is storing this data, but the rationale behind storing it remains a mystery. To the best of my knowledge, Apple has not disclosed that this type or quantity of information is being stored. Although Apple does not appear to be currently using this information, we’re curious about the rationale for storing it. In theory, Apple could combine WiFi MAC addresses and GPS locations, creating a highly accurate geolocation service.

The exact implications for mobile security (along with forensics and law enforcement) will be important to watch. What is most surprising is that this granularity of information is being stored at such a large scale on such a mainstream device.