Dangling Domain From SDK Installed in 150+ Apple Apps Putting Kids, Families and Crypto Traders at Risk

Written by Zach Edwards, Lead Data Supply Researcher, with support from Kelsey Nordstrom, Junior Researcher

October 7, 2021

Update:  Comment from the Executive Director:

October 8, 2022

TLDR: The Me2B Alliance believes apps including the AskingPoint SDK should be safe from malicious redirects or other exploits.

After publishing this blog yesterday, the Me2B Alliance received yet another communication from the Apple product security team. Turns out, the real story here is about how Apple responds to responsible security vulnerability disclosures from well-intentioned people and organizations like the Me2B Alliance. Instead of communicating openly and truthfully with the Me2B Alliance, Apple instead chose to feign ignorance through our ongoing series of emails. The Me2B Alliance approached Apple in all diligence and earnestness. And in return we received slow, sporadic and misleading responses.

So what happened since we published this blog? Yesterday, Apple reported to the Me2B Alliance that they were indeed the purchaser of the URL. (Note that we have not confirmed this.)

Which means they knew full well the risks of the dangling domain to the 150+ iOS apps on potentially millions of devices, and their responsibility in keeping iOS apps safe for people.

The good news is that the domain no longer appears to be a risk for those 150+ apps and the potentially millions of users.

The bad news is that Apple could have been more forthcoming and honest with us out of the gate, saving us substantial time and effort that could be spent on other research.

One might reasonably ask:

    1. Why did Apple continue to claim they didn’t understand the risk—even in the email from yesterday?
    2. Why didn’t Apple acknowledge their action of purchasing the domain when we pointedly asked them on September 29, right after the domain had been purchased?
    3. Why did Apple go to some effort to obfuscate their ownership of the domain [i.e. how they purchased it]?

These are, I fear, rhetorical questions. Presumably, the answer to all of these questions is that Apple behaved the way they did to make sure there was not even a whiff of culpability. This attitude of “protect the organization at all costs” is the root source of quite possibly the worst of all the harms technology can bring to individuals and society. We saw it this week on a global stage with the Facebook whistleblower, Frances Haugen. And I witnessed it myself on a smaller scale with ongoing interaction with the Apple product security team.

Others in the technical community have far more experience with security bug reporting than I, and apparently Apple’s less than stellar reputation in this arena is common knowledge. This is my first experience with it and I can’t express how shocked and disappointed I am.

Our intention here at the Me2B Alliance isn’t to antagonize the makers of technology—in fact, it’s the opposite. We want to help makers of technology create safer, more respectful technology. In the past year and a half that we’ve been conducting product testing, quite often we’ve seen that the supply chain is no longer readily understood by vendors—it’s gotten out of control. It’s been an eye-opening revelation, and in particular we want to help vendors better understand their software supply chain.

To have one of the world’s largest platform providers, however, engage in a disingenuous and quite possibly deliberately deceitful manner with a non-profit org about an obvious systemic security flaw is infuriating and unacceptable.

Funny thing about this whole situation: we discovered this AskingPoint security vulnerability completely by chance—in the course of other work. As we note in the blog, our primary research focus right now is on what we believe to be an even larger story.

But, to my surprise, it’s clear that there are two large stories, due to Apple’s questionable handling of our responsible disclosure of a serious security vulnerability.

Stay tuned.

Over the past month, the Me2B Alliance product testing team has been investigating something we refer to as “dangling domains” and the risks they pose to people, especially children and families.

A “dangling domain” refers to any URL/domain previously owned by a legitimate organization or business, but which has been either abandoned due to the business shutting down, or due to a mistake where the organization or business forgets to renew their own domain.

It is far more common than many people realize that local schools and government organizations across the United States register seemingly random domains in order to host a website for a specific purpose or program. It seems like a great idea at the time, but time passes, personnel turns over, and credit cards on the site registrar expire resulting in a “dangling domain.” These dangling domains are available for purchase by anyone, anywhere in the world. If a malicious group purchases a dangling domain, they can set up a new advertising/user data ingestion architecture (honeypots) at the URL, send pop-ups and other scams, and potentially conduct other exploits against the app or users, depending on how each app is set up. Our research has confirmed this behavior.

In a soon-to-be released Spotlight Report, we will be explaining in more detail our “dangling domain” findings as they relate to school utility apps, illuminating significant risks for children, parents and school administrators — and we will highlight advertising companies profiting off the sale of kids’ data.


Today’s post, however, focuses on one specific dangling domain – –  for a company who provided software (SDKs) integrated into mobile apps which we found to be potentially integrated into over 150 iOS apps. We found the dangling domain a couple weeks ago, and last week the domain was purchased by a presently-unknown entity.

Through testing of about 33% of these 150+ iOS apps, about 50% of the apps tested are still attempting to connect to the server to receive code, a connection that is currently broken, but could turn back on at any moment via the new domain owners. These currently-broken requests to the dangling domain were occurring the moment certain apps were opened, without any control for the app users.


AskingPoint was founded in 2012 and according to their website, in 2018 their SDK was being used in “thousands of apps” and “on over 250 million devices.” This statement is slightly dated, but AskingPoint was historically installed on iOS apps with hundreds of thousands of ratings/reviews, and some of the Android apps that previously used Askingpoint had millions or tens of millions of users. Our team is unable to know exactly how many devices currently have apps installed on them who make requests to the dangling domain, but we would anticipate at least several million devices could potentially be at risk of unexpected user data ingestions, ad fraud, or scams/pop-ups/malicious redirects.

Figure 1- Self-Reported Reach of AskingPoint SDK

Figure 1: Self-Reported Reach of AskingPoint SDK (from Feb 3, 2018 archived website on Wayback Machine) was originally owned by KnowFu, who seems to have closed around 2018-2019. This company had “orchestration” features that focused on swapping out advertising vendors, and for many apps, the AskingPoint request is the first or nearly the first request to fire when someone opens the app.

Figure 2- AskingPoint SDK Capabilities

Figure 2: AskingPoint SDK Capabilities (Historical Snapshot via Wayback Machine)

It’s not uncommon for an SDK company to go out of business — it’s expensive to ingest lots of data, and the mobile software space is extremely competitive — solid products go out of business or are sold regularly. At its height, AskingPoint’s website boasted that they were installed on hundreds of millions of devices.

Currently, according to, AskingPoint is installed on 159 apps, with 155 being built for iOS (including iMessage and Apple TV). Historically there were Android apps, but it seems only two remain active (see Figure 3). To view a full list of the apps that SDK database determined still have the AskingPoint SDK, click here.


Figure 3- Breakdown of Apps with AskingPoint SDK

Figure 3: Breakdown of Apps with AskingPoint SDK (source:

Of the 155 Apple iOS apps that still have the AskingPoint SDK installed, from our local tests of about 1/3rd of these apps, we found only about half of the apps were sending data to AskingPoint from the client side. It’s possible that all the apps had the AskingPoint SDK still integrated, but due to the domain being down, many of these integrations could potentially break before sending any client data. For the apps that did try to send data to the dangling domain the app would basically make a request to an old URL on and a specific javascript file, but the request would create a 500 “not found” error, basically a 404/not found error. The new owner of this domain could “fix this file” and start to serve unexpected javascript to users, through apps already installed on their phones.

Prior to this research being published, and during the time when the Me2B Alliance first discovered the AskingPoint SDK’s dangling domain, if you visited directly, you would see that the domain was available for purchase for $3,695.

Figure 4: Domain available for Sale

Figure 4: Domain available for Sale

Once our team realized that there were a wide variety of kids games, crypto apps, and other unique iOS apps that had a dangling domain for a powerful SDK integrated into them, with the domain also being for sale, we immediately sent an email to Apple (specifically, to to request that they purchase the domain, in order to protect the potentially millions of users who were still using any one of these 150+ apps.

Two days after our original email, we sent an additional email with more details, including Figure 1 (above) which showed the potential magnitude/reach of the problem. At this point, we received a human response indicating that they would have someone review the problem.

We continued to wait for Apple to confirm they had purchased the domain.

Then last week, one week after our original email to Apple, suddenly the parked domain was no longer available, i.e. it had been purchased. But by whom?


Figure 5- No Longer for Sale

Figure 5: No Longer for Sale

Did Apple buy this domain?

Nope. (Well, apparently not; we have still not received a confirmation one way or the other.)

Upon seeing the domain purchased, we immediately sent a semi-panicked email to Apple’s product security team asking them if they purchased the domain. Approximately 48 hours after the domain was purchased (and our query to Apple), we received a message late on a Friday afternoon that implied that Apple had not purchased the dangling domain of Shockingly, in this reply  – 10 days after our original report of the security risk – Apple asked for “some additional details…to better understand the possible security impact of this issue.” So not only had they apparently not purchased the domain, but it seems that Apple hadn’t even begun to process the information and risks to end-users. (It should also be noted that we spelled out the problem very clearly in our initial email, including an Excel list of all 150+ apps. And our follow-up email made the potential magnitude – “millions of devices” – clear.)

So now here we are, a week after the domain was purchased, with no information on the new owners or their intent, and a brief audit confirmed that the broken requests are still flowing from the apps, just waiting for a new server to be turned on at

Our testing team at the Me2B Alliance also reached out to the former founder and CEO of AskingPoint, who seemingly hasn’t been involved in the business for a few years. We haven’t heard back at the time of this writing. We will update this post with any new details as they arrive. We believe that it’s very common for software businesses to shut down, and don’t believe that the former AskingPoint team has an obligation beyond notifying their own customers (which seemingly happened).

Our team believes that this “dangling domain” problem is a reality of software supply chains and believe that Apple and Google, and any marketplace that allows apps with unique vendors integrated into those apps, need to have policies to monitor and acquire dangling domains, and deal with the ramifications of a supply chain compromise when a domain isn’t purchased.


As it stands, several weeks ago, the Me2B Alliance found a dangling domain that we could have purchased at any moment for $3,695. Due to the size of our organization, we reached out to Apple to make this purchase and Apple failed to take action for 7 days before the domain was acquired by a new entity. Two days after that, Apple appeared ready to start looking at the problem.

We have no idea who now owns this dangling domain; whether they are in the advertising/audience business, or whether they have any malicious intent. We believe that there are significant risks from dangling domains, and that companies like Apple and Google need clear policies and procedures to quickly acquire dangling domains. Right now, we believe that there are 150+ apps in the iOS store, and apps in other stores that have an SDK integrated into them that sends data to an endpoint, which was up for sale for $3,695.

Just a few years ago, AskingPoint was bragging about collecting data from hundreds of millions of devices. Today, no organizations seem to be collecting data from these endpoints….yet. But in the days and weeks ahead, will there be new supply chain injections against 150+ semi-popular iOS apps used by a wide range of people, including numerous mobile games used by kids?

Everyone who worked on this issue at the Me2B Alliance wants to make it clear that we are deeply disappointed in the way Apple responded to this issue and discouraged that more immediate action wasn’t taken when it was brought to their attention. It’s clear that Apple’s product security team needs a better process for these complex data supply chain disruptions.

Questions? Concerns? Revisions? Contact us at

Additional Note on Local Schools’ Use of .com and .org Domains

Additionally, many of these domains are not on .gov domain suffixes, but instead on .com, .org and other domain suffixes that have no requirements for any other person across the world to re-register one of these dangling domains.

Another way explain this risk: if more schools and local governments used .gov domains for their websites, they would have a slightly slower process to register these domains, but it would also be impossible for them to lose the domains to other random people across the world — there is no such thing as a “dangling domain” on the .gov domain instance, only “compromised domains” or other technical accidents — but the concept of losing control of a domain and not being able to re-establish control doesn’t exist on .gov domains, which is a core reason why, perhaps, schools and local government organizations should be required to shift their ad hoc websites to only use approved .gov domains.

Want to Explore for Yourself?

Here are just a few of the apps you can download if you are an auditor, to confirm and see the dangling domain:

Wordoji – Easy Sticker Maker

  • Developer: RTC Holdings Incorporated
  • App Store Age Appropriate: 9+
  • App Store Link:
  • Last Updated: Nov 29, 2018
  • Privacy Label (Yes/No): No
  • Confirmed request firing in app: Yes

Baby Pic Studio: Cute Stickers

Crypto Tracker & Price Alerts

Crypto Converter: Live Prices

Currency Converter: Calculator

  • Developer: Journo Inc.
  • App Store Age Appropriate: 4+
  • App Store Link:
  • Last Updated: Apr 21, 2020
  • Privacy Label (Yes/No): No
  • Confirmed request firing in app: Yes

Packing List Travel Planner

Nomadic Wall.paper – Travel Inspired Digital Pictures, Art Slideshows & Wallpapers

Hockey Stickers – Animated!

Teddy Bear Cops

  • Developer: Psycho Bear Studios
  • App Store Age Appropriate: 12+
  • App Store Link:
  • Last Updated: Jul 14, 2015
  • Privacy Label (Yes/No): No
  • Confirmed request firing in app: Yes


  • Developer: LoftLab
  • App Store Age Appropriate: 4+
  • App Store Link:
  • Last Updated: Feb 18, 2015
  • Privacy Label (Yes/No): No
  • Confirmed request firing in app: Yes