Personal Data Protection has become a red-hot topic after GDPR adoption, and it doesn’t lose its applicability. The main reason for this is the practice of world-wide top-companies which started to implement GDPR provisions and even try to do more than is required to protect the privacy of their clients. Probably the most considerable of recent changes for developers was the introduction of a new Google Play Policy for the providing SMS & Call Log Permissions in the apps.
SMS & Call Log Permissions is a group of permissions provided by users by which they give access for the app to their SMS and Call logs. Google Play leaves open the listing of these permissions and only gives examples of the most popular of them:
for SMS, they are such as:
WRITE_SMS, SEND_SMS, READ_SMS, RECEIVE_SMS, RECEIVE_MMS, RECEIVE_WAP_PUSH;
for the Call Log, they are such as:
PROCESS_OUTGOING_CALLS, READ_CALL_LOG, WRITE_CALL_LOG etc.
So, if your app has such or other similar requests in the manifest and sends them to users for access to their SMS or Call Log, then you, as a developer, shall comply with specific requirements for sensitive permissions of the Google Play.
What are the general requirement for permissions
In general, Google Play has declared its policy of limiting “unnecessary” permissions all along ago. The general requirements for developers were and still are such as:
• the plainness of the request for the user;
• the necessity for performing the main functions of the app (core app functionality);
• discoverability of permissions, forbiddance to use permissions for hidden, unsupported or prohibited functions or purposes;
You can see more about GDPR at different stages of the customer journey here:
Under the influence of GDPR, these general requirements now also establish that:
• Permissions should be asked within a context, that is, through a step-by-step authorization (principle of transparency of GDPR);
• The data should only be used for the purposes for which the user has given his or her consent (principle of purpose limitation of GDPR); and
• If there is a need to use the data for other purposes, not covered by previous consent, then it is necessary to get a new consent of the user (lawfulness + purpose limitation of the GDPR).
What has changed for SMS and Call log permissions?
Along with the general requirements that exist for all platform apps, Google Play has introduced a scope of new requirements that restricted the ability to access the SMS & Call Log, and, therefore, to collect user personal data through the apps.
It was determined that only applications that are installed by users as the default handler now can have the SMS & Call Log Permissions. So, other applications (that cannot be installed as default handlers) should remove these permissions from the app and mustn’t ask them.
After the 9th of March, 2019, the applications that hadn’t meet the requirements of the platform, began to be banned. Even some super popular apps (such as Tasker) were blocked, and it has made angry a lot of users. Actually, it’s important to notice that Google Play has blocked many fee-paying apps that were very useful, although they were not the default handlers.
Because of criticism, Google Play decided to develop a system of exceptions. But banning hasn’t become less frequent because of this, as most developers are not aware of how to prove that their apps fall under such exceptions of the Google Play Permissions Policies.
So, what is requested by Google Play?
Under the new policy, developers of existing and new apps with SMS or Call Log Permissions, were required to submit Permissions Declaration Form, so that the platform officially allowed their existence on a platform with such a functionality, that is, provided its approval.
If the developer had not removed SMS & Call Log from the app and
(i) had not submitted Permissions Declaration Form, or
(ii) did it with inaccuracies or with false info, or
(iii) his or her app just hadn’t met the new requirements;
then the platform banned their apps. As it was noted, firstly it was permitted only to the default handles to have such permissions, so the first banning waves were really widespread.
After the first waves, there were created some exceptions to the general rule under which the platform started to give temporary permissions to use SMS & Call Log Permissions. As Google Play itself notes, “these exceptions are rarely done and not available to all developers.”
In order to obtain temporary permission, two basic requirements should be met:
(a) SMS & Call Log Permissions should be required for the core app functionality.
(b) there should be no alternative method to perform core app functionality.
Examples of situations in which temporary permissions are currently given by Google Play are the following groups:
(і) Account verification via phone call
(іі) Backup and restore for users
(ііі) Enterprise archive, CRM (Customer Relationship Management) and/or device management
(iv) Caller ID, spam detection, and/or spam blocking
(v) Connected device companion apps that enable sending and receiving of SMS or calls
(vі) Cross-device synchronization or transfer of SMS or calls
(vіі) Device automation
(vііі) SMS-based financial transactions (e.g., 5 digit messages), and related activity including OTP account verification for financial transactions and fraud detection
(ix) Track, budget, manage SMS-based financial transactions (e.g., 5 digit messages) and related account verification
(x) Physical safety/emergency alerts to send SMS
(xі) Proxy calls
(xіі) SMS Cell Broadcast
(xііі) Write and Show Call History in Dialer
(ix) In-vehicle hands-free use and projected display
(vіі) the application automates the device
(vііі) The application performs financial transactions via SMS and related actions, in particular, sends one-time passwords to confirm the account for transactions and detect fraud;
All of these groups reflect the practice that Google Play on giving temporary permissions. In addition to these groups, you can also declare a new use case, that is, try to prove the platform that the main functions of your application are not described in these groups, but it is also very useful and necessary for users, and it also needs to have access to SMS or Call Log.
Most developers started to fill the Permission Declaration Form with one or more of these exceptions, which at least somehow may be applied to their application, but they were refused.
Why so? As practice shows, it doesn’t work just to select an exception group, a little bit randomly. If the described functionality is not the core for the app, that is, it does not determine the essence of the app, Google Play will refuse you with temporary permission.
What does it mean? If your application is intended to track the Call Log on a child device by parents, but in addition, it may also block spam on such the device, then spam blocking is unlikely to be recognized as the app core functionality.
So, we need just to find our core functions and that’s it?
In fact, things are not so simple. To indicate that your application belongs to a certain group is not enough. In many cases, when developers filed the Form only by indicating some group, they were refused in getting the temporary permission. In addition to belonging to one of the groups, it is necessary to highlight a number of important aspects.
A systemic analysis of all the requirements (from the articles, explanations, and publications of Google Play) makes it possible to say that while giving the temporary permissions Google Play analyze the following:
1. The application should not violate Permissions Policies and the Developer Distribution Agreement.
This is a general provision, but important. Before submitting the Form, you need to review all the provisions of these documents and check that nothing has changed so that you do not violate them. When your application simply has been existing, such violation may not be seen, but now it will be thoroughly checked.
If the app violates any provision of this docs, then the approve for sensitive permissions will not be provided.
2. Your app should be open and transparent
You can demonstrate it by describing the whole process of using personal data and showing that the user is completely warned about all collected personal data and about purposes of such collection, so can knowingly allow using his data, and so on.
3. The app should be useful and important
Google Play should be able to see the benefits to end-users and how this app improves their lives.
4. Minimal impact on privacy and security
It is necessary to show how data protection is implemented in the application, what are preventive mechanisms for data leakage, etc.
5. Permissions should be need to perform the main functions of the app
We have already discussed this, but it is important that it should be clearly seen when verifying. Google may just miss the links between the permissions and core functions (which you see as a developer) and, as a result, refuse to give temporary permission.
In addition to all the above, it is worth to repeat that it is possible to get permission not only within the groups defined in the Form but also to declare the new use case. In this case, you will definitely need to explain why you are satisfying all of the conditions described above and why your app should create a new group of exceptions to their policies.
If you are sure that you have chosen the right group, but you still have been refused to have sensitive permissions, you can always try to appeal the decision of Google Play.
And one more thing, if your app does not have SMS & Call Log Permissions, but it has some other permissions which may be seen as sensitive, you should better start learning how to submit the Form, since all indications are that in the nearest future special requirements will be created for other permission which may in some way affect the privacy of people using Google Play.