Compatibility vs accuracy
Preceding post sketched a hypothetical solution to the AppOps compatibility problem by fabricating bogus data to appease an application when the user has declined permission. This approach does not complicate life for our (hypothetical) beleaguered developer: there are no security exceptions or bizarre error conditions introduced. All of the regular code paths in the application continue to work, only the data returned is “incorrect” in the sense that it does not correspond to the actual state of the world. This model is not entirely transparent; an application could discover that it is in fact in being lied to, depending on the model for generating the fake data. As the saying goes, liars need a good memory. If GPS is reporting a bogus location, this has to be self-consistent over time– no sudden teleportation across the globe– and also consistent with other signals such as IP address of wireless networks the device connects to. Skeptical applications could try to cross-check the reported location against such external indications and user behavior to detect fabrications– looking for restaurant recommendations in San Francisco when the location “reported” by the system is New York.
Still, the design subtly takes away the burden from developers worried about missing permissions and shifts the balance of power back to users. They are now empowered to reject inappropriate permission requests– just like they could with the more blunt instrument of AppOps– without fear that tweaking permissions may break applications.
Why does Android not implement such a model where permissions can be declined without the unpleasant side-effects of AppOps? That question can not be answered at the technology level. It is more a function of competitive dynamics, of the delicate dance between platform providers vying for expanded market share (in other words Google) on the one hand, and software publishers writing applications that will make that platform more appealing.
Put bluntly, the interests of different actors are not always aligned.
- Users: Users want to derive maximum benefit from their devices at lowest cost. “Cost” in this context includes not only direct monetary impact– upfront purchase price of phone, ongoing purchases for apps, services and content– but also intangibles such as privacy and quality of experience. For example maintaining control over personal information and not being subjected to intrusive advertising are equally relevant concerns.
- Developers: Commercial developers are typically driven by profit maximization motives. In the short-term that could entail seemingly contradictory actions such as giving away content without generating any revenue. But these are best viewed as tactical steps supporting a long-term strategy focused on monetizing the user base. That monetization could take place directly by charging for the application and associated services (such as in-game purchases) or it could be indirect, when free content is subsidized by advertising.
It should also be pointed out that this is not the only type of developer publishing mobile applications. Hobbyists and researchers can be far more interested in building reputation or releasing software out of altruistic motives.
- Platform owner: Google for Android, but exact same calculus applies to Apple for iOS and MSFT on Windows Phone. Seeks maximum market share for its platform that is consistent with the licensing strategy. For example Android is given away for free to OEMs but there is a compatibility certification to qualify for using the trademark, as well as getting access to Google Play store. Apple by contrast uses an autocratic walled-garden model, where third-party hardware manufacturers can not build handsets using iOS. Microsoft used to charge for Windows Phone– inexplicable for an upstart OS trying to get traction– but that strategy may be changing.
Looking more closely at how mobile platforms gain market share, we find the platform owner with divided loyalties, trying to appease multiple constituencies. On the one hand it helps to do right by users. On the other hand, privacy and security considerations are only one of the factors contributing to such decisions. (In particular, it is an often lamented fact of life in the security community that better privacy does not help sell products the same way shiny features can. It remains to be seen to what extent the rude-awakenings inspired by Edward Snowden can change that.) There is an even bigger market distortion caused by the fact that users do not directly pick a platform. That decision is often made by other participants in the ecosystem, such as handset manufacturers who pick what OS to install on their phones– a decision the user can not easily override– and wireless carriers who wield influence by cherry-picking devices to run on their network and subsidizing/promoting the favored ones.
For all participants with a say on whether they will be using Android, iOS, Windows Phone or Blackberry, one important criteria is availability of applications. The greater the selection of apps available on that platform, the more attractive it becomes for users/carriers/handset-manufacturers. This in turn breeds a positive feedback loop: developers want to maximize their audience, so they will primarily target their applications at popular platforms.
In the next post we will argue that Android permissions– specifically ones allowing developers to monetize apps in ways users find objectionable– creates a textbook example of clashing interests between software publishers and users, forcing the platform owner to pick sides.