August 16, 2018

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.

Flash, Scratch, Ajax: Apple's War on Programming

Any ambitious regulatory scheme will face pressure to expand, in order to protect the flanks of the main regulation against users’ workarounds. Apple’s strategy of regulating which apps can run on the iPhone and iPod is just such a regulation, and over the last week or so Apple has been giving in to the pressure to expand its regulation.

To illustrate Apple’s regulatory problem, consider a hypothetical iPad app called Ed’s App World (EAW). EAW lets you download items called EdApps, which consist of instructions that the EAW app carries out. Any developer can create an EdApp which expresses its instructions in Ed’s Programming Language. It’s entirely possible to create an app like EAW.

Apple’s regulatory problem is that Ed’s App World is effectively a competing app store — EdApps can do anything that apps can do, and any developer can create and distribute an EdApp. If Apple wants to prevent competing app stores, it has to keep apps like Ed’s App World from existing.

Apple has long been trying to keep specific technologies like Adobe’s Flash off the iPhone and iPad because these technologies have EAW-like features. Now Apple has expanded its regulation to say that only certain programming methods are acceptable. Here’s section 3.3.1 of Apple’s iPhone developer license agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This rules out many common programming languages and tools. To developers, it looks like Apple is trying to micromanage how they do their work.

Apple’s ban on programmable apps goes beyond just Flash. This week Apple banned Scratch, a widely used educational tool that introduces students gently to computer programming by letting them construct animations. Why did Apple ban the Scratch app? Presumably because Scratch animations involve elements of programming. Computing educators were unhappy, to say the least. Mark Guzdial of Georgia Tech put it this way: “Want to be truly computing literate, where you write as well as read? There’s no app for that.”

What’s really interesting is that despite Apple’s best efforts to block these apps, there is an enormous EAW-type system that Apple hasn’t had the guts to block: the web. Thanks to so-called Ajax technologies, the web has become a vehicle for delivering app-like functionality (within web pages). Apple’s Safari browser on the iPhone and iPad supports these apps well. It’s hard to imagine that Apple could get away with blocking all of the Ajax-enabled sites we use every day. And Apple’s Ajax problem will become even worse as HTML 5 comes online, with even better support for web-based apps.

If you’re not a techie, this stuff may seem like inside baseball to you. But it does affect what you can do and see. You may not know all of the details of why the app store starts looking more and more like Disneyland, but you’ll notice that it’s happening.

Finally, I want to address the common objection that most people don’t care about limits on programming, because they don’t know how to program. To me, this is like saying that you don’t care about restaurant closings because nobody in your house knows how to cook. If you can’t cook for yourself, you should care more about restaurant quality. If all of the good restaurants close, good cooks will just make their own good meals — but you’ll be out of luck.