# Assessing the Security and Privacy of Baby Monitor Apps
## 5 Mobile App Analysis
### Network Communication  
To conduct a privacy assessment and examine the ways in which the selected baby monitoring apps secure their video transmissions, we needed to understand the underlying communication mechanisms. The baby monitor, the device responsible for recording and transmitting video footage, must be placed near the child. Therefore, we assume that the mobile phone used for monitoring purposes is connected to a local Wi-Fi network, e.g., at home or at the hotel. In contradiction, a parental device is expected to be moved around using an Internet connection provided by cellular networks or another Wi-Fi access point. In such a scenario, a direct connection between mobile devices is not feasible. Consequently, before transmitting the monitoring footage, a connection between the baby monitor and the parent device must be established over the Internet. However, since the selected baby monitoring apps are proprietary, their communication mechanisms are opaque, hindering privacy and security evaluation. Therefore, a part of this study explored how app instances communicate with their respective peers. During our analysis, we discovered that in our analysis environment, the baby monitoring apps make use of mainly two different communication mechanisms to transfer video streams. In the following, we describe these two communication mechanisms. The first communication variant is used by the apps Dormi, Saby, and Babyphone Mobile. Although implemented using different technologies and protocols, the overall communication scheme stays the same. Figure 3 shows this communication scheme. For each of these applications, the monitoring device and the parent device connect to a relay instance that is reachable via a public IP address. The relay uses the established connections to forward data between mobile devices, allowing data exchange between \begin{table}
\begin{tabular}{l l l} \hline \hline
**App** & **Pairing** & **Type of Pairing** & **Confirmation Required** \\ \hline Dormi & & 5-digit code, valid for 120 s. \\ SabyCam & & - \\ Saby & & QR-Code, Link, 4-digit code. \\ Babyphone Mobile & & 5-digit code, valid for 30 min. \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Pairing mechanisms utilized by the inspected apps when transferring video footage over the Internet. Figure 3: Network communication of the Dormi, Saby, and Babyphone mobile apps. the monitor and the parent instance. As all data are routed through the relays, the relay operators can access the transmitted video data. However, this privacy threat is mainly mitigated by encryption (see Section 5.5). While the Babyphone Mobile app relies on proprietary binary protocols transported over its servers, the Dormi app exchanges data using servers owned by Google LLC, utilizing a custom protocol to establish a data channel and using the Secure-RTP protocol for video transmission (Table 7). The Saby app uses WebRTC [41] in conjunction with TURN relays [42] operated by Xirsys. In contrast, the BabyCam app establishes connections between mobile phones differently, favoring a direct connection between the monitoring device and the parental endpoint. The app sets up a server on the child device, which provides the monitoring video streams via HTTP. As the monitoring device is part of the local Wi-Fi network, it is typically secured by a firewall and hidden by NAT techniques. This means that the communication scheme has to overcome complexities such as network address translation (NAT) and security mechanisms in local networks, e.g., the firewall has to allow the corresponding connections and provide port forwarding to the monitoring device. Figure 4 demonstrates this communication mechanism. During the operation, the BabyCam app checks if it is externally reachable via TCP on port 6060 or port 50002. If it is not reachable, the default settings configure the BabyCam app to send a UPnP query to the firewall, requesting that connections be allowed on these ports, and establishing port forwarding to the own device.