“Developers Are Responsible”: What Ad Networks Tell Developers About Privacy

Advertising networks enable developers to create revenue, but using them potentially impacts user privacy and requires developers to make legal decisions. To understand what privacy information ad networks give developers, we did a walkthrough of four popular ad network guidance pages with a senior Android developer by looking at the privacy-related information presented to developers. We found that information is focused on complying with legal regulations, and puts the responsibility for such decisions on the developer. Also, sample code and settings often have privacy-unfriendly defaults laced with dark patterns to nudge developers’ decisions towards privacy-unfriendly options such as sharing sensitive data to increase revenue. We conclude by discussing future research around empowering developers and minimising the negative impacts of dark patterns.

decisions are not always fully informed, and developers tend to pick the default options provided by the ad networks ("status quo bias") potentially endangering user privacy [30].
Developers may have privacy concerns for users and look for options that can protect user privacy [11,45,48,50]. For example, when given the option, developers chose coarse over fne grain location information [21]; suggesting that developers do consider privacy. Other developers, though, may just use "industry standard" content provided by large companies which may not be in the best interest of users [11]. Ad networks' documentation is also one of the primary resources of developers when choosing an ad network [30], making presented information particularly important. To understand the default ad networks' confgurations and what privacy-related information they provide to developers which can efect developers' choices and consequently user privacy, we conducted a study with a usable security and privacy researcher and a senior Android developer who reviewed the quick start guides and linked information, of four popular ad networks. We fnd that most of the privacy information presented is framed around legal compliance, casting developers as the responsible entity-which contradicts developers' view that ad networks are responsible for user privacy [30]. The information is also provided in a variety of places sometimes on the main path or included in the libraries by default and sometimes linked from hard-to-notice places which makes fnding the information highly inconsistent between ad networks.

BACKGROUND
Although developers acknowledge the value of user privacy, they fnd it difcult to understand what information is collected and how it is addressed by platforms [11]. Furthermore, developers' user privacy attitudes and actions may contradict; while they may say that they care about user privacy, their decisions and fnal app may not be privacy favourable [30]. Developer concerns about privacy are refected in questions they ask on Stack Overfow [48], and given the options, they pick more privacy-preserving alternatives [21]. Developers tend to follow guidelines and requirements provided by the platforms [38,48]. Our study primarily focuses on the available privacy guidelines for developers in ad networks, as one of the main resources for choosing an ad network [30].
Android developers must request for permissions from the operating system, and sometimes the user, to access certain resources. These permissions are defned by the developer in a manifest fle AndroidManifest.xml [8]. Permissions could be "normal permissions" like "time zone" that do not require user consent, or "dangerous permissions" such as access to contacts, location, and read/write messages that requires explicit user consent [9,41]. Permissions requested by the app are shared within the project, and libraries do not need to ask for second permission from the user or the developer to access shared resources [36,40]. Third-party libraries not only collect data in free apps but also from paid apps [4,18], opening up the question of why developers make such choices? Our study expands ad network literature by studying developer-facing privacy information and options in ad networks.
Dark patterns are "instances where designers use their knowledge of human behavior (e.g., psychology) and the desires of users to implement deceptive functionality that is not in the user's best interest" [17, p. 1]. Some common dark patterns are (1) nagging: when an interface interrupts user workfow consistently and asks for a certain action from them, (2) preselection: values set to defaults that are in the best interest of the provider prior to user interaction, (3) aesthetic manipulation: graphical elements used to deceive the user into taking an action that may be in favour of service provider rather than the user, (4) forced action: users are given only one option to follow even if that is not what they prefer to do, (5) toying with emotion: elements, colours, or language to provoke user's emotion to get user make a decision that is in favour of the service provider, and (6) false hierarchy: options that are in the best interest of the service provider are in higher positions [17]. As such patterns become prevalent in the digital world [5,6,10,12,13,17,27,31,32,51], we are keen to explore the presence of them in tools and libraries that developers use, specifcally, in ad networks.

METHOD
We conducted a walkthrough with two reviewers (similar to a pair-programming activity) of four highly popular Android ad networks [1]: Google AdMob (GAM), Amazon Mobile ad network (AMN), Facebook Audience Network (FAN), and Twitter MoPub (TMP). Reviewers started by searching for "[ad library's name] Android. " on Google which is one of the primary tools developers use to fnd information [29]. Doing so produced the ofcial guidance on how to integrate the library into an app for all four ad networks. This guidance was then accessed and followed to integrate interstitial ads into a hypothetical app, including creating an account. While stepping through the guidance, the reviewers noted any material provided that related to privacy as well as any links to other materials that might be privacy-related which were then visited later. The two reviewers discussed all material as they went through it and agreed on the observations. All websites were visited on a Firefox v79.0 with a UK-based IP address in August 2020. In total, we spent 15.5 hours on the four ad networks; 6 hours on GAM, 3 hours on AMN, 2.5 hours on FAN, and 4 hours on TMP. GAM took most of the time since it had the most materials.
Privacy. In advance of the review, the researcher reviewed prior work on how developers think about privacy on Stack Overfow [48], an ad networks study with developers [30], and in the privacy by design framework [20]. Developers tend to associate privacy with permissions, data collection and management, information disclosure, privacy policies, and laws and regulations associated with privacy such as the General Data Protection Regulation (GDPR) [35], California Consumer Privacy Act (CCPA) [34], and Children's Online Privacy Protection Act (COPPA) [7].
Reviewers. A researcher with four years of experience in usable security and privacy research and four years of experience in software engineering, and a senior software engineer who we will call Abi who has a computer science degree and 11 years of experience in Android development, went through all the content. Abi has written over 40 apps for corporations that have users from hundreds to millions, creates online Android programming video tutorials, and is fuent in Java. Because he develops apps for corporations, he had not previously worked with ad networks and was, therefore, able to look at the pages with experienced, but fresh, eyes.
Limitations. Both Abi and the researcher have extensive experience in their respective felds, reducing the chances of missing the relevant information. However, we note that the results are not generalisable to all developers and ad networks. We focused on the developer-facing information and did not go through the legal documents, terms of services, and privacy policies. We are not aware of studies on developers behaviour when dealing with a privacy policy, but the general public's attitude towards privacy policies is to skip or spend less than 90 seconds reading them [33]. Notably, we conducted the study during COVID-19 pandemic when many businesses were either closed or doing remote work which may have impacted the resources that ad network companies spend on their documentation, websites, and guidelines.

FINDINGS
This section includes the information that was found in guides, linked-to content (supplemental documentation), and in the developer's dashboard. Section 4.5 consists of dark patterns that the research team found during discussions after reviewing the screenshots taken during the review procedure. Table 1 in the Appendix provides an overview of the available privacy information and where they are located, Appendix A shows the screenshots.

Google AdMob (GAM)
GAM provides developers with a clear step-by-step guide and also a consistently-visible sidebar with many links to other materials ranging from how to handle custom events to CCPA. We found the documentation easy to navigate with an everything-in-one-place tone to the user interface.
Guide. A step-by-step guide is included in Get Started page with videos, sample code, and some minimal explanation text. Privacy wise, it has a warning under initialising mobile ads about obtaining consent "from users in the European Economic Area (EEA)" and directs the developer to set request-specifc fags such as "tagForChildDirectedTreatment" or take other actions before initialising the SDK because it may preload ads. None of the terms in the warning were linked (Figure 1). Supplemental Documentation. GAM provides a fair amount of extra privacy-related information, most of which is linked directly of the sidebar. CCPA Preparation appears just below the "Get Started" and "Test Ads" items on the sidebar, so it is relatively prominent. It starts with a link to another set of instructions that explains CCPA and provides guidance on how to restrict data processing via the developer's account page. The CCPA Preparation page itself provides code examples of how to restrict data processing in code via either the Google RDP signal or the IAB ("consortium charged with producing and helping companies implement global industry technical standards" [24]) signal. Notably, the Google option defaults to restricting data processing, but the IAB code example has only a placeholder and requires the developer to open IAB specifcations to construct the parameter string. The in-code setting also overrides any setting in the developer's account page, which may be confusing to some.
The EU Consent option takes the user to the User Messaging Platform SDK which causes all the AdMob branding and sidebar to vanish. The page provides step-by-step instructions on how to use the SDK with many code examples. Notably, the SDK appears to handle user-facing messaging itself so developers cannot easily change it. The example code also puts user consent in a loop so if the user dismisses the popup, it just reloads ( Figure 2). A comment in the code states: "Handle dismissal by reloading form. " The Precise Location Data Policy page frst links to Google Publisher Policies and notes that there are "notice and consent requirements for publishers who pass users' precise location data to Google, for ads-related purposes. " Then provides sample code which asks the user for consent to use their location. There are several points about this code sample ( Figure 3). First, Abi immediately spotted the "we may use your location . . . for the purposes of personalized advertising" which is misleading because the location data is defnitely being used for this purpose. Second, the popup only provides an "OK" option. Third, the text provides a URL to "our" privacy policy that leads to a Chinese Android app market page. Presumably, the developer is meant to link to their own privacy policy which will explain how GAM will use location information. Though, we were unable to fnd any guidance about what a developer should write into such a policy. Fourth, Abi further pointed out that showing multiple popups that do not even belong to his app will annoy users and is the last thing he would do while building an app.
The sidebar also contains several pages on Mediation which is a GAM service that lets developers load ads from other ad networks through GAM. None of the sidebar options are obviously about privacy. However, information about GDPR and other regulations does appear in the instructions under "Optional steps" for some ad network partners. For example, the guidance for Facebook Audience Network discusses GDPR and CCPA but provides no example code. The guidance for both AdColony and AdLovin tells the developer that they are obliged to get user consent and then provides sample code that indicates that the user has given consent.
Dashboard. During account and app creation procedures, GAM encourages developers to share data with other Google services like Google Analytics and Firebase to "optimize your app's user experience and your ad revenue. " These items are also preselected to maximum data sharing (Figures 4, 5, and 6). "Blocking controls" provides several privacy options such as sensitive categories, ad content rating, CCPA, EU user consent, and ad networks ( Figure 8). Sensitive categories are all allowed by default using grey toggle switches (e.g. "References to Sex" and "Religion") except for "Gambling & Betting (18+)" which is blocked using a blue toggle switch. On the content rating page (Figure 7), the setting is set to "Mature Audiences" with a bar that allows developers to change the audiences to "Teens", "Parental Guidance, " and "General Audiences. " When trying to lower the setting, it provides a red box saying: "Est. impact of changing MA to PG: -29 to -57% impressions, -31 to -64% revenue . . ." Developers further can limit ads personalisation for California and European users ( Figure 9). Defaults for these pages are set to "Don't restrict data processing," "Personalised ads," and use all common advertising partners. Under the ad networks page ( Figure 10), a list of partners is shown with over 5,000 partners that GAM shares data with; they are all set to "allowed" with grey looking toggle switches. The only option that is set to on is "Automatically allow new Google-certifed ad networks" with a blue toggle switch that does not have an "allowed" or "blocked" text like others. The funding choices, a service provide by GAM to assist developers in building a consent popup, includes two choice, the frst choice does not include a "Do not consent" button, while the second nearly-identical choice does (Figures 11 and 12).

Amazon Mobile Ad Network (AMN)
AMN's top search result contained no step-by-step page and instead directed us to their main Mobile Ads page which had a "getting started" section of links. Going through the process of integrating the library involved pages that were flled with links to other pages, which in turn also contained many links. The number of pages necessary could easily be overwhelming to a developer.
Guide. We treat the "Get started" section on the Mobile Ads page as the guide. It contained four pages: download SDK, FAQ, account sign up, and publishing apps. To add ads to an app, all the pages except FAQ would need to be gone through, so technically FAQ could be skipped. However, the FAQ was the frst thing Abi wanted to read in the hope that it will contain some useful information. He found all the provided links confusing and not related to "how to add an ad." Unlike the GAM pages, the AMN pages were very text-heavy and had no clear set of steps for developers to follow. Only the FAQ page contained any privacy-related information. The FAQ page had questions on CCPA, GDPR, monetizing EU trafc, managing what ads appear, geolocation from EU, and users' ability to opt-out of tailored ads. COPPA was also briefy mentioned in an answer. AMN does have a Quick Start Guide linked of of the FAQ page. However, its omission from the main Mobile Ads page and its low position on Google search make it unclear if AMN considers the page a primary entry point for developers. The page is a stepby-step guide to incorporating the API. It also contains information about how to optionally set up both coarse and fne grain location permissions to enable "relevant targeted ads" and points out that doing so will likely result in higher revenue ( Figure 13).
Supplemental Documentation. AMN locates nearly all their privacy information on the FAQ page and directs developers elsewhere to fnd general information on the CCPA transparency framework and to fnd specifcs about IAB standards and targeting options. The questions for CCPA says that "you can pass us the user choice signal via the instructions below so that we can honor that choice" and then provides a sample code that sets us_privacy to 1---and says in the comment "example privacy string value." When we looked at the linked IAB documentation ( Figure 14) we realised that "-" means "Not Applicable. " The sample code also sets the location tracking on by enableGeoLocation(true) (Figure 15). The GDPR question only asks to set two fags for GDPR purposes without providing any other materials.
Dashboard. AMN provides a minimal set of privacy settings in the account page allowing developers to "Block Product Categories" where all the items are set to on by default ( Figure 16). It also includes an option to "Include Ads From 3rd Party Networks" with a "Yes/No" radio button (default is set to "Yes") without giving a list of partners. These settings are located in a tab bar next to "My account, " "Tax Identity, " and "Company Profle. "

Facebook Audience Network (FAN)
FAN's guidance was very prescribed with clear step-by-step instructions, lots of screenshots, and example code. Similar to GAM they had a consistent sidebar, but with a deep auto-collapsed hierarchy. So a developer can easily see where they are but might have to expand several times to fnd specifc content.
Guide. FAN provides a Get Started with Android guide to developers along with a guide to adding interstitial ads. Neither guide provides any privacy information.
Supplemental Documentation. The FAN sidebar has no privacy-related terms visible at the default expansion. The "Guides" sidebar option opens to show options for pages about COPPA and CCPA but not GDPR. The COPPA page provides guidance on what "child directed" means and what fags to set, though when we looked up the stated fags, they did not exist in the linked API's documentation. The CCPA page provides code to use for both manual and library-detected setting of location.
Dashboard. "Blocking" is on the sidebar of "Monetisation Manager" next to pricing and performance. It provides options to block ad categories in sensitive and general categories ( Figure 17) that are all unchecked (allowed) by default (e.g. "Associated with violence, " "Gambling, " and "Mature apps"). It also provides an option to limit data use but it is set to of by default ( Figure 18).

Twitter MoPub (TMP)
Get Started with MoPub provides step-by-step instructions, many of which require a visit another page to complete the step. However, all the pages appear with the same sidebar, and the UI shows where the developer is in the site organisation as well as providing a clear "Get Started" link at the top of the sidebar so they can easily return to the main guide page. Each step also ends with encouraging statements like "Terrifc: you've completed Step 4 of 7. " Guide. The TMP guide Get Started with MoPub has seven steps each of which contain a mix of text and links to other necessary guides, such as guides for integrating MoPub into Android, iOS, and Unity. Many of these are clearly on the critical path for a developer trying to integrate ads, but the guide text also contains recommended steps to do things like "refer to our best practices" with links. The Integrate the MoPub SDK for Android warns developers at the top that if they are upgrading they may have to do extra steps for GDPR and links to GDPR guidance which is also linked of the sidebar. The current SDK's behaviour is to auto-detect the user's coarse location using the truncated IP address and then automatically asks for consent from EU users without the developer needing to take action, hence the primary guidance does not directly cover GDPR. The sample code provides optional permissions with fne location data collection ( Figure 19).
Supplemental Documentation. The frst line in the GDPR page, described above, tells developers to read another page frst; making it difcult to follow the instructions: "Do not start this article until you read our GDPR Publisher Integration Guide to understand the fow of events that you will implement below. " Otherwise, TMP provided no other privacy guidance, and terms like CCPA and COPPA are not mentioned in guide pages.
Dashboard. The app application process requires developers to agree to a statement that their app does not target children younger than 13 years old. When clicking on our account name up in the right corner, content blocking shows up next to account settings, and log out. Some items are blocked by default (e.g. "Spyware/Malware," "Hate Content," and "Extreme Graphic/Explicit Violence") and cannot be unblocked ( Figure 20).

Defaults Laced With Dark Patterns
While ad networks make it clear that it is developers' responsibility to make choices and be compliant with the regulations, ad networks make use of range of known dark patterns to nudge developers to make choices that are in the best interest of ad networks.
Developer-Facing Dark Patterns. Ad networks use toying with emotion by hinting that developers get higher revenue or better analytics by sharing more data with ad networks and enabling options like higher content ratings (e.g. mature audiences). Preselection used by all ad networks: regulation defaults are set to of, data collection is not limited, personalised ads are allowed, user consent is by default set to true in sample code, and content categories are all set to on (except for TMP that has a few categories set to of by default). GAM uses aesthetic manipulation in the content categories UI by having a blue toggle represent blocked items and a grey one for allowed items; TMP also uses a similar pattern with blue for blocked items. GAM uses false hierarchy by making the frst option on the consent popup builder not include a "Do not consent" option, while the second nearly-identical choice does. Moreover, privacy information is hard to fnd in all the ad networks, representing the hidden information dark pattern. Abi pointed out that if privacy requirements are buried under sub-pages, advanced options, FAQs, or called "optional, " it is not realistic to expect developers to fulfl those requirements. Privacy options should be part of the workfow, included in the step-by-step ad building guides like the other steps.
User-Facing Dark Patterns. Dark patterns in ad networks also target users. Sample code provided by GAM continues to ask for user consent even if they decline it, which is a clear example of nagging behaviour. Other examples in GAM include notifying the user about using location without giving them any options to refuse, or providing consent popups that do not have a "I do not consent" button; both of these instances represent a forced action dark pattern that could end up in developers' apps.

DISCUSSION AND FUTURE WORK
Drivers of Privacy. The need to comply with legal requirements like GDPR and CCPA drove much of the privacy-related content presented by ad networks. The need for users to consent to permission usage was also a large driver. Most mobile operating systems require user consent before apps can access specifc data and resources, like location. This requirement seems to have compelled ad networks to provide instructions around enabling the permissions and getting the user to consent to their usage. Prior work on privacy-related questions developers ask on Stack Overfow [48] observed developers rarely asking regulation-related privacy questions. However, a fairly large number of questions were related to construction and consequences of accessing resources in privacy policies. The overlap between the two works suggests that ad networks are interested in following regulations by providing fags, settings, and consent examples to developers, while developers are looking for advice on how to write privacy policies that properly express the impacts of including third-party content; information that ad networks do not currently provide.
A potential solution for the challenging privacy tasks may be providing tools to developers which can assist them in making more privacy-friendly decisions by making easy-to-use options available to them [21]. But there are few tools that help developers write things like user-friendly consent popups and accurate privacy policies, and even fewer that take into account both regulations and the current behaviours of common third-party APIs [44,46], like ad networks. A line of future research would be to look into the practicalities of creating such a tool, potentially learning from usability studies in security APIs [16,23] and notifcations [47]. Ad networks also implied that making the more privacy-friendly choices would negatively impact developers' ability to make money from the ads. Since the only real beneft of adding an ad network to an app is fnancial, these comments may have an impact on developer decisions. Future research is called to look at the impact of choice framing and nudging on developers' decisions, and also the fnancial impact of such choices. Such studies, if presented in developer-friendly language, would have the potential to allow developers to make more informed trade-of decisions.
"Developers Are Responsible": Following Regulations Is a Developer Choice and Responsibility. The ad networks' language implied that following regulations was the developer's responsibility, not the ad networks', which is in contradiction with what developers think: it is ad networks' responsibility to protect user privacy [30]. While some ad networks provide code samples of how to handle legal requirements, they also take care to emphasise that it is the developer's responsibility to make sure they are complying with regulations appropriately. Abi was continuously confused and frustrated with these requirements as he (the developer) was the one who would be blamed for things like permission requests, even though they were being requested by the ad networks. For example, AMN provides brief documentation for CCPA and says: "We realize that you will determine what the CCPA means for your Amazon Mobile Ads integration" making the developer responsible but not providing an adequate guide. When Abi saw that he had to set fags (e.g. Google's RDP and IABUSPrivacy_String) in his app's SharedPreferences and not in the SDK, he was not sure how these changes might impact his liability, because typically he sets fags in the libraries and not in his app's shared space and it was odd that the regulation-related fags were located in a diferent place than the other API fags.
Here Be Dragons: Each Ad Network Has Its Own Unknowns. Ad networks present privacy information in a diferent location, use diferent language and options, and have diferent ways to control privacy options. They also explain how to handle legal requirements diferently as well as difering on who is responsible (developer vs ad network) to do checks. For example, GAM provides consent popups but asks the developer to present it to the user, as opposed to TMP's consent that is handled by TMP. The result for developers is that each ad network is efectively its own uncharted area, requiring a fair bit of time to go through and understand how it handles privacy issues, often also requiring the developer to search beyond what is presented in the quick start guide.
Privacy Run Around. IAB is being used to standardise privacy requirements. However, it is also being used as an information black hole; developers are sent to IAB to fnd documentation on settings and fags that does not exist. AMN page contained information on CCPA, including links to IAB's guidance, relevant fags, and a sample code that shows how to set IAB fags by setting CCPA as not applicable and turning on location tracking. The FAQ question on GDPR provides several concrete fags that the developer can set but does not link to documentation on the setting options. We tried looking for guidance on the "consent string" called IABTCF_TCString but could not fnd its correct formatting on AMN or IAB. The FAQ page makes it clear that the IAB consent must be used if the developer wants to make money from EU trafc. GAM also asks developers to use IAB fags, but does not say how. Other black holes that ad networks send developers to visit are main regulation pages under the government sites or privacy policy pages of the parent corporations. Abi was not sure about the usefulness of such links for developers who do not have a legal background and said that he needs a lawyer to understand all these acronyms, terms, and conditions. Future research is needed to build and evaluate a usable framework for presenting privacy information to developers.
Can Developers Make Informed Choices? We fnd that ad networks use dark patterns to nudge developers to choose personalised ads and share more data, much like users resulting in a "control theatre" rather than giving developers a chance to make informed choices. We hypothesise that the low rate of GDPRcompliant consent popups in websites [15,28,49] and the abundance of non-compliant Android apps [26,37,39,54] may partially be because developers are not making informed decisions and are either not aware of the consequences of their choices on users or not aware of how to do a better job than the defaults suggest; hence, not because of their ignorance for user privacy. Opinions about dark patterns are mixed; they are viewed as an ethical issue or a violation of law [51,52]. A recent study by Norwegian Consumer Council shows that instances of data sharing in ad networks (e.g. TMP) appear to be illegal under GDPR [14]. Future research could look at ways to, at minimum, inform developers about these patterns, and regulators could work towards enforcing regulations beyond satisfying requirements like having a privacy policy or terms of service that only a few people may pay attention to.

ACKNOWLEDGMENTS
We thank Yashar PourMohammad for doing the walkthrough with us, and everyone associated with the TULiPS-Lab at the University of Edinburgh for helpful discussions and feedback. This work was sponsored in part by Microsoft Research through its PhD Scholarship Program and a Google Research Award.

A SCREENSHOTS & SUMMARY OF PRESENTED PRIVACY-RELATED INFORMATION
Here, we provide a list of screenshots (as of Jan 2021), that have a privacy element or a dark pattern. Table 1 provides an overview of the available privacy information and where they are located. Here's an example of how to call the initialize() method in an Activity:

Connect
Example MainActivity (excerpt) If you're using mediation, wait until the completion handler is called before loading ads, as this will ensure that all mediation adapters are initialized.

Select an ad format
The Mobile Ads SDK is now imported and you're ready to implement an ad. AdMob offers a number of different ad formats, so you can choose the one that best Uts your app's user experience.

Banner
Rectangular ads that appear at the top or bottom of the device screen. Banner ads stay on screen while users are interacting with the app, and can refresh automatically after a certain period of time.
If you're new to mobile advertising, they're a great place to start.

Implement a banner
Interstitial Full-screen ads that cover the interface of an app until closed by the user. They're best used at natural pauses in the bow of an app's execution, such as between levels of a game or just after a task is completed.

Implement an interstitial
Native Customizable ads that match the look and feel of your app. You decide how and where they're placed, so the layout is more consistent with your app's design.

Rewarded
Ads that reward users for watching short videos and interacting with playable ads and surveys. Good for monetizing free-to-play users.
ConsentStatus.NOT_REQUIRED : User consent not required. For example, the user is not in the EEA or the UK.
Alter your loadForm() method like so: If consent is not required, you can maintain a reference to the form so that your user can change their consent status.

Testing Force a geography
The UMP SDK provides a way to test your app's behavior as though the device was located in the EEA using the setDebugGeography() method on ConsentDebugSettings.Builder .
You will need to provide your test device's hashed ID in your app's debug settings to use the debug functionality. If you call requestConsentInfoUpdate() without setting this value, your app will log the required ID hash when run.
To force the SDK to treat the device as though it is not in the EEA or the UK, use DebugGeography.DEBUG_GEOGRAPHY_NOT_EEA . Note that debug settings only work on test devices. Emulators do not need to be added to the device ID list as they have testing enabled by default.

Reset consent state
In testing your app with the UMP SDK, you may Tnd it helpful to reset the state of the SDK so that you can simulate a user's Trst install experience. The SDK provides the reset method to do this.

Delay app measurement (optional)
By default, the Google Mobile Ads SDK initializes app measurement and begins sending user-level event data to Google immediately when the app starts. This initialization behavior ensures you can enable AdMob user metrics without making additional code changes.
However, if your app requires user consent before these events can be sent, you can delay app measurement until you explicitly initialize the Mobile Ads SDK or load an ad.
To delay app measurement, add the following <meta-data> tag in your AndroidManifest.xml .   Figure 2: Obtaining Consent with the User Messaging Platform page in GAM provided a sample code for obtaining consent from users that constantly shows the popup to the user until they consent. Developers who use this sample code spread a "nagging" dark pattern in their apps.

Complying with our Precise Location Data Policy
Java Kotlin protected void presentConsentOverlay(Context context) { new AlertDialog.Builder(context) .setTitle("Location data") .setMessage("We may use your location, " + "and share it with third parties, " + "for the purposes of personalized advertising, " + "analytics, and attribution. " + "To learn more, visit our privacy policy " + "at https://myapp.com/privacy.") .setNeutralButton ( Figure 3: Precise Location Data Policy page in GAM provided a sample code for obtaining location consent from users without providing a "I do not consent" or "No" button. Developers who use this sample code spread a "forced action" dark pattern in their applications. Upon project creation, a new Google Analytics property will be created and linked to your Firebase project. This link will enable data Mow between the products. Data exported from your Google Analytics property into Firebase is subject to the Firebase terms of service, while Firebase data imported into Google Analytics is subject to the Google Analytics terms of service. Learn more.

United States
Previous Create project Figure 4: Google Analytics had the default option on to share our data with Google (GAM). Turning of the default option would result in seeing a list of sub by default on permissions for all the grey items (e.g. Google products, Benchmarking). "Preselection" dark patterns happens here as the default setting to share information between multiple services is not in the best interest of user privacy.

Support · Terms · Privacy Policy
Welcome to Firebase!  Figure 5: Google Analytics is turned on by default when creating an account on Firebase (GAM). "Preselection" dark patterns happens here as the default setting to share information between multiple services is not in the best interest of user privacy. Figure 6: When creating an app on GAM, we were asked to enable users metrics for powerful reports. The box was pre-ticked. "Preselection" happens here as sharing user data with multiple services is not in favour of user privacy. Est. impact of changing MA to PG: -29 to -57% impressions, -31 to -64% revenue (AdMob Network ads only) Estimates are based on historical network data and not an indication of future performance. Setting the maximum ad content rating at an ad-request level affects these percentages.   Figure 8: In the GAM account page under Blocking controls we could "allow" or "block" certain categories. The use of grey and blue colour to use "aesthetic manipulation" dark pattern is easily visible. Grey commonly has a passive and negative tone whereas blue is known to have a positive tone [53].

Blocking controls
Ad networks # Use this page to allow or block certain ad networks from advertising in your app.

Preferences
Google-certi<ed ad networks may be noti<ed of your allow & block settings (including advertiser URLs and categories), so that they may comply and show appropriate ads. These networks compete for your ad inventory, potentially increasing your total AdSense revenue.
Automatically  Figure 10: In the funding choices service we could "allow" and "block" certain ad vendors. All vendors were "Allowed" by default. GAM pre-ticked the box for automatically adding new vendors to list. 'Preselection" dark pattern spreads via this interface to end-users if developers do not make an effort to change the defaults.

How the California Consumer Privacy Act affects you
The California Consumer Privacy Act (CCPA) is a data privacy law that may require you to give California residents the choice to opt out of the sale of their personal information.
Learn more about the California Consumer Privacy Act.

Restricted data processing
You can choose from two options for users that Google determines are in California. If you want to continue to show personalised ads, tell us the partners that you want to monetise your ads with below. By default, data processing isn't restricted and personalised ads will continue to show.
Don't restrict data processing Google continues to show personalised ads to eligible users in California. Personalised ads are based on a user's past behaviour, such as previous visits to sites or apps or where the user has been.
Restrict data processing Google restricts how it uses certain unique identiFers and other data. Google only shows non-personalised ads from Google demand to eligible users in California. Non-personalised ads are based on contextual information, such as the content of your site or app.

Select advertising partners
Select advertising partners that are eligible to monetise ad inventory for users that Google determines are in California, US. Advertising partners include your Open Bidding partners as well as Authorised Buyers partners and Google demand sources. These partners can receive bid requests from your account to compete for ad inventory via real-time ad auctions. Your selection does not affect mediation.
Use all active advertising partners All active advertising partners are eligible for bid requests from users that Google determines are in California. New advertising partners are automatically added and eligible for these requests. You'll be notiFed when new advertising partners are added.

Use custom list
Only selected advertising partners are eligible for bid requests from users that Google determines are in California. New advertising partners are not Learn more about how EU user consent affects you

Select the type of ads that you want to show
You can choose from two ad serving options. If you don't make any changes, personalised ads will continue to show for EEA and UK users. Your selection will not affect mediation.

Personalised ads
Google can show personalised ads to your users in the EEA and the UK.   Figure 11: Funding choices is a service from GAM to create consent popups. It provides two ready-to-use consent popups to developers, the frst option does not have a "Do not consent" button. Figure 9: CCPA and GDPR sections of GAM have preselected items for information processing and personalised ads. "Preselection" dark pattern occurs here because GAM by default collect information and also shows personalised ads (hence collects more information as well).

Measure content performance
The performance and e!ectiveness of content that you see or interact with can be measured. View details

Consent
Legitimate interest !

Apply market research to generate audience insights
Market research can be used to learn more about the audiences who visit sites/apps and view ads. View details

Consent
Legitimate interest !

Develop and improve products
Your data can be used to improve existing systems and software, and to develop new products View details

Consent
Legitimate interest !

Ensure security, prevent fraud, and debug
Your data can be used to monitor for and prevent fraudulent activity, and ensure systems and processes work properly and securely. View details

Technically deliver ads or content
Your device can receive and send information that allows you to see and interact with ads and content. View details

Match and combine o!ine data sources
Data from o"ine data sources can be combined with your online activity in support of one or more purposes View details

Link di"erent devices
Di!erent devices can be determined as belonging to you or your household in support of one or more of purposes. View details ! ! ! ! In situations where the digital property has determined that the consumer does not fall within a US Privacy jurisdiction (such as CCPA), the digital property may signal this with hyphens in the second, third, and fourth character positions in the following manner: "1---". Otherwise, when signals are present, the consumer falls within a US Privacy jurisdiction. The hyphen character may also be used to signal an unknown state in the second (Explicit Notice) and fourth (LSPA Covered Transaction) character positions.

NOTE:
The third character position (Opt-Out Sale) cannot be unknown (must never include a hyphen) when CCPA applies.

Examples
The following examples provide a sample US Privacy String that represents the stated conditions. In all but the last example, a digital property has determined to use a US Privacy String and that CCPA applies to the transaction. In this example, a digital property has determined to use a US Privacy String and that CCPA does not apply to the transaction.

URL Parameters
A URL-based service that requires US Privacy signals should accept a US Privacy String according to the following conditions and URL parameters: The digital property creating the URL should ensure that the us_privacy parameter exists only once in the URL.
The URL-based service accepting the request is capable of interpreting the US Privacy String and propagating it to other services.
Optionally, substitution macros can be used with the following naming convention:   The Amazon Mobile Ads API requires the com.amazon.device.ads.AdActivity to be declared in your app's AndroidManifest.xml file. Please add the following AdActivity declaration within the application tags of your AndroidManifest.xml file:

Permissions
Making ad requests to the Amazon Mobile Ad Network requires the INTERNET permission. We also highly recommend including permissions for ACCESS_NETWORK_STATE and ACCESS_WIFI_STATE . These additional permissions allow Amazon to provide relevant, targeted ads to your users, which may result in higher CPMs.
These permissions, as well as any additional permissions, need to be declared outside of the application tags in your AndroidManifest.xml file. See the permission declarations below: The ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permissions can also be included to allow location-based targeting. Including one of these permissions allows Amazon to supply highly relevant targeted ads and may result in higher CPMs. If either of these permissions are included, they should also be declared in the same way:

Example Manifest !
For an illustration of how these declarations are implemented into an AndroidManifest.xml file, please refer to the example below:   Figure 13: AMN in the Quick Start Guide page asks developers to add internet, network, wif access, coarse and fne location for higher revenues for developers. While location permissions are called as "optional" the sample code includes both fne and coarse location permissions. "Sneak into basket" dark pattern is present here because developers may copy paste this code without fully being informed about what the sample code does.

General & Overview
Q: What is the Amazon Mobile Ad Network?
The Amazon Mobile Ad Network connects advertisers with mobile apps and game players. The Amazon Mobile Ads API serves display ads from Amazon and brand advertisers in your apps. By delivering relevant messages to your users at the right time, we are able to offer great eCPM.

Q: What apps are supported?
The Amazon Mobile Ad Network supports Android, iOS, and FireOS apps currently published on a recognized app store (e.g., Google Play Store, Apple App Store, Amazon Appstore, Samsung Galaxy Store).  ....
[self.adView loadAd:options]; Figure 15: AMN's sample code in their FAQ page. enableGeoLocation is switched on in the sample code ("sneaking" [17]). "1---" is provided as an example privacy string value. "1" means version 1 and "-" means "Not Applicable." Two dark patterns are visible here, if developers copy paste this code "sneak into basket" occurs and "preselection" also happens because the defaults are not in favour of user privacy (see Figure 14 for IAB code samples.)    The two blocked options are blocked by us. "Preselection" dark pattern happens here as developers may never visit this page and the defaults are not in the best interest of end-users. The green bar on the top right corner will change as developers pick several items, hinting a loss of revenue as they block more categories.