Google recently announced an update to their Google Play Developer policy, essentially changing how permissions related to SMS and Call Logs were handled. This change limited which apps were allowed to ask for these permissions—only apps that have been selected as the user’s default app for making calls or sending text messages will be able to access call logs and SMS, respectively, with few exceptions.
Update 1/4/19: After adding task automation apps to the list of exceptions from the new SMS and Call Log permission restrictions, the developer of Tasker has announced that his app has been approved to use those permissions. Hence, no functionality will be lost in Tasker. However, other apps such as the Tasker developer’s Join app are still under review.
Background
The intent of the change is to protect the often inattentive average user who went around granting these permissions to each and every app that asked for it, irrespective of whether such an app actually needed such permissions for its advertised functionality. Once granted, users would rarely revoke these permissions from apps—resulting in many apps having full access to a user’s SMS and call log history even if they no longer need access. The blame here rests as much on the neglectful user as on the app developers who abused such neglect to gain access to private information. However, Google is choosing to protect users by pushing the burden of proving a need to access these permissions onto developers. Thus came Google’s new policy update, restricting access to only apps that have been set as the default for Phone and SMS functionality, and thereby restricting access to only such apps that the consumer actually used for those purposes.
Unfortunately, this policy change has some collateral damage. Developers offering useful functionality that required such permissions now need to submit a Permissions Declaration Form to Google within 90 days after the change explaining why their app needs to use the SMS and/or Call Log permissions to receive Google Play approval. But, if Google deems the use of these permissions to be non-essential to the app, the form will get rejected. This, in turn, forces the app developer to remove useful functionality from their service to remain on the Play Store.
You should only access Call Log or SMS permissions to enable your app’s core functionality.
Core functionality is the main purpose of the app. It’s the feature most prominently documented and promoted in the app’s description; no other feature is more central to the app’s functionality. If this feature isn’t provided, the app is “broken” (for example, won’t perform as a user would expect).
Google does provide for exceptional scenarios, whereby temporary exception to apps that aren’t default SMS, Phone or Assistant handlers may be given when:
- Use of the permission provides core app functionality to users
- There is currently no alternative method to provide the core functionality
Exceptional uses listed by Google includes Caller ID, spam detection and blocking; connected device companions; cross-device synchronization or transfer of SMS or calls; SMS-based financial transactions and related activity; and proxy calls (VoIP calling). If the app falls within these exceptions, Google may grant approval, implying a discretionary power in the hands of Google.
Summary of changes to the use of SMS or Call Log permissions. Source: Google Play Academy Live: 2018 October policy updates & top issues deep-dive
Impact
However, this approach has its own flaws. Any incidental functionality that requires such permission, despite its usefulness to the user and the bonafide intention of the developer, is liable to be rejected right off the bat. Thus if an app provides several features, and one such important feature requires either of these permissions, the entire app will be rejected. In such a case, the feature will get classified as an incidental function and not a core function, leaving the developer with little hope of being approved under the exceptions (as the exceptions also related to “core app functionality”).
This is what is happening to several popular apps which needed such permissions to perform certain tasks which do form part of their “core functionality”, but are incidental functions when looked at from a very broad and zoomed-out perspective.
For example, EasyJoin allows a user to share messages, links, files, notifications and clipboard contents between devices. The Pro version of the app allows for sending SMS and managing phone calls from a remote device, and is one of the reasons why a user would consider purchasing the Pro version of the app. As made necessary by the policy update, the developer of the app filled out the Permissions Declaration Form and was greeted with the following response:
I’ve reviewed your request and found that your app, Send files, clipboard, SMS & more – EasyJoin “Pro”, net.easyjoin.pro, does not qualify for use of the requested permissions for the following reasons:
- The declared feature {Caller ID, Connected device companion apps} is allowed; however we determined it to be unnecessary for the core functionality of your app.
- The declared feature {Initiate a text message} is not allowed.
Similarly, the developer of ACR Call Recorder mentioned in a Reddit thread that his application was also rejected (based on the reasoning given for EasyJoin Pro) because of this policy change.
Another popular app, Tasker, is also being majorly affected by this change and is likely to lose out on some of its core functionalities and appeal simply because the functions for which SMS/Call Log permission is requested would tantamount to an incidental function from the broader perspective that Google is seemingly using for classification. The core functionality of Tasker would be to do anything, for which an incidental function would be to initiate or automate a text message or a phone call. But sadly, Google does not think along the same lines [emphasis supplied]:
I’ve reviewed your request and found that your app, Tasker, net.dinglisch.android.taskerm, does not qualify for use of the requested permissions for the following reasons:
- The declared feature, “Initiate a text message, Initiate a phone call, and Automation of an unlimited number of situations based on calls, SMS and MMS” are ineligible for these permissions.
- The declared feature “Caller ID, spam detection, and blocking and Cross-device call or SMS sync & send” are allowed; however we determined it to be unnecessary for the core functionality of your app.
- The declared feature “Caller ID, spam detection, and blocking and Cross-device call or SMS sync & send” are allowed; however we were unable to verify this feature during app review.
- Your app has default handler capability that doesn’t match with your declared feature.
- The default handler features are allowed; however your app does not appear to prompt the user to be a default handler prior to requesting related permissions as required by the policy.
The end result of such a rejection is that the app will not be listed on the Play Store. To get the application listed on the Play Store, the developer would need to remove the permission entirely from app, thereby removing key functionalities that users have already paid for.
Some apps, like Call Recording apps, would be crippled by this change. Other apps would need to decouple the SMS/Call functionality into a separate app (to ensure that such function now becomes a “core functionality”) and then resubmit both the apps to Google with explanations. That is a lot of work, and there is no guarantee that this approach also leads to an approval.
Whether an app needs the Call Log or SMS permission is being determined by Google, and not the developer or the users of the app. The discretionary power held by Google is very wide and does not take the consensual and intended use of the app into account. What is deemed “core functionality” is left open for interpretation in the hands of the human representative that is to adjudicate upon the request—leaving the doors wide open for arbitrary discretion and prejudice.
Yes, there is a possibility that some developers may not have been able to adequately explain why their apps require these permissions. However, it is difficult to not see the growing trend of restrictions being placed on developers without adequately clear guidelines on what is acceptable and what is not acceptable. Forcing developers to abandon useful features is a loss for the users who paid for such features. While protecting the negligent, casual user is Google’s job too, should such protection be at the cost of the informed and consenting user?
We hope Google revisits their guidelines and lays down clearer criterion for the exercise of its discretion. A Google Issue Tracker page has been created to document this issue.
EasyJoin "Essential": Send files, clipboard & more (Free, Google Play) →
Call Recorder - ACR (Free+, Google Play) →
0 comments:
Post a Comment