- Election 2011
- Chronology (including bills)
- Electoral District (list)
- Participate in mailing lists
Harlan Yu and I recently wrote an article for XRDS Magazine entitled Using Software to Liberate U.S. Case Law. The article describes the motivation behind the CITP project called RECAP, and it outlines the state of public access to electronic court records.
Using PACER is the only way for citizens to obtain electronic records from the Courts. Ideally, the Courts would publish all of their records online, in bulk, in order to allow any private party to index and re-host all of the documents, or to build new innovative services on top of the data. But while this would be relatively cheap for the Courts to do, they haven't done so, instead choosing to limit "open" access.
Since the first release, RECAP has gained thousands of users, and the central repository contains more than 2.3 million documents across 400,000 federal cases. If you were to purchase these documents from scratch from PACER, it would cost you nearly $1.5 million. And while our collection still pales in comparison to the 500 million documents purportedly in the PACER system, it contains many of the most-frequently accessed documents the public is searching for.
As with many issues, it all comes down to money. In the E-Government Act of 2002, Congress authorized the Courts to prescribe reasonable fees for PACER access, but "only to the extent necessary" to provide the service. They sought to approve a fee structure "in which this information is freely available to the greatest extent possible".
However, the Courts' current fee structure collects significantly more funds from users than the actual cost of running the PACER system.
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 coure, security is 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.
James Grimmelmann is an Associate Professor at New York Law School.
Bill C-32, the government’s latest attempt at reforming copyright laws, brings Canadians a Jekyll and Hyde. On a positive note, the bill demonstrates that Parliamentarians were listening to Canadians during the Copyright Consultations last year. It legalizes fair parody and satire, and clarifies that educational use of content can qualify as fair dealing. It also legalizes format shifting and time shifting, recognizing that Canadians want be able to legally put music on their computers and iPods, and record content using VCR's and PVR's.
Unfortunately, this fair balance does not permeate through to Bill C-32's legal protection of digital locks. Here, the bill caters to U.S. demands rather than the views of Canadians. The bill allows distributors to restrict access to content, skirting around the balance that is struck by fair dealing provisions. Reporters won't be able to fairly use locked content in news stories, filmmakers won't be able to insert protected clips in documentaries, and whistleblowers seeking justice will not be able to release encrypted documents.
Other key sites
Digital Copyright Canada BLOG