[continued from part II]
Here is a scenario when users and application developers have directly opposed interests, and the platform owner is put into a position of having to arbitrate between these two actors.
Suppose our hypothetical consumer comes across a new mobile application they consider useful. It could boost their work productivity, help connect with friends or provide some entertainment. This person wants to install and user the application on their phone to extract that “utility.” Meanwhile the company who authored that application is interested in deriving revenue from providing that useful application. In an ideal market, consumers can always negotiate and choose between:
- “Paid” version where the consumer pays upfront for installing the application and/or pays over time for continued access to the cloud service associated with that app. This is the more customary notion of payment where money exchanges hands.
- “Free” version funded by targeted advertising and user-data mining. As with other examples of seemingly “free” lunch, consumers pay dearly in privacy and attention, while avoiding monetary costs. This could involve collecting location information to display advertising based on geographic proximity to stores for example.
Developer’s ultimatum: take it or leave it
Indeed many application have this dual cost structure. Often there is even an upsell within the free version, giving users the opportunity to upgrade to paid version and get rid of advertising nuisances. But sometimes the decision is made unilaterally by the application developer committing to one of the two models. There is no version of Facebook or Twitter where users can buy their privacy outright, paying to opt-out of data collection and behavioral advertising. For whatever reason Facebook and Twitter have decided that the optimal business strategy is to not charge users for accessing the service, but instead monetize their eyeballs indirectly via advertising. From a transactional perspective, there is nothing wrong or unfair per se about this, as long there is transparency into the terms of the arrangement. Most reputable software publishers will describe in painstaking terms exactly what nefarious data collection practices are implemented in their terms-of-use and privacy policies– which everyone clicks through without reading. Still all that legalese counts as notice, and clicking “I agree” constitutes informed consent on the part of the consumer.
Is there another option available to users dissatisfied with the status quo? There are two ways to interpret that question.
- Capability, or “can it be done?” Can users continue to enjoy the “useful” functionality provided by an application while opting out of its harmful data-collection practices? This is a clear-cut question of facts, which depends on the nitty-gritty implementation details of the platform/hardware where the app runs.
- Ethics, or “should it be done?” Assuming we answer the first question in the affirmative, is it fair game for users to take such measures in the name of privacy “self-defense”? Many people would frown upon exploiting some trick to get paid applications for free. What about interfering with the business model of the developer by installing the application while disabling its ability to be monetized? Here we quickly get into gray areas. There is a vocal group arguing that no one is hurt by pirating commercial software; surely blocking monetization can not be worse than outright stealing a copy of free (in the beer sense) software to begin with?
Off with their permissions
Android permissions and AppOps-type functionality goes to the heart of the first question. If users could start selectively disabling permissions, instead of having to agree wholesale to take-it-or-leave-it ultimatum from the application developer, they could have the best of both worlds. They can install and use it to get the benefit of the features without having to pay for the privacy harms caused by unwanted data collection.
As the second post pointed out, AppOps is not necessarily the ideal solution here. Bluntly taking away privileges can be disruptive, introducing new error cases into an application that were not anticipated by its developers. The only way this could work is if the revoked privilege is rarely used or only used under user direction. For example an application may never resort to recording audio or taking pictures unless the user presses a particular button to invoke some specific feature. In that case removing its microphone and camera permissions will not interfere with ordinary usage, while guaranteeing that the application will not be snooping on conversations and scenes in its vicinity. Of course if the application is so predictable and well-behaved , there is no need for AppOps in the first place. Same improved privacy outcome can be obtained by not pressing that button. Meanwhile the more unruly applications that attempt to capture audio/video randomly and never expect to get an access-denied error (because the developer declared upfront in the application manifest they need those permissions) will quickly run into trouble and crash.
Luckily there are more subtle ways to revoke access without breaking applications. Part I described one approach that creates the illusion of access granted– no unexpected “access-denied” errors to confuse the application– while returning either no data or completely fabricated bogus data which bears no relationship to the user. For Google it would be fairly straightforward to implement some variant of this as an improvement over AppOps. But would it be a wise move? The answer depends on which side one takes.