“Pulitzer Prize-winning editorial cartoonist Mark Fiore found his iPhone app rejected because it contained “content that ridicules public figures.” Fiore was well-known enough that the rejection raised eyebrows, and Apple later reversed its decision. But the fact that apps must routinely face approval masks how extraordinary the situation is: tech companies are in the business of approving, one by one, the text, images, and sounds that we are permitted to find and experience on our most common portals to the networked world. Why would we possibly want this to be how the world of ideas works, and why would we think that merely having competing tech companies—each of which is empowered to censor—solves the problem?”

Apple’s approach is an example of a larger phenomenon. Microsoft recently released its guidelines for its new Windows 8 app store, and it looks like the company wants the same level of editorial control. From the Windows 8 Store Terms of Use:

You [the developer] may not include or submit any content that is untrue, misleading, defamatory, infringing, or harassing, that constitutes hate speech, that is or includes sexual content, that insinuates profanity, or that is otherwise objectionable.

This places Microsoft’s review team in the position of deciding what is untrue, infringing or otherwise objectionable (not to mention what “insinuates profanity” — a rather odd turn of phrase, perhaps meant to cover sanitized profanity like “sh*t”?).

There is at least one major difference between the current Microsoft store and the Apple store: Microsoft has phrased its licensing in such a way to allow free and open source software to be distributed through the store without breaking either license. In the license to customer section of its app developer agreement, Microsoft says:

Your license terms must also not conflict with the Standard Application License Terms, in any way, except if you include FOSS, your license terms may conflict with the limitations set forth in Section 3 of those Terms, but only to the extent required by the FOSS that you use. “FOSS” means any software licensed under an Open Source Initiative Approved License.

It appears that the Open Source Initiative’s licenses (which include the GPL) will then be commensurable with Microsoft’s, meaning that software developers don’t have to give up their free and open source rights (and requirements) to use the Windows 8 Store.

Like Apple’s OS X App Store, the Windows 8 store is only one method of installing applications on machines running Windows 8. Users can still download applications from the Internet or buy software elsewhere to install on their machines: “sideloading.”

Microsoft reserves the right to retroactively delete from users’ machines any apps that it no longer wants to distribute through the store. It brings to mind the 1984 Kindle incident,where Amazon removed versions of Orwell’s 1984 from purchasers’ Kindles.  ”The death of the PC” is not a claim about the withering away of the PC form-factor — but rather, the end of commonly installing software without requiring the assent of an intermediary.  Apple’s products have provided a model for this end, one now replicated in part by Microsoft.

The Personal Computer Is Dead

Power is fast shifting from end users and software developers to operating system vendors.

By Jonathan Zittrain

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.

JBAT:

- You wrote the Future of the Internet three years ago. It warned of a lack of awareness with regard to what we’re building, and the consequences of that lack of attention. it also warned of data silos and early lockdown. Three years later, how are we doing? Are things better, worse, the same?

And a follow up. On a scale of one to ten, where one is “actively helping” and ten is “pretty much evil,” how do the following companies rate in terms of the debate you frame in the book?

- Google (you can break this down into Android, Search, Apps, etc)

- Facebook (which was really not at full scale when you published)

- Apple

- Twitter

- Microsoft (again break it down if you wish)

Thanks!

JONATHAN ZITTRAIN:

Sorry this took me so long! I got a little carried away in answering –

- You wrote the Future of the Internet three years ago. It warned of a lack of awareness with regard to what we’re building, and the consequences of that lack of attention. it also warned of data silos and early lockdown. Three years later, how are we doing? Are things better, worse, the same?

It’s the best of times and the worst of times: the digital world offers us more every day, while we continue to set ourselves up for levels of surveillance and control that will be hard to escape as they gel.

That’s because the plus is also the minus: more and more of our activities are mediated by gatekeepers who make life easier, but who also can watch what we do and set boundaries on it — either for their own purposes, or under pressure from government authorities.

On the book’s specific predictions, Apple’s ethos remains a terrific bellwether. The iPhone — released in ’07 — has proved not only a runaway success, but the principles of its iOS have infused themselves across the spectrum. There’s less reason than ever to need a traditional PC, and by that I mean one that lets you run whatever code you want. OS X Lion points the way to a much more controlled PC zone, anyway, as it more and more funnels its software through a single company’s app store rather than from anywhere. I’d be surprised if Microsoft weren’t thinking along similar lines for Windows.

Google has offered a counterpoint, since the Android platform, while including an app store, allows outside code to be run. In part that’s because Google’s play is through the cloud. Google seeks to make our key apps based somewhere within the google.com archipelago, and to offer infrastructure that outside apps can’t resist, such a easy APIs to geographic mapping or user location. It’s important to realize that a cloud-based setup like Google Docs or APIs, or Facebook’s platform offer control similar to that of a managed device like an iPhone or a Kindle. All represent the movement of technology from product to service. Providers of a product have little to say about it after it changes hands. Providers of services are different: they don’t go away, and a choice of one over another can have lingering implications for months and even years.

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). The upside is that the vast creativity of outside coders has led to a software renaissance on mobile devices, including iPhones, from the sublime to the ridiculous. And Apple’s gatekeeping has seemed to be with a light touch; apps not allowed in the store pale in comparison to the torrents of stuff let through. But that masks entire categories of applications that aren’t allowed — namely anything disruptive to Apple’s business model or that of its partners or regulators. No p2p, no alternate email clients, browsers with limited functionality.

More important, the ability to limit code is what makes for the ability to control content. More and more we see content, whether a book, or a magazine subscription, represented in and through an app. It’s sheer genius for a platform maker to demand a cut of in-app purchases. Can you imagine if, back in the day, the only browser allowed on Windows was IE, and further, all commerce conducted through that browser — say, buying a book through Amazon — constituted an “in-app purchase” for which Microsoft was due 30%?

A natural question is why competition isn’t the answer here — or at least reason to not worry about the question. If people thought the iPhone made for a bad deal, why would they want one? The reason they want one is the same thing that made the Mac so appealing when it first came on the scene: it was elegant and intuitive and it just worked. No blue screen of death. Consistency across apps. And, as viruses and worms naturally were designed for the most common platform, Windows, those 5% with Macs weren’t worth the trouble of corrupting.

We’ve seen a new generation of Mac malware as its numbers grow, and in the meantime a first defense is that of curation: the app store provides a rough filter for bad code, and accountability against its makers if something goes wrong even after it’s been approved. So that’s why the market likes these architectures. I’ll bet few Android users actually go “off-roading” with apps not obtained through the official Android app channels. But the fact that they can provides a key safety valve: if Google were to try the same deal as Apple with content providers for in-app content, the content providers could always offer their wares directly to Android users. I’m worried that a piece of malware could emerge on Android that would cause the safety valve of outside code to be changed, either formally by Google, or in practice as people become unwilling to drive outside the lanes.

So how about competition between platforms? Doesn’t that keep each competitor honest, even if all the platforms are curated? I suppose: the way that Prodigy and CompuServe and AOL competed with one another to offer different services as each chased subscribers. (Remember the day when AOL members couldn’t email CompuServe users and vice versa?) That was competition of a sort, but the Internet and the Web put them all to shame — even as the Internet arose from no business plan at all.

Here’s another way to think about it. Suppose you were going buy a new house. There are lots of choices. It’s just that each house is “curated” by its seller. Once you move in, that seller will get to say what furnishings can go in, and collects 30% of the purchase price of whatever you buy for the house. That seller has every reason to want to have a reputation for being generous about what goes in — but it still doesn’t feel very free when, two years after you’re living in the house, a particular coffee table or paint color is denied. There is competition in this situation — just not the full freedom that we rightly associate with inhabiting our dwellings. A small percentage of people might elect to join gated communities with strict rules about what can go inside and outside each house — but most people don’t want to have to consult their condo association by-laws before making choices that affect only themselves.

The U.S. government uses a PC control switch? The U.S. federal government obtained a temporary restraining order in April that allowed it to send to private computers unwittingly part of a massive criminal botnet a command that disabled the malware. In the past, the government has cut off or seized the command-and-control servers and computers that run a botnet, but here – without notice, because federal agents were still trying to collect the IP addresses of infected computers – the government issued a command to personal computers owned by innocent targets of the Coreflood botnet. Arguably, since Coreflood steals private data and loots victims’ bank accounts instead of just generating huge amounts of spam, the government had sufficient justification to order citizens’ (and non-citizens?) computers to kill the program. But in addition to concern that the command itself might unintentionally damage some private machines, such a path may be quite slippery. After all, prevention may be cheaper than disease; why shouldn’t the government push security software to all personal computers? And why shouldn’t it monitor citizens’ online activity to make sure they aren’t downloading programs from malicious sites? Nonetheless, how different is the command in this case from required residential building and health standards or mandatory vaccinations for schoolchildren? The government regulates personal safety in the real world when it implicates the broader public good, why shouldn’t it do the same online? And in the end, an individual can avoid running the command on his computer (and dodge the botnet risk, too) by simply disconnecting from the Internet.  Of course, that makes the computer slightly less useful.  The phenomenon is reminiscent of this Wired account from 2003, though note the reporter’s credibility appears to be in question.  (!)

Google’s questionable Grooveshark takedown. Last week, the Electronic Freedom Foundation criticized Google for removing the popular music service Grooveshark’s app from the Android Market. Google has said that it was responding to an RIAA complaint but has not explained the basis of that complaint. The company did not require notice before the takedown as provided for by the Digital Millennium Copyright Act. If the complaint was grounded in copyright, EFF noted that Google’s actions departed from its longstanding position of requiring such valid notice before takedown. Because the move coincided with Google’s testimony before the Senate Judiciary Committee, EFF speculated that it was designed to mollify any Congressional skepticism that Google was not committed to copyright enforcement.  Note that apps can still be added to a phone without having to go through the Android Market.

More consumers demanding iPads in place of laptop PCs. Last quarter, Apple’s profits exceeded Microsoft’s for the first time since 1991. Overall PC sales declined 2%, consumer PCs dropped 8%, and netbooks –  the inexpensive and mobile generative PCs most similar tablets like the tethered iPad – fell 40%.

Translating iOS to WP7. Meanwhile, Microsoft is contesting Apple’s dominance of the tethered device market. Microsoft now offers a tool that helps developers convert their iOS apps to Windows Phone 7 apps. It maps the WP7 application programming interface – the set of definitions and rules an app uses to communicate with the phone’s operating system – onto the iOS API, making it easier for developers to port their apps to WP7, giving Windows Phone 7 users access to more apps, and allowing Microsoft to compete with Apple in app marketplace size and range sooner.

And a related discussion of generative PCs and tethered devices including thoughts on JZ’s thesis in the book, as well as a take on his concerns about crowdsourced work.

—Jennifer Halbleib

Although there was initially speculation that Apple pulled the Wikileaks app because it either was “not very useful” or was a paid app that solicited charitable donations and therefore contravened the Developer Guidelines (pdf), Apple later justified the app’s removal under other provisions of the Guidelines: “Apps must comply with all local laws and may not put an individual or group in harm’s way.” The app’s developer had promised to donate one dollar from each $1.99 sale to Wikileaks, giving people a way to support the organization after Paypal, Visa, and MasterCard stopped facilitating donations to the non-profit because of its questionable activities. Apple’s reluctance to serve as a conduit of funds for Wikileaks, no matter how nominal each individual donation, is a possible secondary motivation for removal. The app raised $4443 for Wikileaks while it was available in the App Store.

The app can still be downloaded onto jailbroken iOS devices from Apptrackr, and apps that provide access to Wikileaks documents are available for Android phones. In addition, the App Store itself has a handful of apps that give Wikileaks news and updates, but presumably don’t let users look through the leaked information. Nevertheless, Apple’s unilateral control over which apps users can run on their iPhones and iPads again raises concerns that a closed platform enables censorship either by Apple directly according to its standards or by government pressure on the company. And since Wikileaks posts appear to be both newsworthy and legal (so far), pulling the app may well have a chilling effect on other news outlets considering publishing controversial information of public interest to their iOS apps. For example, would Apple also pull the New York Times app if the newspaper posted a story on the leaked cables to its app?

These concerns, both disturbing and credible, will grow as more people get their news from apps run on closed platforms rather than print or Web sources. But the (hopefully farfetched) nightmare scenario is a universally adopted closed platform with a slick, free Wikileaks app… that gives users access to documents that have been surreptitiously altered to remove or even provide false information. A similar worry exists with search engines or ISPs that are overwhelmingly dominant or government-enforced monopolies. If such a search engine doesn’t index the Wikileaks website (or indexes a modified fake site instead), the site may as well not exist, unless a user knows where to look. And incidents during the recent Belarussian election highlight how a national ISP could achieve an analogous result by redirecting requests for a legitimate independent news site to a fake one.

In the past, open, distributed media in the U.S. has made such tactics impractical. And there still may be little chance that extreme deception of this nature could occur in the U.S. as private companies don’t often have an incentive to mislead their customers and the government is constrained from doing so. Yet it’s worth thinking about, both out of concern for citizens of other countries and because our government does on occasion employ technology to covertly alter reality by, for example, wiretapping or other surveillance. Surveillance is distinguishable in that it is directed against a particular individual or group, usually requires a warrant, and, while deceitful, simply collects information instead of affirmatively providing misinformation. But if authorities have probably cause, is a warrant to push an app “update” to a specific individual that provides inaccurate information to thwart criminal activity or facilitate capture – say, an altered fight schedule or public transit timetable – acceptable? In a very small minority of cases courts have enjoined the publication of certain information, but is there ever a situation where, if feasible, it would be permissible for the government require a company to mislead the general public? We may never need to answer these questions, but Apple’s response to the Wikileaks app is a step in their direction.

—Jennifer Halbleib

For every smartphone, someone, somewhere has an app kill switch. This week, Microsoft discussed the circumstances in which its kill switch could be flipped on the Windows Phone. It emphasized that pre-screening apps and subsequent removal of any remaining risky apps from the Market Place were preferred tools for addressing privacy and security concerns, characterizing the kill switch as a scram in case of impending meltdown.

i(Gold)Bricks. An iPhone 3G user has accused Apple of a different type of killing. In a lawsuit filed last week, she alleges that Apple intentionally used the iOS 4 update to debilitate iPhone 3Gs in order to increase sales of the iPhone 4. Part of her claim is based on the charge that Apple didn’t allow consumers to revert to a previous version of iOS after experiencing poor iOS 4 performance on an iPhone 3G — at least without voiding the warranty by jailbreaking the phone.

What are the limits on employee Internet policies? The NLRB is suing a Connecticut company, alleging that the employer fired one of its workers because she posted a negative comment about her supervisor on her Facebook page from her home computer. According the Legal Times, the NLRB is challenging a provision of the policy that the union says prohibits “depicting the company in any way over the Internet without company permission.” The EMT service contends the woman was fired for “multiple serious issues.”

A picture is worth a thousand dollars in traffic tickets. Next generation speed cameras not only calculate a driver’s speed, but also check to see if his insurance is current, his seatbelt is on, and he’s keeping a safe distance from the car in front of him. Some jurisdictions are apparently having difficulty making money off their speed cams. Upping the number of violations per picture should help.

Market Captcha. In the grand capitalist tradition of slapping an ad on any exposed surface, NuCaptcha is selling squiggly commercial space. Website visitors will have to type in a company slogan to proceed. Several prominent companies have signed up. I wonder if sellers of knock-off Rolexes and cheap pharmaceuticals will as well.

—Jennifer Halbleib

Zak Tanjeloff, chief executive of the app’s creator, DLP Mobile, said in a news release: “This app is certainly controversial, but can be helpful to people in relationships where this type of monitoring can be useful.”

Controversial, indeed; I think it’s awful and here I am spreading the word about it.

It was up in the Android app store until the NYT inquiry got it taken down.  The company behind it didn’t bother with a counterpart for the iPhone:

Mr. Tanjeloff said in a phone interview that his company had decided to build the SMS application for the Android platform because it would not need to be reviewed before it reached users.

“We can’t build it for the iPhone because it wouldn’t make it past the App Store approval process,” Mr. Tanjeloff said.

Here, then, a certain generative trade-off, one I’ve described more with viruses and trojans from afar than a fellow phone-user’s malice.  With the iPhone, apps like these just aren’t available — at least without the stalker having to jailbreak the targeted iPhone first.  On the more generative Android, it’s simply easier for bad stuff to brazenly find its way onto the platform since Google isn’t as obsessed with curating the selection of software for the phone.  And with Android, the official apps market isn’t the only source for software — so the banning of SMS Replicator there doesn’t exclude it from the phone; the enterprising stalker can install it from elsewhere.

Such software has been available for a long time on PCs, and few if any would say that its existence would be reason to upend the generative PC environment.  But the competition between Android and iPhone highlights that generativity really does come with some costs.  Should there be a well engineered Android worm that hops from phone to phone — either directly or by going through the SMS or email addressbook of each victim and recommending installation to the next — those costs will be even more drawn into focus, and the temptation may arise quickly to update Android not to be so open — or to exercise a kill switch targeting a particular piece of code.

It suggests the need, at least, for some easy-to-use auditing software for generative (or partially generative) platforms, Android, iPhone, and PC alike, so users can have a sense of what’s going on inside the device — and what data is going in and out.

To be sure, the generative dilemma trading off openness and security interests me because it runs so deep.  More superficial security problems can happen even on more locked down platforms, such as today’s revelation by Wired that a quick key sequence can apparently bypass an iPhone’s four-digit security code.  iOS update no doubt soon to follow.

Addressing the zombie invasion. U.S. officials are evaluating an Australian plan that targets the botnet epidemic. In particular, the American government is eying provisions that allow an ISP to notify customers with infected computers — since botnets typically run in the background of a user’s own applications, often the consumer is unaware that her PC has been taken over — and perhaps even quarantine maliciously co-opted machines by limiting online access. As the FOI book echoed in 2008, such a program increases security without resorting to perfect enforcement and may also encourage ISPs to provide consumers with tools to disinfect their computers, either as part of the service plan or for an additional fee.

iOS developer guidelines relaxed enough for torrent apps? Last week Apple approved its first BitTorrent app. But it turns out that Apple didn’t intend to allow torrent apps. Instead, the developer avoided the term “torrent client” in the app description, temporarily evading rejection. When Apple became aware of the app’s capabilities, it removed the app from the App Store.

Android apps share information. A Duke-Penn State-Intel study using the new TaintDroid tool revealed that half of thirty randomly selected popular Android apps send personal information such as location or phone number to ad networks, sometimes with surprising frequency. When an Android owner downloads an app, he or she has to give permission for the app to collect personal information. But from that sole initial disclosure it’s usually not clear when information will be accessed and how it will be used. Privacy policies are often unintelligible. Hopefully utilities like TaintDroid will soon be available in downloadable form to allow Android (and iPhone) owners to monitor in real time what information their apps are accessing.

Italy demands that Apple remove an offensive app from the App Store. Child pornography? No. Graphic violence? Not so much. Italy is upset that a travel app characterizes the country as the home of the Mafia (also of pizza and scooters). Since Italy knows Apple can remove the app, it may feel entitled to demand that the company do so whenever Italians’ dignity is the least bit bruised. In a walled garden, the country of Da Vinci need not cultivate perspective.

RIM jumps on the anti-fart app bandwagon. RIM takes the position that apps that keep users coming back and convince them to purchase upgrades or additional content are more valuable to RIM and developers than fart apps. But should the value of an app be determined ex ante by device-makers or set by user behavior? Good search and rating systems seem like a better way to run an efficient app store — one that allows both apps that provide “ongoing entertainment value” and inexpensive, one-off apps that may serve important, if temporary, functions. (Ever unexpectedly have to entertain a child for an afternoon?) Still, nice of CompuServeRIM to tell us what we want. Because listening to users and developers isn’t a plan that’s going to work.

Can a wireless provider block texts it doesn’t like? New York federal court was presented with that question in a case where T-Mobile blocked all texts from a texting service because one of the service’s clients provided information via text on legal marijuana dispensaries in California. Under the recently proposed Google-Verizon net neutrality principles (analyzed here), a wireless company would have latitude to discriminate based on the sender, recipient, or content of the message as long as its practice is transparent. But it’s hard to see how the discrimination in this case is required because of the “unique technical and operational characteristics of wireless networks.” We’ll have to wait to see how courts address the issue as the parties have settled the case. Although the full terms of the agreement weren’t disclosed, it “requires T-Mobile to stop blocking the New York-based EZ Texting service’s thousands of clients, if they meet T-Mobile’s approval. The medical-marijuana info service, which used texts to tell its users where the nearest medical-marijuana store was, remains blocked.” (emphasis added).

The future of HR. Social Intelligence will help potential employers determine whether you are a good hire and monitor you (with real-time updates) when you’re on the payroll by trolling your public social network profiles. “[C]ompany spokespeople emphasize liability. What happens if one of your employees freaks out, comes to work and starts threatening coworkers with a samurai sword? You’ll be held responsible because all of the signs of such behavior were clear for all to see on public Facebook pages. That’s why you should scan every prospective hire and run continued scans on every existing employee.”

iPhone expression that’s more than skin deep. Children and adults with disabilities affecting speech are converting their iPhones to alternative communication devices. Smartphone apps that are mobile, easy to use, and even cool give a voice to autistic kids and stroke victims alike.

—Jennifer Halbleib

Unfailingly quotable Steve Jobs summed up Apple’s position on third-party development tools when the restrictions rolled back this month were originally instituted in April: “We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.” At the time, many Internet news outlets considered the new rules a nativist response to the release of an Adobe cross-platform app development tool, which allows programmers to write apps once using Flash and then create variations for multiple mobile operating systems. Now Adobe’s tool and others like it are back in the game. The major remaining restriction, that an app can’t download any code, appears legitimately motivated at least in part by security concerns. But Adobe notes that Flash content in apps or the Safari web browser still is not allowed — developers can create apps with Flash but users can’t view Flash video.

Other restrictions imposed by Apple this year limited the analytic information an app could collect when the developer used an advertising network owned by a company that also made a device or an operating system. For example, AdMob is owned by Google, as is Android, so developers using AdMob couldn’t access the same information as, say, those using Apple’s iAd. Developers use ads to pay for free apps and need analytics to accurately target the ads to users. In an important corollary to loosening restraints on app developers, Apple now seems to permit unrestricted collection of analytic information by any mobile ad platform. If true, it will allow more mobile ad companies, and Google and AdMob in particular, to compete for app developers in the iPhone market.

Although the review guidelines are behind the iOS developer fee pay wall, they quickly leaked onto the Web. Apple must still approve every app, but now the company is providing some ex ante guidance for developers. However, the wording of the press release and guidelines is vague and broad, and terms are undefined. What’s “amateur”? To qualify as not amateur, does an app either need to look professional or be an idea so cool that Apple doesn’t care how polished the app is? The judges at Apple retain substantial discretion in interpreting the guidelines. But now at least their interpretation is confined within more precise parameters than Steve Job’s “porn, malicious, bandwidth hog, illegal, privacy, and unforeseen.” The judges are human, so they will make mistakes. But if they’re also good judges, their mistakes will be fewer in number, both because they have the guidelines in hand — which may have been true before the guidelines were public — and because developers will work to adhere to the guidelines and avoid the grief of getting rejected. Already, highly anticipated apps like those with Google Voice are being reinstated under the new regime.

Nevertheless, the powers-that-approve at Apple won’t be entirely “good” from the point of view of users, because these judges are never entirely accountable to consumers. In a perfectly free market they would be, but not in a world of two-year contracts, exclusive service providers, and trapped data. Apple must take into account corporate interests, regulatory concerns, input from their business partners, developer needs, and the like, as well. Not that perfect accountability is necessarily desirable; most U.S. judges are life-tenured, free from the control of the citizenry (mostly). This situation allows them to make decisions for the long-term benefit of society rather than being pressured to give into immediate demands that will cause bigger problems later. But federal judges are insulated from all constituencies, not beholden to several masters. iOS users and the developers that program for them know that Apple takes other considerations into account besides users’ first-order best interest. Perhaps Android will challenge Apple’s curation with a search-based approach that relies on users’ judgment of what apps they find valuable and what is the appropriate number of, say, fart apps.

That said, the shift in Apple’s policy is reason for optimism. While Apple can change its mind and rescind the changes, as JZ notes, once you crack open a platform, even just a little, it’s hard to go back. As soon as users and developers rely on the increased freedom, they will consider it unfair of Apple to backtrack. Perhaps Apple is slowly relinquishing control of the iOS platform.  First came the SDK, then more liberal development rules, what’s next?

—Jennifer Halbleib