• Home
  • About
  • Blog
  • News
  • Events
  • Media
  • Video
  • Glossary
  • Contact
  • Download
  • RSS

The Sandbox and the Playground: Changing Rules for Software and Developers

November 29th, 2011  |  by Kendra Albert  |  Published in Future of the Internet  |  8 Comments

Update on 2/23/2011: Apple has pushed back its deadline for OSX sandboxing to June 1st, 2012. The deadline was originally November, 2011, but was pushed to March 1st  in early November. Although Apple claimed that this change was to give developers time to integrate new permissions from an update,  it does follow the announcement of Gatekeeper, which might be a partial substitute for sandboxing.

During the 1990s, PCs ran whatever software was installed on them. Users bought software (not yet called apps) from physical stores or got a copy from their friends. They stuck the CD in the drive, and went through the installation process, or dragged the application to their application folder.  The code was “signed” by the developer (by being from a box), or not at all.  The operating system didn’t stop and ask “are you sure,” no one typed in a root password, and the applications were limited only by what their programmers had decided when coding. Those were the days of the playground, not the sandbox.

The playground had problems. Software with malicious code or bugs could hijack your PC. Other users could tamper with your files. So sandboxing (although not known yet by that name) was born. Starting as far back as creating separate user directories, to as recent a development as cloud data storage, steps have been taken to make the user’s personal data and computing cycles  safely under lock and key – sometimes with the key held by the user, and other times by the operating system maker. When Windows Vista was released in 2009, it tried to solve this problem with “allow” dialogs, which would pop up when an application tried to take actions without the user’s permission. This solution was mostly considered an annoyance, not a feature, as the parameters that caused a dialog were broad and users just clicked through to allow instinctually. Mac OSX’s requests for passwords before installing applications are just another step down this road – meant to put users in control of their own computing destinies, and less dependent on the good will of developers.

On smartphones, things have gone a different way.  We take for granted that applications haven’t been able to access all the features of the phone. Android users view a permissions screen that tells them exactly what to expect from an application – whether it can take photos with the camera, keep the phone from sleeping or access GPS. Apple screens its applications on the way into the iOS App Store, making clear what parts of the phone they can get to, and limits users to apps from the store. All of the app’s files are required to stay in their own little corner of the file system. This process of requiring developers to encapsulate their applications within one folder – and to clear with someone for access to things outside – restricts the potential for harm. This is one version of the phenomenon known as sandboxing. Sandboxing, on the most basic level, is a security measure used to run code that’s not trusted. Rather than allowing software or applications to play freely across the machine, sandboxes restrict them to very specific resources, mitigating the damage they can do.

For years, it’s been a standard on mobile platforms and web applets. For example, the Bejeweled game that you’re playing in one of your Chrome tabs doesn’t have any way of accessing the Word document you are supposed to be working on. In fact, your Chrome tabs can’t even access each other, preventing badly coded webpages from crashing your entire browser. These apps can play in their own sandboxes – but not all over your phone or PC. The same wouldn’t be true for Bejeweled if it were a regular PC app – it’d be free to rummage through everything on the hard drive, surveilling, modifying or deleting at will.  Knowing that, it’s a marvel that serious viruses didn’t appear sooner and more often.

For phones and web applets, sandboxing is ideal. After all, even you, the user, don’t interact with the underlying file structure of your iPhone or Android device (without jailbreaking), and you certainly wouldn’t want to open an online game and have it be able to make changes to your Word document. Sandboxing has serious security advantages – if programs have to lay out in advance what kind of access they get to a device, and are limited to only specific actions, an app that “goes rogue” or is compromised by malware can no longer cause the same harm to the rest of the user’s data. Similarly, a piece of compromised software can’t run processes in the background that it wouldn’t be able to run anyway – limiting potential damage.

Sandboxing usually also includes signed code, or code that is cryptographically linked to a specific developer license.  Not only do Apple and Google know exactly what parts of your phone the code can access, they also know which developer produced the code. Apple’s signature program is run through its developer program, which is tied to a yearly fee, where as Google’s requires some information from the developer, but not a specific license as such.

Enter the Mac App Store

So as things stood previously, most PCs had some steps towards protection against rogue software, but hadn’t taken the sandboxing route. Browsers and smartphones sandbox processes, but different smartphone platforms have different ways of involving the user. Apple’s iOS doesn’t involve the user, and all permissions are handled at the App Store level. Android apps can either be downloaded from the Android Market or from third parties directly. In both cases, a list of permissions are visible to the user and the applicatiosn are sandobxed where they are still sandboxed.

In early November, Apple announced to developers that it was pushing back its deadline for Mac Store Apps to implement sandboxing to March 1st, 2012. This makes the Mac App Store platform much like the Android Market – users have the option to install applications from elsewhere, but all applications that go through the market must be sandboxed. Although the requirements were supposed to take effect earlier this week, the pushed-back date reflects some of the serious problems MacOS developers were running into in making their applications compatible with Apple’s new rules.

Apple’s change marks a huge departure from the way development and code has operated in the past. As discussed above, software on the PC of the past had access to a playground, controlled only by the user’s discretion. Although Apple’s new OSX Lion has supported sandboxing since its release, Apple is using its distribution platform to require that apps follow their new security rules. The App Store push will certainly increase the amount of applications secured.

Although there may be net gains for users who are concerned about the security of applications downloaded from the Internet, there is the potential to limit the types of applications that companies will bother trying to distribute. Programs as widely used as antivirus software and backup utilities are not distributable through the App Store platform, due to the rule against root access, and in the larger scheme of things, Apple’s concerns about security. This means no Norton Anti-Virus, no Dropbox and no MacZip. At this time, distribution outside the store is not problematic; in fact, most large-scale developers seem to not be early adopters. However, as customers become more comfortable with the App Store process, that might change.

OSX Sandboxing in Depth

The sandboxing requirements make applications downloaded through the Mac App Store limited to a very specific set of actions. Ars Technica offered an in-depth discussion of OSX Lion’s sandboxing procedures in its review of the platform, and here are the basics

To play outside the sandbox, applications need “entitlements” that represent permission to access outside tools. Entitlements can include taking photos with the camera, responding to mouse gestures or creating network connections. Lion has about thirty built-in entitlements for applications to request, created and managed by Apple.

When submitting their software to the app store, developers lay out each process that an application might run, and then explain the privileges each one might have. For example, an application like QuickTime decodes video, runs audio, and accesses closed captions from a folder at the same time. Each of those different tasks is split into a sub-process with a different set of permissions – laid out by the developer before submission to the App Store. So the video decoding sub-process of Quicktime has access to the user’s screen and graphics card, but not audio settings. The audio sub-process doesn’t have access to the video card. These divisions keep the software from using system resources without permission. Unlike platforms like Android, users won’t see these processes or entitlement – they’re just for the purpose of Apple approving the software.

Users do have special powers for sandboxed applications – any action that is specifically initiated by a user doesn’t need to be okayed by Apple in advance. They can initiate special, non-entitled actions, like opening a list of recent files or saving documents elsewhere in the file system. Apps can build in these requests without asking for entitlements for them, knowing that the user is going to activate and oversee the process.

Concerns from Developers

Pushback from the development community has come from many fronts. Some developers, such as Recent Redux creator Tim Schroeder, feel that the entitlements that the apps can have do not represent the full spectrum of developers’ needs. There are two very specific use cases that are no longer possible for App Store apps – using AppleScript and file system management

Most users probably don’t interact with AppleScript on a regular basis, but it allows for many of the processes that make software work. Notification systems like Growl, which standardizes user notifications across multiple applications use AppleScript, as do hundreds of apps that allow for better music management in iTunes. On its most basic level, AppleScript is a tool developers use to exchange information between applications, and can produce Apple Events, which make programs take actions. It can run repetitive tasks, print from one application to another, or open applications. However, it also can automate file transfers or photo editing – and will no longer be usable by sandboxed applications. Instead, AppleScript will theoretically be replaced by APIs (application programming interfaces) that allow developers (and Apple) to have better control over application interaction.

Matthias Gansrigler, a developer responsible for applications including ScreenFloat and Yoink, explains how sandboxing could, without a new API, destroy one of his existing pieces of software. GimmeSomeTune (GST) downloads lyrics and album covers, as well as displaying iTunes info in a customizable window. To do those things, GST depends on a connection to iTunes via AppleScript – it extracts information about songs that are playing and uses it to download lyrics and cover art back to iTunes. Without an API, and with Apple eventually sandboxing iTunes, GimmeSomeTune will no longer be able to access the song titles it needs. Gansrigler notes that Apple has not sandboxed iTunes yet, but with it on the horizon, he’s stopping development on the software now.

File system management is the second big field that developers are concerned about. There are many existing systems used by corporations or developers that support version control or sorting of code – and they work in the background in the file system without the user’s consent. Similarly, SSH clients or FTP apps can no longer show real time file trees – which means that all moving of files or downloads must go through the open dialog. To paraphrase an Apple ad, there’s no entitlement for that.

And to make things worse, some of the entitlements are currently temporary, leading developers to be concerned that their software might break after said entitlements are revoked. Apple has promised to provide APIs to replace the temporary entitlements, but it’s not clear when those will be available. In the mean time, developers are in a terrible state of flux – trying to decide whether to continue to put time into applications that may not be able to exist by March.

Independent of the concerns about APIs and entitlements is the uncomfortable truth of the App Store as a completely new way for developers to interact with customers. Although in previous years an OS upgrade or an update could break software, those were rare to the extreme. If an application worked on a computer, it would continue to work. Now, Apple’s role in the development process means that developers have to actively coordinate with Apple to keep their software from breaking – and a slight change in the entitlement system could destroy all of the tethered software. Apple had made itself a controlling party in the application wars – and the consequences of that are still unknown. This sandbox is under the baleful eye of Apple as playground monitor. Given Apple’s willingness to ban security researchers like Charlie Miller from developer programs for publishing security holes, this increased control might not be the security boon anyone hoped for. As if that wasn’t enough, flaws in the sandboxing system have already been reported.

Trading Generativity for Security

Sandboxing represents a true security/generativity trade off. As Jonathan Zittrain said in Chapter 7 of The Future of the Internet and How to Stop It, “Most fundamentally, many of the benefits of generativity come precisely thanks to an absence of walls. We want our e-mail programs to have access to any document on our hard drive, so that we can attach it to an e-mail and send it to a friend.” Applications downloaded from the Mac App Store, in contrast to ones from the generative Internet, may not have these capabilities.

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. Certainly, not all software that runs on Mac OSX is downloaded through the app store. But as The Unofficial Apple Weblog (TUAW) put it, “There’s also the fact that any discussion that begins with ‘The Mac App Store isn’t the only way to get apps on a Mac’ inevitably ends with the ominous pronouncement ‘yet.’”

Furthermore, there are issues on the development side of generativity. It seems unlikely that developers who are concerned about the market share will develop two versions of the app – (one that’s sandbox safe for the App Store and one that includes extra features that won’t work in a sandbox). As a result, sandboxing might dumb down the feature set available to even those who choose to grab their applications from the Internet. Once programmers are playing in the sandbox, there’s little reason to develop for playground-level access again. Reactions have been slow but scared – app-makers are uncertain as to what a sandboxed future means for their applications and for their distribution.

Even in the short term, where both the App Store and regular distribution methods co-exist, Apple’s sandboxing requirements are a big deal. The uncertainty about the existence of longstanding Mac programming methods like AppleScript and Apple Events, combined with the fact that no one is sure exactly how much business the App Store will do means that the impact is totally unknown. It seems unlikely that Windows 8 or other OSs will follow suit, given that Microsoft hasn’t been pursuing the same sort of distributional model, but the new tethered nature of these applications is a significant change from the way PCs have previously operated. The only thing that’s sure is that Apple would like the future of the Mac platform to be a sandboxed one, and consumers and developers will have to adapt.

12/7/11: Edited to incorporate corrections from the comments re: Android code signing and permissions.

Responses

Feed
  1. The PC is dead. Why no angry nerds? :: The Future of the Internet — And How to Stop It says:

    November 30th, 2011 at 11:32 am (#)

    [...] Security is also a factor—consumers are willing to consign control over their code to OS vendors when they see so much malware out in the wild. There are a variety of approaches to dealing with the security problem, some of which include a phenomenon called sandboxing—running software in a protected environment. Sandboxing is soon to be required of Mac App Store apps. More information on sandboxing, and a discussion of its pros and cons, can be found here. [...]

  2. Tom Andersen says:

    November 30th, 2011 at 2:46 pm (#)

    What’s better for the user, an unsandboxed app bought/found in the wild, or a digitally signed application, also unboxed.

    Obviously its better for security to have applications signed. Sandboxing adds another level of security.

    Put another way, Sandboxing stops other malware from taking over an app and using it for bad things, while signing an app makes it far less likely that the app itself is a baddie.

    There are no? cases of any third party software hacked to get into the OS. Its not a big win, unless almost everyone has and runs some popular title. (e.g. Chrome).

    There are cases of unsigned third party software that has turned out to be actual malware.

    On the March 2012 deadline: It does not even make logical sense. As far as Apple says only updates will need to be sandoxed. So old, buggy apps can stay as long as they don’t update themselves.

    Also as others have pointed out, there is no way to sandbox something like Xcode, offered on the App Store.

    Total disaster.

  3. Chris says:

    November 30th, 2011 at 3:28 pm (#)

    Chillax, all the creative types will go to Linux and then because all the best apps (And sane permissions management) are on Linux the rest of the world will follow.

  4. Jason says:

    November 30th, 2011 at 5:55 pm (#)

    I understand the security/generativity tradeoff. But as tech becomes more and more integrated into our lives, shouldn’t we be fine adding more security?

    Let’s say that the iPhone 6 can integrate with my car and my apartment. I want my iPhone apps carefully sandboxed so that some program I downloaded can’t access my car’s engine, or my house’s thermostat, for instance.

  5. Clark says:

    December 1st, 2011 at 12:59 pm (#)

    Applescript is still usable. It’s more that you can’t have an application that sends general Applescript (that is to arbitrary programs). But you can have an application that just sends Applescript to iTunes. This is more a problem for macro or scripting services like iKey, Quickeys, or Fast Scripts.

    Modifying applications in a more robust fashion though is problematic, although apparently people are finding ways to hack around this. I believe that’s what Default Folder X does to work with sandboxed apps. Although I’m honestly not sure how they exactly got it to finally work with sandboxed programs.

  6. Lev says:

    December 7th, 2011 at 10:09 am (#)

    The statements:

    “Of course, apps distributed through the Internet and not through the Android Market are not signed, which is one of the reasons why Android platforms have more malware.”

    and

    “Android apps can either be downloaded from the Android Market, in which case, a list of permissions are visible to the user, or from third parties directly, where they are still sandboxed, but the code is unsigned and permissions are not visible.”

    are simply wrong.

    All Android apps must be signed. The OS will not run an unsigned app, even if it is downloaded directly through ADB (a tool for developers to communicate with the phone over USB) or built in to the firmware.

    Of course, there is no rule for an app to be signed by a certificate issued by some central authority that verifies the app makers identity. This is true even for apps in the Android Market, and it is up to every developer to make his own certificate for signing.

    As for displaying permissions, it can only be avoided by installing the app via ADB.
    This is something regular users rarely do. It involves installing the Android SDK and using command line tools, or having the app sources and running it from Eclipse IDE.

    If a regular user downloads an app through the browser, or tries to install an app from the SD card via an on device file manager, he is still prompted with the permissions screen and can choose not to install the app, in a way almost identical to installing an app from the market.

  7. Kendra Albert says:

    December 7th, 2011 at 7:59 pm (#)

    Lev,
    Thanks so much for your comments. A lot of the information I found about Android signing and permissions was unclear and or sketchy, so I appreciate your corrections – and have edited the piece to reflect them.

    Kendra

  8. L’ordinateur personnel est mort pour laisser place à des prisons dorées ? « SAM7BLOG says:

    December 11th, 2011 at 5:48 pm (#)

    [...] La sécurité est également un facteur à prendre en considération. Lorsqu’ils voient tant de logiciels malveillant dans la nature, les consommateurs peuvent vouloir déléguer le contrôle de leurs programmes aux vendeurs de systèmes d’exploitation. Il existe une grande variété d’approches pour gérer la question de la sécurité, certaines impliquant l’utilisation d’un bac à sable, c’est à dire d’un environnement protégé à l’intérieur duquel s’exécute le logiciel. L’exécution dans un bac à sable sera bientôt obligatoire pour les application de la boutique pour Mac. On trouvera plus d’informations sur le sujet et une discussion sur ses avantages et ses inconvénients, ici. [...]

Blog

  • Rethinking Online Culpability: The Amazon “Keep Calm” Shirts Controversy (Part 1: A/B Testing)
  • In early March, the online retailer Solid Gold Bomb provoked outrage when customers discovered that its Amazon store, which featured apparel bearing dozens of variants on the “Keep Calm [and Carry On]” slogan, included a t-shirt that read “Keep Calm and Rape A Lot.” Solid Gold Bomb generated the shirts, and Amazon offered them for sale in its marketplace. To complicate matters, it appears that Amazon doesn’t review the stores in its marketplace like a mall owner might review physical storefronts, and, particularly unusual, Solid Gold Bomb didn’t review the shirts it offered for sale: the designs were computer generated. How far, then, should blame extend? When unsupervised automation produces results that everyone regrets, how do we decide whom to hold responsible, and when do we decide to hold anyone responsible in the first place?

    Solid Gold Bomb’s official apology explained that its Amazon store featured millions of hypothetical shirts to be produced on-demand, should anyone order one. The “Keep Calm” debacle resulted from an automated script that generated words to approximately fit the design’s syntax and layout. The resulting list, says SGB owner Michael Fowler, “was culled from 202k words to around 1100 and ultimately slightly more than 700 were used due to character length and the fact that I wanted to closely reflect the appearance of the original slogan graphically.” Clearly, the vendor is at fault for failing to eliminate possible ending phrases to the Keep Calm slogan like “rape a lot” and “choke her” from a 700-word list. However, similarly automated practices regularly take place on a much larger scale across the internet. Determining accountability for these widespread and fundamental operations can be much less straightforward.

    In some ways, Solid Gold Bomb’s generation of the offensive shirts can be seen merely as A/B testing gone awry. Offering thousands of options and printing shirts to order is a way of using user behavior to cull successful products. Presumably, if one of the quasi-randomly-generated shirts began to outstrip the others in sales, Solid Gold Bomb would have adjusted its inventory and marketing accordingly.

    With A/B testing, the line between savvy capitalism and unethical business practice can get fairly nebulous. Zynga, for example, relies on a practice that CEO Mark Pincus calls “ghetto testing.” One of Zynga’s approaches to game development is to advertise games that do not yet exist, in order to test consumer response to a basic premise. Says Pincus,

    “We’ll put up a link for five minutes saying,  ‘Hey!  Do you ever fantasize about running your own hospital?’…We’ll put that up for five minutes, and the link will maybe take you to a survey, where you give us your email and we say when this comes out we’ll contact you. If you’re really doing ghetto, it says ‘404 not found’.  That’s bad. So first you try to get the heat around it, you see how much do people like it, then…”

    This isn’t all that dissimilar to Solid Gold Bomb’s approach. Like Zynga’s “ghetto-tested” games, the “Rape a Lot” shirts didn’t actually exist, and would only have been produced in accordance with user demand. In fact, Solid Gold Bomb didn’t misdirect potential buyers as deliberately as Zynga’s “ghetto testing” approach does.

    In large, computer-conducted A/B testing campaigns, it becomes impossible to demand human supervision of every output. Solid Gold Bomb’s 700-word list for generating T-shirts should have been thoroughly scrutinized, of course, but operations with more permutations of A’s and B’s seem less accountable for each potential outcome. For example, it’s hard to believe it would be within a webmaster’s responsibility—or even her ability—to make sure that every possible banner ad on every single page of a site doesn’t combine unfortunately with the page’s content.

    A/B testing is practically ubiquitous online, and most of its applications are unequivocally benign. Wikipedia, for one, famously self-published the test results of its 2010 fundraising push. Moreover, unsupervised, computer-conducted A/B testing can produce serendipitous results that no human could ever have engineered or anticipated. The popular twitter handle @horse_ebooks, for example, began as a poorly functioning spam account intended to drive traffic to an e-book site. But its garbled messages are so striking—and occasionally poignant (cf. a recent example)—that the bot currently has over 170,000 followers.

    The problem, then, is that our expectations for internet commerce haven’t quite caught up with the techniques that drive internet commerce. If a store offers things for sale that we find offensive, our typical reaction is to get mad at the store—after all, being willing to profit off an item seems to imply some kind of endorsement of that item. Today, however, these assumptions about endorsement are challenged by the ubiquity of A/B testing and other automated content generators. A “ghetto test” by Zynga might not mean that the company fully endorses a game that simulates running a hospital. Similarly, the presence of an item in the Amazon Marketplace might not be enough to presume Amazon’s approval of that item.

    [Parts 2-4 will be published over the next week]

    - Ben Sobel, Kendra Albert, and JZ

  • The Future of the Internet: Five Years Later
  • In 2008, The Future of the Internet called attention to a “sea change” in the way consumer devices interact with the Internet. “The future is not one of generative PCs attached to a generative network,” the book warns; “it is instead one of sterile appliances tethered to a network of control.” In response to the security threats posed by malicious third-party code, increasing numbers of users will likely gravitate towards gadgets “tethered” by continuous communication between product and vendor. And this proliferation of tethered computing—the “appliancization” of PCs—will deal a serious blow to the principles of generativity and free expression that drove the early Internet.

    Since the publication of The Future of the Internet, the ethos of strict appliancization has taken a new turn. In 2011, Professor Zittrain wrote an update on the book’s message: “at the time of the book’s drafting, the alternatives seemed stark: the “sterile” iPhone that ran only Apple’s software on the one hand, and the chaotic PC that ran anything ending in .exe on the other. The iPhone’s openness to outside code beginning in ’08 changed all that. It became what I call “contingently generative” — it runs outside code after approval (and then until it doesn’t).” This trend towards contingently generative models continues into the present day, and represents a shift similar in many respects to the one The Future of the Internet predicted.

    Jon Brodkin and Peter Bright’s Ars Technica op-ed on the Microsoft Metro app store offers some valuable commentary on a big development in this “sea change.” The article recognizes that “Microsoft is imitating Apple in one very bad way, by limiting the distribution of Metro applications to a Microsoft-controlled app store… by bringing Windows to tablets, Microsoft could strike a blow for openness in a market dominated by a closed system. Instead, Microsoft is bringing the same restrictions found on iPads to both Windows tablets and PCs.” As forecasted by The Future of the Internet, devices that only run approved code are gaining popularity. Metro, the curated user interface that has found its way onto Microsoft’s tablets and PCs (in the case of the PCs, alongside a fully-functional desktop mode capable of side-loading non-Windows Store applications), won’t run applications from outside the Windows Store. Moreover, the apps available through the Store are subject to a bevy of restrictions on content. With these restrictions on installable applications come the restrictions on generativity that The Future of the Internet anticipated: “lock down the device, and network censorship and control can be extraordinarily reinforced.” And, as the Ars Technica piece observes, the Windows Store’s rules would exclude critically-acclaimed content like the video game Elder Scrolls: Skyrim, simply for its PEGI 18/ESRB M rating. It isn’t hard to extrapolate, as Brodkin and Bright do, that these rules could give rise to debacles similar to Apple’s (repealed) ban of a satire app developed by a Pulitzer Prize winner.

    Though the Windows Store’s restrictions resemble Apple’s policies in many ways, there is a crucial difference: Metro-running Windows 8 products are designed as PC replacements, rather than sui generis devices like the iPad. And since Windows desktops have long been preferred gaming platforms, the theoretical exclusion of content like Skyrim from the Windows Store makes Windows 8’s emphasis on the Metro interface particularly jarring.

    With Metro, Microsoft has made a decisive move towards contingent generativity. Brodkin and Bright note that “there are security benefits to a closed app store model, particularly for less tech-savvy users who may not understand all the dangers on the Web. There are also, arguably, convenience benefits; end-users can be reasonably confident that the apps they download will work correctly and be at least marginally useful…But while these security and convenience benefits might be enough to justify the existence of a curated app store, they don’t justify the decision to make that store the only option for all users. Informed users should be allowed to install applications from wherever they want.” Brodkin and Bright prefer a system like Gatekeeper, a fixture in newer versions of Apple’s OS X, from Mountain Lion forward. Gatekeeper gives users the choice to restrict their operating system to App Store apps and outside apps that have been signed with Apple-issued Developer IDs, or open up the device to all programs, whether or not they’ve been vetted by Apple. The “Future of the Internet” Blog is fairly enthusiastic about Gatekeeper: about a year ago, a post here suggested that “the middle ground of allowing non-App Store signed code may represent the best of both worlds.” But we were quick to warn that Gatekeeper strikes a tenuous balance: “one small tweak — lose that Control-click for sideloading — and OS X could fully merge with iOS, both in functionality and in security methods.” Metro’s riff on content control could be just that sort of tweak—especially given recent speculation that Microsoft may dump desktop mode in Windows 9, leaving only Metro.

    Moreover, a contingently generative business model like the Windows Store’s carries some ethical implications that, while not damning, are certainly worth examining. Distribution systems like the Windows Store, Apple’s App Store, and the Android Market receive 30% of the sales revenue from applications sold in their stores (in the Windows Store, this cut drops to 20% after an app reaches $25,000 USD in revenue). Further restrictions on side-loading in new operating systems would drive a great deal of business towards big companies’ proprietary marketplaces—and with that traffic would come big payouts. With the uptick in store traffic that tighter gatekeeping would engender, it’s easy to imagine the equilibrium of Mac’s OS X Gatekeeper being forsaken for more restrictive, and more lucrative, operating systems. To analogize, a la The Future of the Internet: when the company that makes your computer requires you to install programs through their official store, it isn’t so different from the company that makes your toaster forcing you to buy from their bakery—and taking a cut out of every bread purchase you make.

    Even though Windows 8 PC users can still make use of a fully-functioning desktop operating system, Microsoft’s failure to include a side-loading option for the heavily-emphasized Metro interface—particularly in devices marketed as PC replacements—is a step in the wrong direction. It’s also an indication that the seas are changing in the way The Future of the Internet predicted. Given that Android’s more open approach to outside applications[1] still leaves the Android Market increasingly economically viable, Ars Technica is right to voice its disappointment in xenophobic operating systems like iOS and Metro.

    - Ben Sobel, Kendra Albert, and JZ

    [1] Though the Google Play approach to openness is far from perfect! Ad-Blocking apps were recently pulled from the Play Store, in a move that will come to illustrate just how viable it is to distribute a side-loaded Android app without any help from the Play Store.

  • Rock star RA wanted
  • I’m seeking a full-time one-year rock star research associate to engage with a variety of projects and classes, with a broad opportunity to immerse in cyberlaw and Internet topics.   Blurb below, with more information on how to apply at <http://cyber.law.harvard.edu/getinvolved/jzra>.  …JZ

    –

    Professor Jonathan Zittrain of Harvard Law School, the Harvard Kennedy School of Government, the Harvard School of Engineering and Applied Sciences, and the Berkman Center for Internet & Society, seeks a full-time research associate in Cambridge, MA for a period of one year, beginning no sooner than June 1, 2013.

    This position requires the ability to absorb large amounts of written and other media materials from various sources (including but not restricted to: original sources, scholarly articles, news articles/blogs, interviews, databases) in a short amount of time, critically analyze that material and render it forward. This could take the form of prep materials for panels, conferences and presentations; article outlines; fact checking materials; original article or paper drafts; slide decks or other digested forms. The research assistant should be prepared to help prepare materials for class sessions and syllabi, lead discussions and work with project managers to accomplish research-related goals.

    Research is often self-directed with little outside guidance beyond broad outlines and themes (though occasional targeted research assignment for a specific fact or image can be expected, and feedback is provided), so the ability to quickly critically appraise sources and identify interesting, relevant and original paths is essential. Wide-ranging interests and the ability to work on almost any issue or topic that arises is a plus, as is an ability to ramp up quickly on unfamiliar fields or topic areas. Excellent writing and editorial skills with an attention to detail are also required.

    This job is an ideal opportunity for those interested in future graduate school or law school studies, whether currently admitted or still applying to such programs.

    Over the course of the year, a motivated individual will sharpen and focus his or her research agenda and make valuable contributions (in his or her own name) to the field of cyberlaw and beyond, while being exposed to interesting thinkers in academia, industry, and government. A research associate in this position will work very closely with Professor Jonathan Zittrain and his team, assisting in a variety of research areas, e.g. ubiquitous human computing, mesh networking, and cybersecurity, as well as on topics around access to knowledge and open scholarly publishing under the auspices of the Harvard Law School Library.

    The position will not start before June 1, 2013.  As with all Berkman staff positions, this is a term position, ending June 30, 2014.

  • F-T: Don’t sue over tweets
  • I just published a short piece in the F-T in the wake of legal threats against users who tweeted or retweeted a link to a BBC report of child abuse that turned out to be wrong.  Here’s the full text –

    Those who didn’t see the false child abuse accusations against Lord Alistair McAlpine on an ill-considered BBC documentary may have instead heard about them through social media. This week, London’s Metropolitan Police suggested they might file charges against those Twitter users who sullied the reputation of the retired Conservative politician by knowingly repeating the lie that he was a child abuser. But the police may be less fearsome to the average BBC-linking tweeter than Lord McAlpine himself. Read more »

  • Taking More than Candy from a Baby
  • Update – 10/17/2012: The parties involved in the lawsuit – Speak for Yourself and SCS/PRC reached a settlement, allowing the app to remain in the Android and iOS app stores. More at the Nieder family blog.

    Original Post:

    Generativity hasn’t had a poster child — until now.

    Meet Maya, a four-year-old child who could lose her ability to speak with the elimination of an app from the iOS App Store.

    As detailed in the Nieder family’s original blog post on the subject, Maya uses Speak for Yourself (SfY), an iPad app that serves as an “augmentative and alternative communication” (AAC) device. Before finding SfY, Maya had tried multiple AAC devices, but hadn’t found one that worked for her. Read more »

About Jonathan Zittrain

jonathan zittrain

Jonathan Zittrain is Professor of Law at Harvard Law School and co-founder of the Berkman Center for Internet and Society at Harvard Law School

RSS Tweets from Z

  • An error has occurred, which probably means the feed is down. Try again later.

Blog Archives



Creative Commons BY-NC-SA Jonathan Zittrain unless otherwise noted.
Powered by WordPress using Gridline Lite.