APP Privacy Compliance Status and Preventive Measures-Translation

background

On November 1, 2021, the "Personal Information Protection Law" was officially implemented, marking the entry of information protection into the era of strong supervision , and APP supervision has been raised to an unprecedented level. Corresponding rules and regulations have been introduced in various aspects such as data security , user privacy, and even functional experience. , The original intention of supervision is to protect the rights and interests of users at all levels, to avoid the abuse of users' privacy, experience, and data, and even threaten national security. On the one hand, it is necessary to fully consider and meet various regulatory requirements during the product design and development stages; on the other hand, once hidden problems are found, it is necessary to actively respond and rectify them in a timely manner, otherwise it may face the risk of being notified by the Ministry of Industry and Information Technology, or even completely removed from the shelves. The first piece is: APP Privacy Compliance .

APP privacy compliance simply means: the collection, storage, use, processing, transmission, provision, disclosure, and deletion of user privacy must comply with the Personal Information Protection Law and abide by the principles . From the perspective of the APP, it is related to the user's personal experience, and the user can intuitively feel whether his privacy is being excessively demanded. For example, apply for permissions that have nothing to do with your own functions, refuse to provide services and other scenarios.

Key Scenarios for APP Privacy Compliance Monitoring

According to the statistics of the Information and Communication Research Institute, as of December 10, 2021, the Ministry of Industry and Information Technology has tested a total of 2.44 million apps, issued a total of 5,000+ rectification notices, notified 2,000+ unfavorable apps for rectification, and removed 600+ apps that refused to rectify. Among them, the hardest-hit areas are illegally obtaining user privacy, collecting personal information beyond the scope, excessively frequent and excessively asking for permissions, and using personal information in violation of regulations, among which illegal collection of personal information
accounted for 48%, excessive requests for permissions accounted for 17%, and excessive collection of personal information Information accounts for 10%, illegal use of personal information accounts for 8%, and mandatory targeted push accounts for 8%. These are also key areas for APP detection and rectification.

Illegal collection of personal privacy

The information mentioned here mainly refers to the ability to track, locate, and identify personal identities, and is mostly obtained in an implicit way. With reference to the Personal Information Protection Law and the "Methods for Identifying the Illegal and Illegal Collection and Use of Personal Information by Apps" , the illegal collection of personal information mainly refers to the following scenarios:

(1) Undisclosed collection rules, purpose, method, and scope. Common manifestations include:

App缺少隐私政策，或者隐私策略不规范  **【隐私策略H5落地页 】**

     
     
      
      
     
     
      
      
       
       1

首次运行时未通过弹窗等明显方式提示用户阅读隐私政策等收集规则；  **【启动隐私策略弹窗 】**

     
     
      
      
     
     
      
      
       
       1

隐私政策难以访问、难以阅读[文字过小过密、颜色过淡、模糊不清] **【隐私策略规范】**

     
     
      
      
     
     
      
      
       
       1

App或者SDK收集目的、方式、范围披露不完整  **【SDK披露列表 】**

     
     
      
      
     
     
      
      
       
       1

隐私策略变更时，未以显著方式通知用户  **【更新弹窗 】**

     
     
      
      
     
     
      
      
       
       1

申请权限，或户身份证号、银行账号、位置等个人敏感信息时，未同步告知用户其目的，或者目的不明确**【说明弹窗 】**

     
     
      
      
     
     
      
      
       
       1

(2) Collecting personal information without the user's consent, with specific manifestations

Start collecting before the user agrees [Privacy Policy Before clicking Agree, call sensitive API]
Still collecting after the user clearly expresses their disapproval, or frequently asking for the user's consent, which affects the use [should not frequently request after refusal]
The collection of information exceeds the scope of user authorization or violates its policy statement to collect personal information. 【no fault】
Choose to agree to the privacy policy by default [selected by default]
Targeted push information, close if not mentioned [Thousands of people, thousands of faces]
Did not provide users with ways and means to withdraw their consent to collect personal information; [The operability is too low, I have not experienced this]

APP frequently, coercively, and excessively asks for permissions

The authority mentioned here mainly refers to the need for user authorization at the system level. Only authorization can obtain some information, and most of them are obtained by display . Violation scenarios generally refer to: after the user explicitly rejects certain permission applications, frequent pop-up windows continue to repeatedly apply for a certain non-essential permission, or because the user refuses to refuse to provide services as a whole. Common manifestations are:

Frequent Requests: When the Shangxiang user explicitly rejects the location application and is still running the subsequent App, he/she applies for it in various ways
Mandatory request: When the app is launched for the first time, the user is asked for IMEI permission to be used as the device ID, and the user chooses to refuse the authorization and exit directly
Excessive request for permissions: Reading tools ask for address book permissions, etc.

The "Privacy Policy" must clarify the purpose of all permission applications, and ensure that the permissions are related to functions. Refusing a certain functional authorization should not affect the normal use of other functions. Caution.

Differences in privacy compliance between Android and iOS

(1) Android is the key object of privacy compliance

Overall, the iOS ecosystem is healthier and more complete. Compared with Google, Apple pays more attention to privacy and supports it better at the system level. Moreover, because the iOS system is not open source, all domestic mobile phone manufacturers use the Android system, and each manufacturer has its own application market, resulting in a particularly chaotic ecology. The open source of Android makes Google's voice in the system not particularly high, and the fragmentation of the system It is almost impossible to solve privacy issues through system upgrades. Therefore, the focus of domestic privacy compliance review has always been Android, and basically only Android. Whether it is technically or in terms of voice, Apple is more strong.

(2) Android's compliance review standards are confusing

Privacy compliance is mainly promoted by the Ministry of Industry and Information Technology, the Cyberspace Administration of China, and local traffic management bureaus, but the specific review work is not undertaken by these departments, but is handed over to a third party for review. In order to ensure the quality of apps in their own market, some application markets also define a set of review rules, which leads to such a chaotic situation: Apps that pass the review in market A still have privacy compliance issues in market B, and the Ministry of Industry and Information Technology Apps that are compliant with the review cannot pass the review standards of some application markets. At present, the main domestic application markets are as follows:

Compared with the uniqueness of iOS, the manufacturers that Android has to deal with are very complicated, and the compliance issues to be dealt with are even more confusing. Although the privacy compliance policy is positive, there is a lack of unified certification standards at the implementation level, which is difficult for development and product operations . Brings a lot of extra adaptation work. For example, for the original intention of some user information collection, some markets require very detailed requirements, and this measurement is not performed by machines, but by manual review. Subjective judgments bring a lot of uncertainty to this part.

Review methods for APP privacy compliance

At present, privacy compliance is basically completed by manual + automated tools. It is still difficult to 100% automated audit, and compliance testing is generally provided by specialized agencies. There are two types of inspections here, one is the compliance inspection initiated by the Ministry of Industry and Information Technology and the Traffic Management Bureau, and the other is the developer’s own initiative. The Ministry of Industry and Information Technology will generally hire a third-party organization to conduct compliance inspections on batches of APPs and issue rectifications based on the results. Notification, and follow-up review, the review process is generally:

The review by the Ministry of Industry and Information Technology Communications Management Bureau is generally passive for developers, but after the results are detected, they must be actively and actively resolved. Once the handling is not good, the consequences of notification or removal from the shelves will be disastrous. Relatively speaking, the other is development or legal active detection. Many platforms provide privacy compliance detection services. The purpose of testing is self-examination to expose risks in advance.

However, for developers, this method is not very friendly, and a real-time, convenient and cheap self-examination method is needed

APP developer privacy compliance self-examination

The review methods used by each manufacturer or platform are basically similar. Manual review is responsible for proofreading at the functional level, such as: whether to provide a directional push switch, whether to provide a privacy policy, whether the content of the privacy policy is complete, whether the application for specifications and permissions is compliant, etc. Pay more attention to the explicit requirements of laws and regulations; tool review pays more attention to the acquisition of private information, whether some system interfaces are called to illegally obtain user information, and pays more attention to implicit compliance requirements. Explicit compliance is easier to satisfy, and it has basically been dealt with in the interaction design stage, so focus on the tool review review part.

The acquisition of user sensitive information is achieved by calling the system API, so the current approach is basically to hook the system API, and then output the call stack to see if the current node meets the compliance requirements, such as in the user unified Before the privacy policy, any operation that calls sensitive APIs is not compliant. How to deal with it during the development process? Taking the Android system as an example, there are various solutions for system API HOOK, such as the XPOSED framework and the Frida framework, etc. The usage of these two is introduced separately:

XPOSED frame method

XPOSED itself is a HOOK framework. It hooks all the processes in the entire system by polluting the zygote process. Developers can customize the HOOK rules after installing the ROOT mobile phone Android XPOSED framework. In the scenario of privacy compliance review, Add hook functions for all compliant APIs, just print out the call stack before calling, and then install the modules you develop into the XPOSED framework, and you can see the calls of sensitive APIs in real time through the logs.

public class CheckPlugin implements IXposedHookLoadPackage {
try {
    XposedHelpers.findAndHookMethod(
            TelephonyManager.class.getName(),
            lpparam.classLoader,
            "getImei",
            String.class,
            new XC_MethodHook() {
                @Override
                protected void beforeHookedMethod(MethodHookParam param) {
                    if (!TextUtils.isEmpty(packaname) && !packaname.equals(lpparam.packageName)) {
                        return;
                    }
                    Log.e(TAG, lpparam.packageName + " 调用getImei获取了IMEI");
                    collectionExceptionAllinformation(param);
                }
            }
    );
} catch (Throwable ignored) {
}
	    ...
    <!--其他合规API-->
}

   
   
    
    
   
   
    
    
    
    
     
     
   
   
    
    
   
   
    
    
     
     1
     
     2
     
     3
     
     4
     
     5
     
     6
     
     7
     
     8
     
     9
     
     10
     
     11
     
     12
     
     13
     
     14
     
     15
     
     16
     
     17
     
     18
     
     19
     
     20
     
     21
     
     22
     
     23

The main work of this method is to write the XPOSED module, and the implementation code is Java, which can be directly developed in Android Studio. For Android development, the implementation is relatively simple, but each modification must be redeployed to the mobile phone, and the device needs to be restarted. Effective, the initial development efficiency may be relatively low, but after solidification, it is quite convenient. Use Magisk+ruri+ LSposed for installation reference above P

The Frida framework approach

Compared with the XPOSED framework, Frida is more flexible and does not need to install any framework. You only need to run Frida-server on the Root phone for reference . It can interact with frida_server by writing JS and Python codes. Frida uses Dynamic Binary Insertion (DBI) inserts additional code and data in real time when the program is running, so as to achieve the function of tracking and intercepting functions. Hook script writing method:

Java.perform(function(){

var macAddress = Java.use(“android.net.wifi.WifiInfo”);
macAddress.getMacAddress.overload().implementation = function () {
console.log(“getMacAddress()”);
this.private_func();
};
…
<!–其他合规API–>

});

Although this method is more flexible, it is a little inconvenient to use. Every time, you need to start the script injection directly or indirectly through the command

frida -U -l  privacy.js -f com.netease.yanxuan

 
 
  
  
 
 
  
  
   
   1

Comparison of the two methods:

The XPOSED framework is more troublesome in mobile phone transformation. In addition to ROOT, XPOSED needs to be installed. XPOSED’s compatibility is poor, but the subsequent benefits are more convenient. XPOSED’s
early development efficiency is low, but once the Module is fixed, there is almost no cost in the later
configuration of Frida . Relatively simple, only need ROOT
Frida development is more flexible, suitable for flexible and changing API detection, but each subsequent detection must be started through the **command line,** a little troublesome

For development and use, XPOSED is preferred. If automated deployment is considered, Frida is preferred, which is more operable.

APP privacy compliance rectification

Principle: Before the privacy policy is agreed, do not obtain any user's private data, and do not apply for any permission before reaching a specific business scenario. Reasonable publicity must be given if any permission and privacy are used

Judging from the practice of APP's multiple rectifications, the illegal collection of personal privacy in violation of regulations is the most common , and the collection without user consent is the most among them. There are many reasons for this, and the inconsistency between system design and regulatory review is the most common. The key point is that the privacy compliance inspection and the design of the Android system do not resonate at the same frequency, and are even somewhat mutually exclusive. There is no such a pause link in the system , allowing users to agree to the privacy policy before continuing the subsequent operations. The display of pop-up windows in the Android system already belongs to the category of business, rather than a customizable system blocking point, so it is not easy to deal with. Normal development is to initialize many environments and parameters at the beginning of APP startup, and these initializations are likely to involve some privacy API calls. Under the framework of privacy compliance, these calls can only be artificially delayed or canceled. Secondly, although its own business compliance is relatively easy to handle, the compliance of some third-party SDKs is more troublesome, and some of them can be resolved through upgrades, while SDKs that have been in disrepair for a long time may only be able to solve non-compliance problems through aspect programming. Writing plug-ins is a One investment, and more plug-ins affect compilation efficiency, and maintenance is also troublesome.

For the acquisition of dynamic permissions, there are two points to note: one is to apply only in the associated interface, do not apply in advance; the second is that a reasonable explanation must be given before applying for permissions, even if sometimes this explanation seems redundant, Google officials also recommend adding reminders before applying for certain sensitive permissions, but it is not necessary on the system, but domestic compliance is basically one size fits all, and it is mandatory to add.

For the privacy policy, the main focus is first: whether the collection, storage, and use of privacy are disclosed in detail and thoroughly; second: whether there are any omissions in the three-party SDK list, basically satisfying these two points.

Summarize

At present, the domestic privacy compliance review is a little too strict, but serious illness needs strong medicine, let’s make things right first, and maybe it will be a little looser in the future.