GDPR Compliance Assessment for Cross-Border Personal Data Transfers in Android Apps

,


I. INTRODUCTION
The pervasiveness of today's software systems and services allow the personal data of individuals to be easily collected and shared worldwide, across different countries and jurisdictions [1].However, cross-border transfers of personal data pose risks to the privacy of individuals, as the organizations receiving personal data may not offer an equivalent level of protection as in their country of residence.For example, in many parts of the world, particularly in Europe, privacy is strenuously protected [2] and assumed as a Human Right [3].In other regions, such as China, privacy values are often a lesser priority when compared to order and governance [4].These non-equivalent levels of protection are clearly evidenced by a recent court resolution in the European Union (EU) [5], which held that the level of data protection in the U.S. is not essentially equivalent to that required under EU data protection law.Thus, transferring personal data across jurisdictions raises data protection compliance concerns.For example, the General Data Protection Regulation (GDPR) [2] The associate editor coordinating the review of this manuscript and approving it for publication was Porfirio Tramontana .constrains personal data transfers outside the European Economic Area (EU) 1 (a.k.a.cross-border transfers or international transfers), and establishes a set of assurance mechanisms to carry them out.
Mobile applications (''apps'') are a particular kind of consumer software that exacerbate these data protection compliance issues to organizations.The particularities of the app development and distribution ecosystems are major factors underlying these risks [6], [7].First, apps are distributed worldwide through global app stores, being easily accessible to everyone everywhere.Thus, an app provider can easily reach markets and users beyond its country of residence.Second, once any piece of personal data has been collected by an app, it can be transmitted from the device for processing across the world [1] or shared between chains of third-party service providers [8], even without the app developer's knowledge [9].Thus, app developers and other stakeholders are required to be constantly vigilant to ensure that appropriate measures have been taken, there by preventing potential data protection compliance breaches.
However, testing or auditing mobile applications against legal data protection requirements is a non-trivial task.Personal data flows of apps are generally opaque, i.e., the types of personal data transferred, the recipients, and the recipient countries are not easily visible, even for developers when carried out by third-party libraries.According to the EU Cybersecurity Agency, there is still a serious gap between GDPR legal requirements and translation of these requirements into practical solutions, and also there is a need for tools to test, verify and audit existing apps, libraries, and services [7].Following this direction, significant research efforts on data protection compliance assessment in the mobile ecosystem have been undertaken by academics [10]- [14] and regulators [6], [15].Despite the enormous progress achieved, there are still certain gaps that need to be addressed.First, the GDPR defines certain requirements, such as those regarding cross-border transfers, for which assessment approaches have not yet been proposed.Second, most current approaches focus on assessing the apps' compliance with their own privacy policies but not with the underlying regulations, thus assuming that the policy already complies with these regulations.Unfortunately, this is not often the case, particularly for mobile applications [16].
In this context, we aim to advance the fundamental understanding of data protection practices and GDPR potential compliance issues in the Android ecosystem.In particular, we rely on a multidisciplinary approach to better understand the flows of personal data originating from apps in the EU to worldwide recipients and the implications for GDPR compliance.Specifically, we target compliance assessment of both Android apps and their privacy policies with GDPR.To this end, we check compliance in tandem, i.e. the behavior of apps against their privacy policy commitments, and these, in turn, against the transparency requirements established in the GDPR.Thus, we deal with a common drawback highlighted in a previous work, which states that most compliance assessment approaches focus on assessing that personal data flows are consistent with its privacy policy, and assume that this policy complies with certain regulation [17].
Our two key multidisciplinary contributions are (1) a compilation of compliance criteria for assessing cross-border transfers in mobile apps, and (2) a method for detecting cross-border transfers in Android apps at runtime and check their compliance with their privacy policy.We consider that our proposal is valuable for app providers, app distribution platforms such as Google Play Store, and supervisory authorities to detect potential non-compliance issues with GDPR cross-border transfers.We have validated the method on a sample of one-hundred popular Android apps and their privacy policies.As a result, our third contribution is (3) a corpus of privacy policies annotated with cross-border transfer practices.This corpus complements other prior efforts in annotating privacy practices into natural language privacy policies [11], [18], which has been released to the research community. 2Finally, we report the outstanding evidence found on potential GDPR compliance issues in Android apps.
The rest of the paper is organized as follows: Section II presents the background and analyses the existing related work.The results of a multidisciplinary analysis of cross-border transfers in mobile apps as for the GDPR and the compliance criteria for assessing them are presented in Section III.Section IV presents our method for compliance assessment.Section V presents the results and findings of the method validation with one hundred Android apps.Finally, Section VI concludes the paper.

II. BACKGROUND AND RELATED WORK
This section reviews the background and work related to privacy analysis in Android apps and highlights the incidence and gaps of GDPR that motivate our proposal.

A. PRIVACY ANALYSIS IN ANDROID APPS
Significant research efforts on techniques and methods focusing on analyzing the Android apps' behavior and detecting privacy-related anomalies have been made across several research communities.The plurality [19] and contestability [20] of the privacy concept, which is generally approached from a multidisciplinary perspective [21], [22], makes it difficult to define a closed set of criteria or conditions that circumscribe when privacy is preserved or violated in mobile apps.Privacy as confidentiality [23] and privacy as contextual integrity [24] are two paradigms mostly used by prior work to determine when a privacy violation occurs.Prior work covered by the privacy as confidentiality paradigm relies on the binary criterion that any exposure of personal data outside the app (not necessarily external to the mobile device) may lead to a privacy violation.To check this criterion, these works rely on static analysis techniques carried out on the apps' representations or models (e.g., [25]- [28]), on dynamic analysis techniques carried out on the actual implementation of the apps (e.g., [29]- [31]) or on hybrid analysis techniques that combine static and dynamic analysis (e.g., [32]- [34]).A smaller number of works go a step further by collecting and analyzing more contextual information to determine a potential privacy violation.For example, some of them focus on detecting who is accessing the personal data (by distinguishing third-party libraries from the app itself [35]- [37], while others focus on discriminating whether access to certain personal data is required for the app's core functionality or another secondary (third-party) task [38].The Google Play Protect (GPP) approach [39] is also aligned with this paradigm aiming at detecting potential harmful behavior in the Android ecosystem, including the disclosure of personal data off the device via Spyware.All in all, these works are useful to alert personal data leaks but fail when certain flows of personal data are expected or authorized in a particular context (e.g., when a user consents to it).Going a step further, privacy as contextual integrity claims that criteria or conditions that circumscribe when privacy is preserved or violated rather than being absolute require more contextual information to be considered [24].This considers five key elements to define personal data flows: (i) the type of personal data; (ii) the data subject to whom the personal data refers; (iii) the sender and (iv) the recipients of personal data acting in a particular capacity or role; and, (v) the transmission principles that constrain a flow (e.g.user consent).Some recent works rely on the apps' privacy policies [10], [40] or prevailing standards or regulations [12], [13], [41]- [44] as the source for extracting the appropriate or inappropriate personal data flows in terms of the aforementioned elements.These are used as ground truth to analyze their alignment with the personal data flows carried out by apps, and then detect whether a potential privacy violation occurs.Zimmeck et al. [10] propose the Mobile App Privacy System (MAPS), which relies on static code analysis and privacy policy analysis to check the alignment between the personal data that are accessed by mobile apps and their collection practices disclosed in their privacy policies.A combination of dynamic code analysis with privacy policy analysis is proposed by Andow et al. [40] to determine the flow-topolicy consistency, but they focus on distinguishing the entity (i.e., first-party vs. third-party) disclosing personal data.Reyes et al. [41] present a method to evaluate whether Android mobile apps comply with the Children's Online Privacy Protection Act (COPPA), which is a US legislation that regulates how mobile apps can collect private information of children.Much closer to our work, some research efforts also aim at approaches to assess compliance with some GDPR requirements, as further elaborated in the following section.

B. GDPR ANALYSIS IN ANDROID APPS
A recent systematic literature mapping [17] states that there is growing interest in assessing GDPR compliance of software systems, evidenced by the 37% of techniques that deal with them.Compliance with the GDPR is crucial for organizations because a privacy breach can entail significant financial penalties [45].This legal framework aims to ensure that all data processing operations, such as collection or cross-border transfers, are lawful, fair and transparent [2], and ultimately preserve the privacy of individuals.It, therefore, establishes a set of requirements that organizations, even those based outside the EU, should comply with them when offering services within the EU.
In the mobile ecosystem, several works also aim to assess compliance with some GDPR requirements.Ferrara and Spoto [12] focus on the convenient aggregation of the results of detecting disclosures of personal data to represent them at different levels of abstraction, i.e. from developer level to data protection officer level, thus allowing the latter to detect potential GDPR infringements.They relied on static code analysis to detect any disclosure of personal information, although the specific GDPR requirements that are covered are blurred.Jia et al. [13] propose a method to detect personal data disclosures in network traffic based on association mining.Leveraging the fact that the application's network packet payload is represented as a set of key-value pairs, they used a catalogue of key-value pairs related to personal data to search for any of them and then detect personal data disclosures without the user's consent.While our work focuses on different GDPR requirements, the Jia's work could be seen as complementary to our work as the detection method could minimize the false-negative rate.Fan et al. [43] relied on static analysis and privacy policy analysis to carry out an empirical assessment of GDPR compliance in Android MHealth Apps, focusing on transparency, data minimization and confidentiality requirements.In transparency, they checked whether six different practices are informed through privacy policies, but cross-border transfer practices are not covered.In data minimization, their efforts focused on collection practices by checking whether personal data types collected by apps are disclosed in their privacy policies.Mangset [44] relied on the static and dynamic analysis to identify personal data disclosures at rest and in transit, and then check for GDPR compliance.The underlying method is largely manual and in-depth, assessing five pharmaceutical and dating apps, focusing on requirements related to transparency, data minimization (collection practices), confidentiality (data at rest in transit), and some user rights (particularly, consent and objection automatically individual decision-making).Finally, we consider Eskandari et al. [42] as the closest related work.They propose PDTLoc, an analysis tool that employs static analysis to detect violations of article 25.1 of the EU Data Protection Directive (European data protection law replaced by the GDPR).The Directive set requirements for international transfers similar to those laid down in the GDPR.However, this prior work did not consider the recipient type of personal data flows nor the privacy policies as a means of disclosing the safeguards that enable cross-border transfers.Therefore, this approach would have incorrectly identified potential compliance issues (false positives), as any transfer outside the EU would be presumed to be a regulatory infringement.
To fill this gap, we rely on a multidisciplinary approach to better understand the flows of personal data originating from apps in the EU to worldwide recipients and the implications for GDPR compliance.Moving requirements from the legal to the technical domain is challenging mainly because natural language is used to define them.Such textual descriptions are away from the technical realm, and translate them requires mitigating ambiguity and subjectivity, and solving the potential conflicts that may arise.In this regard, a comprehensive analysis was first undertaken by privacy and data protection experts who collectively identified a set of criteria for assessing the compliance of mobile apps with GDRP cross-border transfers (Section III).Then, based on these criteria, a method for detecting cross-border transfers in Android apps at runtime and check their compliance with their privacy policy is proposed (Section IV).

FIGURE 1.
The GDPR lays down the (a) the criteria for distinguishing cross-border transfers (light-grey boxes), and (b) information to be disclosed to data subjects, generally through privacy policies, in order to ensure transparency.

III. PERSONAL DATA CROSS-BORDER TRANSFERS
As illustrated in Figure 1(a), there are specific criteria for determining what must be considered a cross-border transfer, to which the GDPR lays down further constraints or requirements.These requirements include, in each case the disclosure of specific and meaningful information to data subjects, as shown in Figure 1(b).
Criterion C1.1: Does the app send personal data to remote recipients?GDPR defines personal data as ''any information relating to an identified or identifiable information'' [2].Explicitly, the location, contacts, unique device and custom identifiers, including the International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identity (IMSI), Unique Device Identifier (UDID), and mobile phone number, biometrics, the identity of the phone, phone calls logs, SMS, browsing history, email, and pictures and videos have been determined as personal data according to GDPR () [6].
This work, far from seeking comprehensiveness, focuses on personal data in four specific categories: contact, demographics, identifiers, and location.The first two are characterized by being collected directly from the data subject, e.g. through app forms when registering an account, while the last two can be collected directly from the mobile devices.Based on Zimmeck et al.'s classification [11], we broke down the aforementioned categories into the fine-grained data types listed in Table 1.
A mobile device has several identifiers, although we have included the identifiers of high risk for privacy, i.e. those that could enable tracking of data subjects across time and across different apps in Table 1.The scope and persistence are two dimensions of identifiers, with a number of possible discrete points, that suggest the risk involved [46].The scope defines which apps can access an identifier: (1) one app only, (2) a group of apps, or (3) all the apps on the device.The lower the scope, the lower the risk of tracking a data subject through transactions from different apps.The persistence defines the lifespan of an identifier and depends mainly on the mechanism available to reset it: (1) app installation reset, (2) in-app reset, (3) system-setting reset, (4) device factory reset, and (5) non-reset.Likewise, the longer the persistence, the longer the tracking time.For example, the IMEI (International Mobile Equipment Identity) and the AAID (Android Advertising Identifier) are device-level and OS-level identifiers, respectively.They, therefore, are consistent across all the device's apps and can be used to track a data subject across them.The IMEI may also allow tracking a data subject over time, as it is a non-resettable identifier.On the other hand, although the AAID is supposed to be a non-persistent identifier since it can be reset through the system settings, there are two main reasons for also considering it, in practice, as potentially persistent.First, data subjects are prone to preserving default privacy settings [47], especially when such settings are hard to discover and understand (the option to reset the AAID is 6 steps deep) [48].Second, a recent related work [40] found that 74.7% of recipients who receive AAIDs also receive other persistent identifiers, nullifying the non-persistence property and also allowing a data subject to be tracked over time and across resets.In this sense, as shown in Table 1, we considered the identifiers with the greatest scope, i.e. those that are shared by all the apps in a device, and whose removal requires the data subject to necessarily perform a system-setting or device reset.
For the purposes of this study, except for data types in the grey cells, any app that processes at least one of the data types listed in Table 1 satisfies criterion C1.1.

Criterion C1.2: Are EU data subjects being targeted by app providers?
This criterion seeks to determine whether an app provider is offering a service within the EU.Generally, providers upload their apps to global distribution platforms, such as Google Play Store, APK Pure, or F-Droid, to make them available to users.Therefore, these TABLE 1. Personal data types in the meaning of GDPR that could be transferred by mobile apps.Personal data types in the grey cells were not considered in deciding whether criterion C1.1 is met, although the experiments log them when transferred along with other personal data types.
distribution platforms play a key role in providing the necessary capabilities to set up, inter alia, the countries or regions of targeted users.In the case of Google Play Store, to which this study circumscribes, the publication of an app involves two main stages: preparation and release.In the preparation stage, the app provider must digitally sign the app with a (self-signed) certificate before uploading it, including details on the organization such as its name and locality [49].In the release stage, the app provider should perform a pre-configuration before uploading the app and making it available, including the selection of countries targeted [50].This process leads us to fairly assume that mobile apps available in the Google Play Store reachable from an EU country are actually targeting EU data subjects (irrespective their nationality), thus satisfying criterion C1.2.
To reinforce the assessment of this criterion, we can rely on the app's privacy policy and look for statements suggesting that an app or service targets EU-resident users [51].For example, when a privacy policy includes references to (1) the EU as a whole or one EU member state in relation to the service offered; or, (2) dedicated addresses or phone numbers to be reached from an EU country.

C1.3: To which countries do the app transfer personal data?
This criterion seeks to determine to which country personal data are sent.Personal data may be disclosed through multiple sinks or channels to different recipients.Relevant sinks to this work are those that allow personal data to be disclosed outside the device.For example, through an SMS (Short Message Service), Bluetooth, NFC (Near Field Communication), or network interfaces.Particular focus is given to network interfaces, as previous studies [52] have shown their high prevalence to communicate externally over other interfaces.
In this context, certain metadata of the connections between the app and the receiving servers, particularly the server's IP address and the domain name, can be used to geolocate the country to which personal data are transferred.Based on this information only the first-hop server recipient can be geolocated, i.e., the destination server directly reachable via the app connection.Personal data, however, may be transferred from the first-hop server to other servers, although tracing it necessarily requires the collaboration of the remote servers (organizations) involved.The geolocation of recipient servers bifurcates app transfers into (C1.3.1)EU cross-border transfers and (C1.3.2) non-EU cross-border transfers.
An EU cross-border transfer (C1.3.1)implies that an app, owned by an EU data subject, transfers personal data to recipients geolocated in another European country.That is, there is a transfer between different countries, but these are located within the EU.This type of transfer does not add further constraints or requirements, since the GDPR itself is an effort to unify the different EU country legislations and thus facilitate the free movement of personal data within the EU. 3n the other hand, a non-EU cross-border transfer (C1.3.2) implies that an app, being used by an EU data subject, transfers personal data to recipients located outside the EU.However, this criterion on its own is insufficient to determine whether an app is carrying out an international transfer in the meaning of GDPR.Rather, based on the non-EU cross-border transfers a further criterion needs to be checked (C1.4).

C1.4. To which recipients do the app transfer personal data?
This criterion seeks to distinguish whether the servers located outside the EU belong to (C1.4.1) the app provider (i.e., first-party recipient or data controller in GDPR terms), or (C1.4.2) another organization (i.e.third-party recipient).First-party recipients are the app providers themselves, who may be using cloud servers for remote data storage or other kinds of cloud processing.On the other hand, third-party recipients include other organizations delivering a variety of services to the apps, such as support for the app operation (e.g., crash management), analytics (e.g. to design optimization), social network integration or app monetization through advertising.These first-and third-party recipients are roughly aligned with some actors defined in the GDPR, the Data Controller and Data Processor respectively.

C1.4.1. Is personal data transferred to a non-EU data controller?
This criterion seeks to determine whether an app provider (data controller) is established outside the EU.Transfers of personal data from an app to first-party recipients located outside the EU can occur in two possible settings.First, the app provider is indeed based in a non-EU country and therefore its servers too.Second, the app provider is based in an EU-country, but its servers are outside the EU.In both cases, the app provider is subject entirely to the GDPR requirements.However, in the first case, the app provider must also designate in writing a representative in the EU and disclose, generally through its privacy policy, the contact details to data subjects4 (S1 in Fig. 1b).A representative is not necessarily a data forwarding entity but rather an entity that should act on behalf of the app provider, addressing matters of the data subjects and supervisory authorities.The app's privacy policy is the main source for extracting the contact details of the data controller, including locality.

C1.4.2. Is personal data transferred to non-EU third-party recipients?
This criterion seeks to determine whether a third-party recipient is not established within the EU.If this criterion is met, then we are dealing with an international transfer.An international transfer can only take place if the non-EU third-party recipients can ensure a level of protection equivalent to that mandated by the GDPR.In this line, the European Commission (EC) distinguishes the non-EU countries with an adequacy decision from those lacking it.Twelve non-EU countries have been recognized so far by the Commission as providing protection equivalent to GDPR and therefore maintaining an adequacy decision [53].It is worth mentioning that until July 16, 2020, US companies that complied with the Privacy Shield legal framework [54] also maintained an adequacy decision.However, this was invalidated by the Court of Justice of the EU finding it no longer provides adequate protection [5].

C1.5.1. Is an international transfer covered by an adequacy decision?
This criterion seeks to determine whether an international transfer is targeted to a third-party recipient located in a country covered by an adequacy decision.If so, it can take place without any further safeguards, although to ensure transparency, 5 the app provider should inform the data subjects about (1) the intention to transfer personal data to a non-EU country, including (2) the names of targeted countries, and (3) the existence of an adequacy decision by the Commission [55] (S2 in Fig. 1b).

C1.5.2. Is an international transfer not covered by an adequacy decision?
In the absence of an adequacy decision, the app provider, acting as data controller, requires the adoption of ''appropriate safeguards'' before carrying out an international transfer.GDPR defines a set of assurance mechanism that enable international transfers in such cases, 6 including Standard Data Protection Clauses, Binding Corporate Rules, Approved Codes of Conduct and Approved Certification Schemes.These assurance mechanisms should be approved by the European Commission and, in general, allow the app provider to ensure that third-party recipients have implemented appropriate safeguards to ensure a protection level equivalent to GDPR.So far, the Commission has adopted four Standard Data Protection Clauses [56], which should be incorporated into contracts between the parties concerned.Binding Corporate Rules should be established when international transfers take place between companies belonging to a corporate group and be signed with the Commission's approval.Finally, the Commission has not yet adopted any Code of Conduct or Certification Scheme for GDPR.
Finally, in order to ensure transparency, 7 the app provider should inform the data subjects about (1) the intention to transfer personal data to a non-EU country, including (2) the names of targeted countries, (3) a reference to the appropriate safeguard(s) according to the aforementioned options, and (4) the means to obtain a copy of the safeguard(s) [55] (S3 in Fig. 1b).
Other Exceptions: In the absence of an adequacy decision or any appropriate safeguards, there are some exceptions 8 that allow international transfers in specific situations.We highlight the explicit consent, which requires the consent through an affirmative action of the data subjects, e.g., ticking a box, to be obtained after providing precise details of the international transfers.In this case, the data subjects should also be able to withdraw consent easily at any time.

IV. ASSESSING APPS COMPLIANCE WITH GDPR CROSS-BORDER TRANSFERS
On the basis of the criteria defined in Section III, assessing compliance of an app with cross-border transfers requires fundamentally two inputs: the app's personal data flows and the committed practices in its privacy policy.On the one hand, the former provides information on the type of personal data, the type of recipient who receives the personal data (i.e., first-party or third-party recipient); and the country in which the recipient servers are located.Based on this information, the key idea is to determine which type of cross-border transfer is performed by a target app, if any, according to the criteria summarized in Figure 1a.On the other hand, it is necessary to interpret all pertinent privacy policy practices to determine whether detected cross-border transfers have been properly disclosed, according to transparency elements summarized in Figure 1b.It is worth pointing out that we refer to a privacy policy in the sense of GDPR, i.e., a document that contains the committed privacy practices of an app provider, including collection, sharing and international transfer practices.Figure 2 illustrates the three underlying process that supports the overall method to analyze apps and their privacy 7 GDPR Art.13(1)(f) and Art.14-(1)(f) 8 GDPR Art.49  policies and then detect potential non-compliance issues with GDPR cross-border transfers.Each of these processes is explained in detail in the following subsections: the extraction of the app's personal data flows that occur throughout the network in Section A, the systematic extraction of cross-border transfers statements disclosed through the app's privacy policy in Section B, and, finally, the compliance checking between observed personal data flows and policy statements in Section C.

A. EXTRACTION OF PERSONAL DATA FLOWS FROM THE APP
We define an app's personal data flow in terms of (i) the type of personal data, as per Table 1; (ii) the type of recipient who receives the personal data (i.e., first-party or third-party recipient); and, (iii) the country in which the recipient servers are located.We rely on dynamic analysis to observe the app behavior and extract its personal data flows.Personal data flows can also be inferred from the app's representations or models by using static analysis [25]- [28].However, we favor dynamic analysis to prioritize soundness over completeness, as our goal is to extract actual evidence of cross-border transfers carried out by an app.Furthermore, we rely on app network interfaces as sources of behavior.Previous studies [52] have shown the prevalent usage of network interfaces over SMSs or short-range interfaces such as Bluetooth or NFC by mobile apps to communicate externally.Thus, it is fair to assume that most cross-border transfers occur naturally through the network.Figure 3 sets out the overall data flow extraction process and its phases, which are detailed below.

1) STIMULATION
This supports both automated and manual stimulation.Automated stimulation is based on a random strategy provided by the U/I Exerciser Monkey [57], which provides better performance in terms of code coverage compared to other approaches [58].As the Monkey can miss some event that only humans can trigger, e.g., apps that require a login, manual stimulation by analysts or testers is also supported.While this approach allows for uncovering app functionality similar to what a real user can do, it is not scalable and is feasible only with a small number of apps.

2) CONFIGURATION
This component allows the configuration and automated deployment of the entire experimental environment.Based on the Google Play API [59], it automatically crawls and downloads the target mobile app (APK) from Google Play Store.Once downloaded, it retrieves the metadata from the APK digital certificate and stores it in a centralized log repository.It also repackages the APK before installing it on the mobile device in order to bypass basic TLS protection in the network traffic, as explained below.Finally, it deploys the necessary components according to the analyst's configuration, for example, capturing traffic in different stages, such as an idle stage (i.e.without any user interaction) and an active stage (i.e. with user or monkey interaction).

3) INTERCEPTION
This component is responsible for capturing the app network traffic and storing it for further analysis.Three key features of the state-of-the-practice of mobile apps were considered to build this component.First, a vast majority of Android apps have adopted TLS (Transport Layer Security) as the defacto protocol for internet communication [60].Second, some apps, and in particular integrated third-party libraries [60], implement further protections such as certificate pinning thus restricting trusted Certificate Authorities (CA) to a small known set [61].Third, several apps and OS services can run concurrently and generate network traffic, it being necessary to distinguish the traffic belonging to the target app from the others.
Traffic capture from the device's network interface is built around a man-in-the-middle (MITM) proxy [62].It requires a MITM proxy self-signed CA certificate to be installed in the root certificate store of the mobile device in order to become a trusted CA.Thus, instead of establishing a direct TLS connection between apps and remote servers, the MITM proxy will set up two different TLS connections: app-proxy and proxy-remote server.After configuring the mobile device to connect to the Internet through the MITM proxy, it is possible to capture HTTP and HTTPS traffic from the apps.Note that this approach requires the configuration of the mobile device once rather than the configuration of individual applications.Therefore, once the terminal is configured the traffic of any application can be captured.
We also implemented a MITM proxy plugin consisting of two main classes: a TLS failure detector and flow-toapp mapping.The TLS failure detector captures the exceptions produced by the TLS layer and stores appropriate logs when a connection cannot be established.For example, an app detecting an untrusted CA due to a certificate pinning implementation will abort the proxy connection and generate a TLS exception, which will be logged including the targeted IP address and domain.The flow-to-app mapping allows us to filter in the traffic belonging to the target app since we analyze each app independently.It takes advantage of ADB (Android Debug Bridge) [63] and netstat [64] to retrieve the ports opened by apps running on the mobile device.Based on this information, only the traffic and connection metadata belonging to the target app is logged.
As already mentioned, several apps and their integrated third-party libraries implement certificate pinning as further protection layer against TLS interception.These apps trust in specific CA certificates instead of the CA certificates available in the device.Consequently, they will abort connections using the MITM proxy's self-signed CA certificate and prevent certain data flows from being intercepted.CA certificates can be hard-coded either (i) in the network_security_config file of an app distribution package (APK), or (ii) in the app code itself.In the first approach, an app can declare the CA certificates they trust in the network_security_config file, which is located in the APK xml folder.For example, the entries <domain>example.com</domain>and <certificates src="@raw/ pinned_ca"/> pin the CA certificate pinned_ca to connect to the example.com domain.In the second approach, the CA certificates are hard-coded in the app code itself using the standard Android API, such as Trust Manager, or third-party specialized libraries, such as OkHttp3 and TrustKit.Actually, there are a significant number of third-party libraries for this purpose, therefore there are many different ways of implementing it (we have identified 23 so far).We adopted two approaches to bypass these protections.First, to bypass the Manifest-based certificate pinning, we modify the app's network_security_config file to trust the system's CA certificates, including the MITM proxy certificate we installed.More specifically, the network_security_config file was extracted from the APK using apktool [65].By crawling this file, the entries that pin the specific CA certificates are replaced by the entry <certificates src="system"/>, thus the app will trust the system CA certificates.The APK is finally repackaged and installed in the mobile device.Second, to bypass the library-based certificate pinning, we rely on Frida [66] to change the behavior of the target app at runtime when verifying the CA certificates it trusts.That is, the API library methods that verify the trusted CA certificates for a connection were hooked, and then convenient code was injected to bypass the verification.For example, an app using the OkHttp3 library calls the CertificatePinner.checkAPI method to verify trusted CA certificates.If the connection's CA certificate does not match with any of the trusted certificates, then it throws an exception, and the connection is aborted.To prevent this, we command Frida to capture the CertificatePinner.checkmethod and then inject our code.In fact, our code overloads the check method to print a black hole message instead of throwing an exception.In this way, the connection between the app and the MITM proxy is successfully established.So far, we have implemented the check bypass for 23 different certificate pinning libraries.

4) ANALYSIS
Based on the stored app's traffic packets and metadata, the main purpose of this component is to analyze them and then determine (i) the type of personal data transferred by an app, (ii) the country where the personal data recipient is located, and (iii) the type of recipient who receives the personal data, i.e. first-party or third-party recipient.

a: PERSONAL DATA TYPE
We use string searching in packet payloads to detect personal data types, as detailed in Table 1.A key assumption for adopting string searching is that these personal data types are well-known in advance and will remain unchanged in our experimental environment.That is, contact details, identifiers and location information are retrieved in advance from the mobile device and fed into the algorithm that searches for these data in the traffic packets of each app.As app developers may deliberately obfuscate this personal data using different encoding and hashing mechanisms to evade detection [41], our algorithm also searches for data encoded in Base64, MD5, SHA1 and SHA256.To validate this approach, we wrote a ground-truth test Android app 9 that discloses the personal data listed in Table 1 to a remote server.We ran this app through the pipeline shown in Figure 3 and were able to recover all the types of personal data.

b: RECIPIENT LOCATION
We relied on ipstack API [67] to determine the location of the servers receiving the app's connections.In this way, the firsthop server recipient, i.e. the destination server directly reachable via the app connection, can be geolocated.Admittedly, further connections can be established from the first-hop server to other servers.However, tracing them would necessarily require the collaboration of remote servers (organizations) involved, which is beyond the scope of this work.This component ultimately tags each personal data flow whose recipient server is outside the EU.

c: RECIPIENT TYPE
The objective is twofold.First, to distinguish whether the target domain of a connection is a first-party recipient (i.e. the app provider itself) or a third-party recipient (i.e.third-party service provider or other company).Second, if it is a thirdparty recipient, we determine its owner organization, service category and headquarter country.To this end, a two-iteration process was carried out.
In the first iteration, we try to match the owner of the application with the owner of the target domain of the network connections.To this end, we generate two bags of tokens: one with tokens representing the app and another with tokens representing the target domain.A token matching is then made between the two bags, classifying the domain as a first-party recipient if there is at least one token match.More specifically, the app's token bag is built upon the reverse domain name used to name an APK, which generally contains the name of the app provider.For example, com.netflix.Speedtest consists of the app's name (Speedtest), the second-level domain (SLD) that commonly refers to the organization (netflix), and the Top-Level Domain (TLD) that is global and may be shared between multiple APKs (com).The SLD and subdomains were included in the app's token bag but TLDs were excluded, as they are not suitable for distinguishing between different domains.We also noted that a small number of APK names do not include the organization name, e.g, com.mt.mtxx.mtxx is owned by the Chinese organization Meitu.Therefore, we reinforced our approach by also considering the name of the app's controlling organization extracted from the digital certificate used to sign the app.In the case of com.mt.mtxx.mtxx, the Meitu token is certainly contained in its digital certificate.Lastly, the domain's token bag consists of the SLD and individual subdomains of the target domain.Each flow of personal data then is tagged as a first-party recipient if there is at least one token in both app and domain bags.In order to validate it, we have manually checked the domains targeted by 100 apps that were tagged as first-party recipients, and 98.6% were correctly classified.A small number of domains were misclassified because certain APK names and a target domain use a same generic token, e.g.''app.'' In the second iteration, domains not classified as first-party recipients are initially assumed to be third-party recipients.These domains, particularly SLD, are used as proxies to identify their owner organizations, based on Libert's dataset [68].This allows individual target domains to be mapped to the owner company and even to parent companies, including the country in which the headquarters are located and service category.We have used Libert's dataset as it was created in the specific context of disclosing personal data to third parties, albeit focusing on the web [69].Later, it was also extended [70] and used [71] in the context of mobile apps.However, while this dataset greatly served as a base and starting point, the last update was in 2018 and therefore several domains of potential third-party recipients (targeted by more than one app) were not found in the dataset.We then manually populated it based on the Crunchbase [72] and OpenCorporates [73] databases, which provide, inter alia, information on the headquarter country, category of service offered, and information on company acquisitions that give an insight into the organizations' structures.Over 50 new entries were added and committed to a public repository maintained by a research community. 10inally, after these two iterations, certain domains could be classified as neither first-party nor third-party recipients and therefore are tagged as unknown.In this case, manual inspection is required.For instance, in a traffic dataset generated by 100 apps, 366 unique domains have been targeted, of which 8 SLDs are actually first-party recipients but could not be properly classified since they do not use their canonical organization names.For example, the domain nflxvideo.netuses nflxvideo instead of netflix.We have manually cured these tags, as the number is quite handy.However, in order to automate it and improve precision, the digital certificates of the targeted domains (if available) can be leveraged in a similar way as explained above.We leave this for future work.On the other hand, 23 domains look like they are anonymously registered and could not be found either using automated tools such as whois or searching in catalogues such as Crunchbase.For example, the domains startappservice.com and smartechmetrics.comare targeted by several apps but we were unable to determine the owner and other related information.These domains therefore were labeled as ''unknown'' in our dataset and were not considered for further analysis.

B. EXTRACTION OF CROSS-BORDER TRANSFER STATEMENTS FROM PRIVACY POLICIES
Despite efforts to represent the committed privacy practices by using machine-readable means (e.g., P3P-Platform for Privacy Preferences [74]), natural language privacy policies seem to be the de facto channel of communicating privacy practices of a digital or physical service to different stakeholders [75].Particularly in mobile apps, following requests from certain European [76] and the US [77] working groups, major app distribution platforms provide functionality that allows app developers to link their privacy policies.GDPR has also relied on privacy policies to disclose privacy practices to data subjects and other stakeholders [55].
Therefore, the main purpose of this task is to systematically extract the cross-border transfer statements disclosed in the apps' privacy policies.To this end, we followed the guidelines of the codification or annotation method [78], i.e. an interpretative and qualitative approach in which one or multiple domain analysts assign a label or code to data.While this process has been completely manual, the systematic process followed has allowed the generation of a corpus with structured annotations of cross-border transfers.
This corpus has been released in a public repository, 11 thus contributing other prior efforts in annotating privacy practices in natural language privacy policies [11], [18] and also enabling classification models to be trained and to automate the annotation process.
Figure 4 illustrates the overall process to determine the cross-border transfer statements declared in an app's privacy policies.

1) ANNOTATION SCHEME DEFINITION
Domain experts, including privacy experts and legal scholars, were involved in defining the cross-border transfer annotation scheme.Taking the GDPR [2] as reference together with the transparency guidelines issued by the EDPB [55], we defined an annotation scheme consisting of three levels: cross-border transfer type, transparency elements to be disclosed in each case, and potential values.While details have been presented in Section III, Table 2 outlines the annotation scheme used to capture the transparency elements disclosed by the app's privacy policies.
As shown in Table 2, a valid option for each individual transparency element is 'Not disclosed', allowing annotators to express its absence.This is because, after carrying out a pilot annotation on a subset of privacy policies, we found that some transparency elements are ambivalent or just missing.For example, the privacy policy of the app org.mozilla.firefoxstates that ''This means that your information might end up on one of those computers in another country and that country may have a different level of data protection regulation than yours''.This declares, somehow, the transfer intention but lacks other transparency elements.
Another key task carried out by domain experts was the definition of some simplifying assumptions about 11 The corpus is available at https://github.com/PrivApp/IT100-CorpusTABLE 2. Cross-border transfer annotation scheme.( * ) Explicit consent is not a safeguard in itself but an exception that enables a cross-border transfer.
cross-border transfer statements to resolve the ambiguities of natural language.Discrepancies in interpreting privacy policies are very common [79] since, inter alia, details, structure and language can vary from one app to another.Thus, through an iterative process, a subset of privacy policies was annotated in order to identify alternative statements referring to certain transparency elements or to give them a more precise meaning.For example, to refer to Standard Data Protection Clauses the privacy policies use alternative statements such as ''contracts approved by the European Commission'', ''data protection model contracts'' or ''data processing addendum.''These simplifying assumptions were provided as tooltips during the annotation process.

2) TOOL-BASED ANNOTATION
A web-based tool 12 was developed to support the whole annotation process, seeking to simplify the process and prevent mistakes.As detailed in Figure 5, it provides functionality to set up different privacy practices in a three-level structure (i.e., practice, transparency elements, and potential values), annotate the privacy practices at the segment and sentence level, calculate the inter-coder agreement, and display inconsistencies between coders.
Each privacy policy was broken down into segments (roughly paragraphs).They are presented sequentially to coders who annotate them by selecting a value for each transparency element.In addition, the coder can select a text 12 http://anotacion.herramientapoliticasprivacidad.com/homespan (e.g. a sentence) for finer-grained annotations.Once a policy has been coded, the tool outputs segment and sentence level annotations represented in YAML format, a human-and machine-readable format.

3) INTER-ANNOTATOR RELIABILITY CHECKING
In order to control the inter-annotator reliability during the annotation process, we randomly selected a subset of privacy policies to annotate using another coder.Then, we rely on Krippendorff's α coefficient for evaluating the reliability of the annotations, which indicates that agreement between both coders is ''good'' (α > 0.8), ''tolerable'' (0.67 -0.8), or ''suspected'' (α < 0.67) [80].We analyzed disagreements between the two coders in order to (1) amend the annotations performed once an agreement has been reached, and (2) identify potential systematic disagreements, such as misunderstanding of the annotation criteria, and then refine them.For example, in a set of 100 annotated privacy policies, we evaluated the inter-coder reliability over 15% of policies, as other related studies [10].Transfer intention, appropriate safeguards (particularly, adequacy decision and standard data protection clauses), copy means, and target country reached a ''good'' agreement.The agreement on Not disclosed appropriate safeguard is ''tolerable'' (0.67 -0.8), while Explicit Consent and Binding Corporate Rules fall into ''suspected'' annotations.We analyzed disagreements and identified non-systematic disagreements since one of the coders overlooked the disclosure of certain cross-border  transfer statements.More significantly, we identified systematic disagreements due to misunderstandings, e.g. in coding explicit consent.Tacit consent, i.e. the mere use of service is assumed as a user consenting to an international transfer, was coded as explicit consent by one coder, which is not right.Coders mutually harmonized their criteria and curated the annotations properly.The same procedure was followed for all other disagreements. 13

C. COMPLIANCE CHECKING
The final process aims to check whether the apps performing cross-border transfers properly disclose, through their privacy policies, the transparency elements according to Table 2. To this end, we consider four consistency types between the app's personal data flows and privacy policy statements, as illustrated below.

1) FULL CROSS-BORDER TRANSFER DISCLOSURE
It implies that a privacy policy discloses all transparency elements according to the type of cross-border transfer actually carried out by an app.For illustrative purposes, consider the ''Battle Bay'' com.rovio.battlebayapp, owned by Rovio Mobile Ltd.It has been installed +10,000,000 times from the Google Play Store.For analytics purpose, it transfers the AAID (Android Advertisement Identifier) to, inter alia, outcome-ssp.supersonicads.com,whose servers are located in the United States (US).The domain supersonicads.com is owned by the third-party recipient IronSource Ltd, which is based in the US.
The privacy policy of the app discloses the statement shown in Figure 6, which fully disclosing their cross-border transparency elements.That is, the transfer intention (green); target country (yellow); appropriate safeguard -Standard 13 Details can be found in the replication package available at http://dx.doi.org/10.17632/ws6cx9p65dData Protection Clause and Adequacy decision (blue); and the means to get a copy of the safeguards (grey).Therefore, in this specific case, we classify this app as a full cross-border transfer disclosure.

2) AMBIGUOUS CROSS-BORDER TRANSFER DISCLOSURE
It implies that a privacy policy discloses only a subset of the transparency elements required by the GDPR according to the type of cross-border transfer carried out by the app.The missing transparency elements are either disclosed in an ambivalent manner or not disclosed at all.For example, consider the ''ASKfm -Anonymous Questions'' (com.askfm)app, owned by Ask.fm, that has been installed +50,000,000 times from the Google Play Store.For analytics purposes, it transfers the AAID to, inter alia, startup.mobile.yandex.net,whose servers are located in Russia.This domain is owned by the third-party recipient Yandex LLC that is based in Russia.
The privacy policy of the app discloses the statement shown in Figure 7, which states the intention to transfer personal data (green) and the target countries (yellow).However, target countries are stated in an ambivalent manner ''various countries around the world''.Besides, appropriate safeguards and the means to get a copy of such safeguards are missing.It should be pointed out that the AAID is transferred to startup.mobile.yandex.netbefore the user interacts with the app, nullifying any attempt to underpin the transfer by explicit consent, as explained in Section III.

3) INCONSISTENT CROSS-BORDER TRANSFER DISCLOSURE
It implies that a privacy policy discloses statements that contradict the cross-border transfers actually carried out by an app.For illustrative purposes, consider the ''Mondly-Learn 33 Languages Free'' (com.atistudios.mondly.app, owned by ATi Studios, that has been installed +10,000,000 times from the Google Play Store.For analytics and advertisement purposes, it transfers the AAID to app.adjust.comand onesignal.com,whose servers are located in the US.These domains are owned by the third-party recipients Adjust and OneSignal, Inc., respectively, both based in the US. The privacy policy of the app discloses the statement shown in Figure 8.It discloses the intention to transfer personal data (green) to countries covered by an adequacy decision (blue).Although the target countries have not been explicitly disclosed, a conservative assumption leads us to consider the twelve countries that maintain an adequacy decision [53] as possible targets (yellow).However, the US does not fall into this group of countries.Therefore, in this specific case, we classify this app as inconsistent cross-border transfer disclosure since an international transfer is actually made to the US.

4) OMITTED CROSS-BORDER TRANSFER DISCLOSURE
It implies that a privacy policy does not disclose any transparency element when an app performs a cross-border transfer.For example, consider the ''Camera360-Photo Editor'' (vStudio.Android.Camera360) app that has been installed +100,000,000 times from the Google Play Store.It transfers the MAC Address to t.growingio.com,whose servers are located in China.The domain growingio.comis owned by the third-party recipient Alibaba, which is based in China.Also, it transfers the AAID and the GPS Location to i.camera360.com, a first-party recipient located in China.After searching for a policy statement describing at least the intention to make a cross-border transfer, it was not found at all.We, therefore, classify this app as omitted cross-border transfer disclosure.

V. VALIDATION
The main motivation for the method was to analyze whether Android app providers properly disclose the transparency elements required by GDPR when apps make cross-border transfers.In this section, we present the results of analyzing 100 apps from the Google Play Store and identify the extent to which these apps are potentially non-compliant, as a way of validating the applicability of the method.

A. EXPERIMENTAL ENVIRONMENT SET-UP
We developed a controlled experiment by using the assessment method presented in Section IV.Details on the availability of underlying resources can be found in the replication package. 14Both the apps and their privacy policies were downloaded in March 2020 and tested between 7 and 14 April 2020.The apps were implemented on a mobile device Xiaomi Redmi 7a with Android 9 (API 28).As illustrated in Figure 9, each app was run for 10 minutes considering two phases: idle stage (i.e., without user interaction) and active stage (i.e., with user interaction).Since apps may transfer personal data immediately after they are launched, traffic is captured for 2 minutes without any user interaction (idle stage).Then, a tester interacts with the application for 8 minutes (active stage).During the active stage, one of the paper authors acted as a tester by interacting with each of the targeted apps.He followed the overall operational testing plan shown in Table 3, seeking to navigate through the main functionalities as an actual user would.Although a detailed UI navigation specification is not feasible since each app provides different functionality, the tester read the app description taken from the Google Play Store before starting to navigate through it, to get an understanding of the app's core functionality

1) APPS SELECTION
The dataset consists of 100 popular Android mobile apps downloaded from the Google Play Store in March 2020 from Spain.Three main criteria guided the app selection: (i) top-free apps in an EU country; (ii) apps included in the APP-350 corpus [10], and; (iii) apps offering diversity in the geographical location of app providers.The first criterion is transversal to the two other criteria and is intended to bring us closer to the most popular apps in an EU country.To this end, we rely on the categorization of top-free apps in Spain made by Google Play Store in terms of the number of downloads.The second criterion sought to contribute prior efforts in annotating privacy practices in privacy policies, particularly the APP-350 corpus [10], by extending it with crossborder transfer annotations.To this end, we selected a subset of 44 apps coming from that corpus that also fall into the top-free app category.The third criterion aims at ensuring the top-free apps selected represent providers offering services within the EU but established across the world, thus enabling us to understand how cross-border transfers are addressed in the wild.To this end, as other related works [1], [8], we relied on the Country field in the digital certificate used to sign the app to obtain the country organization.As a result, a set of 56 additional apps from 25 different countries were included, most of them from the US, China, Spain, France and Australia. 15

2) PRIVACY POLICY CORPUS
We annotated the set of 100 privacy policies by following the process described in Section IV-B.Each privacy policy was entirely read, irrespective of whether cross-border transfers were detected during the app testing time.Each policy segment was assigned a label with the transparency elements disclosed.Within the segment, a text span (i.e., sentence) was assigned also an appropriate label, to make finer-grained annotations available.The corpus 16consists of a total of 3,715 segments.Of these, 315 contain transparency elements of cross-border transfers distributed as shown in Table 4.Some transparency elements are redundant within a privacy policy.For example, the cross-border transfer intention is disclosed in 127 different segments from only 57 apps' privacy policies.

3) APP'S DATA FLOW DATASET
A total of 29,910 flows from 100 apps have been logged.Each log includes the app name, app version, capture stage (idle or active), target port, target domain, target country, and personal data type disclosed (if any).The dataset contains 6,281 flows (21%) disclosing personal data to 195 unique fully-qualified domain names (FQDNs) with 117 unique second-level domains (SLDs).These SLDs are hosted on servers located in 13 different countries, 6 EU countries and 7 non-EU countries hosting 19 and 106 domains respectively.A few domains (8) are hosted on servers located in both EU and non-EU countries. 17

B. COMPLIANCE RESULTS
Figure 10 details the number of apps that fulfil the criteria leading to cross-border transfers discussed in Section III.A subset of 85 apps transferred personal data during the testing time.From them, 10 apps transferred personal data solely to other EU countries.While these are also a type of crossborder transfer, they do not imply further constraints in the meaning of GDPR.The remaining 75 apps transfer personal data outside the EU.This subset of apps has been broken down into three groups that imply different transparency requirements: 27 apps transferring personal data to non-EU based data controllers (Section 1), 59 apps transferring personal data to third-party recipients covered by an adequacy decision (Section 2), and 8 apps transferring personal data to third-party recipients not covered by an adequacy decision (Section 3).
Note that some apps have performed more than one cross-border transfer type.For example, out of 75 apps that transferred personal data to a non-EU country (C1.3.2 in Figure 10), a subset of 16 apps transferred personal data to both non-EU third-party recipients and non-EU firstparty recipients.This is why the sum up of both subsets of apps (64 and 27) exceeds its input in 16.Details of these apps can be found in Annex A.

1) NON-EU DATA CONTROLLER CROSS-BORDER TRANSFERS
We found 27 apps transferring personal data to first-party domains hosted in servers outside the EU; details are provided in Table 5 of Appendix section.We used the Issuer Country field of the apps' digital certificates to identify the organizations' location [49], and 22 are in fact from outside the EU.We were unable to identify the location behind the digital certificates for the remaining 5 apps since they are missing.The privacy policy of one of these apps (Duolingo) does indicate that it is an organization established in the USA, but the other 4 do not provide any information.
Only 11 of the 27 apps have been classified as full cross-border transfer disclosures, i.e., their privacy policies explicitly provide contact details of either the data controller or a representative within the EU.For example, Duolingo (com.duolingo) and Reddit (com.reddit.frontpage)explicitly disclose subjects that their organizations are based outside the EU, but they have defined a data controller and representative within the EU, respectively.
The remaining 16 apps have been classified as omitted cross-border transfer disclosures, i.e. their privacy policies do not provide information on a data controller or a representative within the EU.Although admittedly 6 of them do mention GDPR as the privacy legislation taken into account and even state the intention to transfer personal data to the USA, they do not provide information on a representative or data controller established within the EU.

2) ADEQUACY DECISION-BASED CROSS-BORDER TRANSFERS
We found 64 apps that transferred personal data to third-party domains hosted on servers located in the US and Canada.
Although the organization' locations (based on digital certificates) indicate 18 different countries, third party services are predominantly located in the US (63) and only one in Canada.Canada maintains an adequacy decision, therefore any transfer can be made without any further safeguards [53].On the other hand, apps that personal data to third-party recipients located in the US could be covered by an adequacy decision as long they complied with the Privacy Shield Framework. 18As already mentioned, Privacy Shield was invalidated by the Court of Justice of the EU on July 16, 2020, finding that it does not provide adequate protection [5].However, given that this experiment was carried out in April 2020, Privacy Shield was still valid.In Section B-4 we analyze whether the apps involved have adopted changes.
As explained in Section III, three transparency elements should be disclosed to data subjects when such transfers take place: transfer intention, names of targeted countries, and the existence of an EU adequacy decision.
A smaller subset of 9 apps has been classified as full cross-border transfer disclosures, i.e. their privacy policies disclose the transfer intention, the specific target country and rely on third-party service providers listed in the Privacy Shield List, thus maintaining an adequacy decision.See Table 6 of the Appendix for details.
A subset of 23 apps has been classified as ambiguous cross-border transfer disclosures.All their privacy policies disclose the intention to transfer personal data.The specific target countries are disclosed by 20 apps' privacy policies, while the remaining 3 apps disclose ambiguous statements such as ''any country in which we do business.''The existence of an adequacy decision (i.e., compliance with the Privacy Shield Framework) or any other appropriate safeguard is missing from 20 privacy policies.Three other apps do rely on Privacy Shield; however, the policies state that the apps themselves are Privacy Shield compliant, but say nothing about the third-party service providers to whom they transfer the personal data.These were therefore also tagged as ambiguous disclosure.Finally, it is worth pointing out that more than half of this subset (13) do not mention GDPR statements, suggesting that this privacy legislation is not considered by app developers.See Table 6 of the Appendix for details.
A considerable number of 27 apps have been classified as omitted cross-border transfer disclosure, i.e., their privacy policies do not disclose any of the aforementioned transparency elements.In fact, most of these privacy policies (21) do not even mention GDPR statements, suggesting this privacy legislation is not taken into account by app providers when informing data subject of their rights.See Table 6 of the Appendix for details.
The remaining 5 apps rely on other safeguards that are discussed in the next section.

3) NON-ADEQUACY DECISION-BASED CROSS-BORDER TRANSFERS
We found three apps that transferred personal data to China (1), Malaysia (1), and Russia (1), as well as 5 apps that transferred personal data to the US by using other appropriate safeguards than adequacy decisions.Apps that made international transfers to China and Malaysia were classified as omitted cross-border transfer disclosure.Neither the transfer intention, the recipient countries, nor the appropriate safeguards were disclosed by their privacy policies.The app that made an international transfer to Russia was classified as inconsistent disclosure.Although it discloses the intention to make a cross-border transfer, it states only the US as a target country, but personal data are also transferred to Russia.
Three of the remaining 5 apps that performed international transfers to the US were classified as full cross-border transfer disclosures, i.e. their privacy policies disclose the transfer intention, the specific target country, the appropriate safeguards (in this case standard data protection clauses) and the means of obtaining a copy of such safeguards.The other two apps rely on standard data protection clauses and binding corporate rules, although they are disclosed ambiguously and do not provide the means to obtain a copy of them.They, therefore, were classified as ambiguous cross-border transfer disclosures.The privacy policies of these last two apps alternatively mention that they could rely on the explicit consent from the user to make an international transfer.However, the method that both apps carried out the transfers during the idle stage.Therefore, this exception to making the transfer is nullified.See Table 6 of the Appendix for details.

4) ADEQUACY DECISION-BASED CROSS-BORDER TRANSFERS AFTER THE INVALIDATION OF PRIVACY SHIELD
Since the Privacy Shield framework was invalidated by the Court of Justice of the EU on July 16, 2020 [5], the crossborder transfers to the US that rely on this framework may face potential compliance issues.In October 2020, we downloaded the new versions of the 9 apps that were classified as full cross-border transfer disclosuresand relied on the Privacy Shield as an adequacy decision (Section B-1).We then re-analyzed the apps and their privacy policies that were supported in Privacy Shield using the method described in this article to observe the changes adopted, if any.These 9 updated apps still perform transfers to the same third-party recipients and countries, except for one recipient that was not detected during this new analysis.Their privacy policies still maintain Privacy Shield as the adequacy decision that enables international transfers.In this case, these applications have been classified as inconsistent cross-border transfer disclosures.
As a result, a total of 66% of apps have been found as ambiguous, inconsistent or omitted cross-border transfer disclosures.As detailed in Table 7 of the Appendix, we found that some apps have performed more than one type of crossborder transfer.Therefore, an app has been classified as fully compliant only if all individual performed practices have been classified as full cross-border transfer disclosures.

C. VALIDITY OF RESULTS
This section discusses the potential threats to the validity of the potential non-compliance results presented in Section B along with the actions we have taken to minimize them.

1) CONSTRUCT VALIDITY
Since the overall compliance assessment method deals with GDPR requirements, there is a risk that the study setting will not reflect the construct under study when moving those requirements from the legal to the technical domain.That is, since natural language is used to define legal requirements, translate them into technical ones requires mitigating ambiguity and subjectivity, and solving the potential conflicts that may arise.To address this validity threat, much effort has been made to characterize the cross-border transfer of GDPR on the basis of multidisciplinary work.A comprehensive analysis was undertaken by privacy and data protection experts who collectively identified a set of criteria for assessing the compliance of mobile applications with GDRP cross-border transfers.These criteria were developed using the GDPR and the relevant opinions in the field of the mobile ecosystem issued by the European Data Protection Board, which are duly referred to in Section III.This multidisciplinary approach also comprehensively guided the building of the annotation process, annotation scheme, and the simplified assumptions used during the annotation process of cross-border transfer practices in privacy policies.

2) INTERNAL VALIDITY
The internal validity of the non-compliance results depends primarily on (1) the reliability of the annotation process of the cross-border transfer practices in the privacy policies, and (2) the accuracy in detecting the cross-border transfers performed by apps.One the one hand, a threat to (1) is the annotator's bias in deciding whether or not to annotate a policy segment and labeling each cross-border transfer transparency TABLE 5. Cross-border transfers to first-party recipients located outside the EU (Target countries).An app is tagged as full cross-border disclosure (•) when the Data Controller (C) or Representative (R) contact information is explicitly disclosed; otherwise, it is tagged as omitted cross-border transfer disclosure (-).Further details can be found at the replication package http://dx.doi.org/10.17632/ws6cx9p65delement according to the annotation scheme.The annotation process is based on a qualitative and interpretative method, which naturally implies an internal threat that could lead to biased or erroneous results.We took two main actions to minimize this threat.First, privacy experts and legal scholars were involved in normalizing the criteria to annotate each transparency element.Thus, a detailed annotation procedure and a set of simplifying assumptions were defined for each transparency element. 19Second, we validated the reliability of annotations by ensuring that a subset of privacy policies was annotated by two privacy experts.As detailed in section IV-B-3, most of the transparency elements annotated (5 of 8) ensured a good Krippendorff's alpha coefficient (>0.8), one had a tolerable agreement (0.74), and two had a suspicious agreement (<0.67).A discussion was held on the latter three in order to align the criteria and amend the annotations, if necessary. 20n the other hand, a threat to (2) is a high rate of false positives that could lead to misdetection of potential non-compliance issues in the analyzed apps.We took one main action to minimize this thread: a conservative analysis is performed prioritizing precision over recall.So, any cross-border transfer detected during the experiments was an observation of the real app behavior and no false positives were generated.As detailed in Section IV-A, we relied on dynamic analysis techniques in order to capture network packets generated by the real execution of apps rather than other techniques that analyze approximate models that, while ensuring high recall, could generate a high rate of false positives (e.g., static analysis [81]).In the following subsections, we further elaborate on the actions carried out in detecting the personal data types, the recipient location and the recipient type (see Section IV-A-4 for details).
Personal data type detection algorithm is based on searching for pre-defined strings.It was validated by analyzing the behavior of a ground-truth testing app that we developed, being able to detect all predefined personal data types.Yet, app developers may deliberately obfuscate data flows by using different encoding and hashing algorithms.Although we also considered different encoding and hashing mechanisms (Base64, MD5, SHA1 and SHA256), customized encodings can result in false negatives and detect them an in-depth manual analysis could be necessary.The main threat in recipient location detection is that further connections can be established from the first-hop server to other servers geo-located in other countries.However, tracing them would necessarily require the collaboration of remote servers (organizations) involved.We, therefore, simplify the TABLE 6. Cross-border transfers to third-party recipients located outside the EU (Target countries) classified as Full (•), Ambiguous ( ), Inconsistent (X) and Omitted (-) cross-border transfer disclosures.Safeguards options are Adequacy Decision (AD), Standard Data Protection Clauses (SDPC), Binding Corporate Rules (BCR), and Explicit Consent (EC).Further details can be found at the replication package http://dx.doi.org/10.17632/ws6cx9p65dTABLE 6. (Continued.)Cross-border transfers to third-party recipients located outside the EU (Target countries) classified as Full (•), Ambiguous ( ), Inconsistent (X) and Omitted (-) cross-border transfer disclosures.Safeguards options are Adequacy Decision (AD), Standard Data Protection Clauses (SDPC), Binding Corporate Rules (BCR), and Explicit Consent (EC).Further details can be found at the replication package http://dx.doi.org/10.17632/ws6cx9p65danalysis for the entities receiving the personal data on the first-hop server, and alert for potential non-compliant crossborder transfers.Afterwards, the organizations themselves or independent supervisory authorities can perform further analysis to re-check non-compliance issues by requesting information from the remote servers involved.Finally, as per recipient type detection, we manually checked the domains tagged as first-party recipients, and 98.6% were correctly classified.A small subset of 23 domains are anonymously registered and could not be classified as a first nor third-party recipient.However, these domains were not considered for further analysis, thus preventing the detection of false noncompliance issues.

3) EXTERNAL VALIDITY
Admittedly, the personal data flow extraction in our approach is subject to the same limitations faced by all dynamic analysis techniques in Android apps, so it cannot ensure completeness.The use of non-standard encodings mechanisms [41], unusual TLS certificate pinning implementations [60], and sub-optimal coverage of app execution paths [82] are some particular challenges to proposal.Thus, we have to recognize that the of fully compliant apps should not be misleading generalized, as false negatives can be generated.That is, the fact that we have not observed a cross-border transfer during our testing period does not mean that an app will not definitely do so if its developers, e.g., use customized encoding mechanisms.
All in all, potential false negatives will not change the validity of results on non-compliant apps, which is remarkably high (66%).As mentioned above, the strength of our proposal is that any non-compliance issue with cross-border transfer detected during the experiments was an observation of the real app behavior and did not generate false positives.Therefore, we consider that our proposal, as well as the results, are valuable for app providers, app distribution platforms such as Google Play Store, and supervisory authorities to detect the lower bound of the GDPR cross-border transfer non-compliance issues.

VI. CONCLUSION AND FUTURE WORK
In this work, we presented a method for compliance assessment of GDPR cross-border transfers in mobile applications.Based on a multidisciplinary approach, it moves towards truly data protection compliance assessment by checking first the cross-border transfers made by apps against their privacy policy commitments and these, in turn, against the transparency requirements established in the GDPR.We applied the method to systematically analyze the potential compliance issues of one hundred popular Android apps, as per cross-border transfers.We found evidence showing that 66% of the apps analyzed present ambiguous or inconsistent crossborder transfer disclosures, or just omit them, leading to potential compliance issues.The invalidation of the Privacy Shield Framework in mid-2020 worsened the problem, leading to some cross-border transfers becoming potentially noncompliant.
Our future work points towards the full automation of the compliance assessment method to better understand the dimension of this issue.For that, we are leveraging upon Machine Learning and Natural Language Processing techniques to automate the extraction of cross-border transparency elements from the privacy policies.TABLE 7. Consolidated compliance results (C) for cross-border transfers considering transfers to non-EU first-party recipients (FP) and non-EU third-party recipients (TP).A transfer can be classified as Full (•), Ambiguous (), Inconsistent (X) and Omitted (-) cross-border transfer disclosures.Only if TP and FP are Full disclosures, the app has been classified as compliant (Yes); otherwise, as non-compliant (No).Apps highlighted in grey were re-analyzed after invalidation of Privacy Shield becoming inconsistent disclosures.A blank field denotes that that transfer type was not detected.

FIGURE 2 .
FIGURE 2. Overall method to assess app compliance with GDPR cross-border transfers.

FIGURE 3 .
FIGURE 3. The overall process to extract cross-border personal data flows from apps.

FIGURE 4 .
FIGURE 4. Overall annotation process to extract the statements on cross-border transfers from the app's privacy policies.

FIGURE 5 .
FIGURE 5. Web-based tool to annotate privacy practices in privacy policies.

FIGURE 7 .
FIGURE 7. International transfer statement of the com.askfm app.

FIGURE 10 .
FIGURE 10.Number of apps performing cross-border transfers.Each app transfer has been classified as full cross-border transfer disclosures (FD), ambiguous cross-border transfer disclosures (AD), inconsistent cross-border transfer disclosures (ID) or omitted cross-border disclosures (OD).

TABLE 3 .
Overall operational testing plan.

TABLE 4 .
Number of apps and statements declaring the transparency elements of cross-border transfer statement.