# Assessing the Security and Privacy of Baby Monitor Apps
## 5 Mobile App Analysis
### App Permissions  
The permission system in the Android operating system regulates an application's access to the phone hardware, settings, and user data [37]. Based on the criticality of the access granted, the Android permissions are divided into different categories, with dangerous permissions allowing access to sensitive data, settings or potentially risky features. Since the release of Android 6.0, Android requires app users to explicitly grant dangerous permissions to an app at runtime [38]. Accordingly, those permissions are called runtime permissions. The user must confirm access for privacy protection reasons, but the time at which runtime permissions are requested depends on the app being used. This complicates the evaluation of permissions because the app could only request permissions when the user triggers the corresponding functionality. However, runtime permissions should be declared in the app's manifest file, a configuration file that is meant to contain all the permissions that an app might request. Therefore, we evaluated the dangerous permissions listed in each app's Android manifest to check whether the app requests more than the required permissions.  
As the evaluation of manifest permissions in Table 4 illustrates, there are ultimately two dangerous permissions required to provide baby monitoring functionality: (a) the CAMERA permission, which allows recording video and taking pictures using the built-in camera, and (b) the RECORD_AUDIO permission, which controls the usage of the device microphone. These permissions are clearly necessary for an app to perform the baby monitoring task and are requested by every app at runtime. However, Table 4 indicates that both the BabyCam and Saby apps may request to write the external storage. Moreover, the Dormi app may want to read the phone state or to write phone settings, and the Saby app may ask to read to external storage. The purpose is unclear in each of these cases, as these permissions are not tied to functionalities in addition to the baby monitoring task. This may indicate excessive use of permissions, which could open the door for potential privacy violations.  
Therefore, we further investigated additional permissions to identify potential misuse. To investigate suspicious permissions not requested during regular app usage, we associated run-time permission requests with their corresponding functionality (Table 5). If an application did not make a run-time request, the corresponding permission was not required for the functions used. Since this could indicate suspicious usage elsewhere in the execution path and could also be associated with proper functionality that we did not trigger during execution, we examined the decompiled code to rule out misuse.  
Due to ongoing changes in the Android permission model [39, 40], not all permissions specified in an app's manifest are required when running an app on a specific Android version. Therefore, we document whether permission is required to implement a feature in Android 12, the OS version we used during our analysis. As our evaluation shows (Table 5), there is no evidence of misuse of any of the potentially suspicious permissions. The Dormi app does not contain any code at all to query the additionally listed runtime permissions. Although the other apps contain code for requesting additional dangerous permissions, we could associate them with legitimate app functions during code analysis. However, our results were obtained with the caveat that evaluating all possible code paths was not feasible. Therefore, hidden or obfuscated usage may have been missed.