Are mobile app developers actively enabling data collection by advertisement and analytics companies, or are they unaware of the implications of using the provided software development kits (SDKs)? Given that the current mobile app ecosystem inadvertently involves collecting user data, which often infringes upon data protection and privacy standards, the question of the underlying reason for the permissibility of data processing arises. We contribute to this research for both Android and iOS by performing a two-step qualitative analysis. First, we conduct a structured documentation review of five advertisement and five analytics SDKs, focusing on privacy-related information. Subsequently, we implement a set of example apps utilizing the basic functionality of each SDK. This custom utilization of the SDK allows us to perform a fine-grained traffic analysis of each required step from initialization until utilization. Our results show that only little guidance on data protection compliance is provided. The observed network traffic shows that overall data collection by SDKs is similar between operating systems and only requires basic usage by the developer to trigger. We discover that with current SDKs, developers have minimal influence over the collected data, as merely using the basic functionality already results in data collection, with advertisement SDKs collecting more data than analytics SDKs. Overall, we explain the observed data protection infringement in ongoing mobile privacy research by documenting how developers must bear with opaque SDKs that lead to data collection simply due to usage.

Web applications utilizing databases for persistence frequently expose security flaws due to race conditions. The commonly accepted remedy to this problem is to envelope related database operations in transactions. Unfortunately, sole trust in transactions to isolate competing sets of database interactions is often misplaced. While the precise isolation properties of transactions depend on the configuration of the database management system (DBMS), the default configuration of common DBMS exposes transactions to anomalies that render their protection worthless.

At the end of 2020, Apple introduced privacy nutritional labels, requiring app developers to state what data is collected by their apps and for what purpose. In this paper, we take an in-depth look at the privacy labels and how they relate to actual transmitted data. First, we give an exploratory statistically evaluation of 11074 distinct apps across 22 categories and their corresponding privacy label or lack thereof. Our dataset shows that only some apps provide privacy labels, and a small number self-declare that they do not collect any data. Additionally, our statistical methods showcase the differences of the privacy labels across application categories. We then select a subset of 1687 apps across 22 categories from the German App Store to conduct a no-touch traffic collection study. We analyse the traffic against a set of 18 honey-data points and a list of known advertisement and tracking domains. At least 276 of these apps violate their privacy label by transmitting data without declaration, showing that the privacy labels’ correctness was not validated during the app approval process. In addition, we evaluate the apps’ adherence to the GDPR in respect of providing a privacy consent form, through collected screenshots, and identify numerous potential violations of the directive.