Aug 29, 2024
Note from Emily: This week’s essay is guest written by Lisa LeVasseur, the Executive Director and Research Director at Internet Safety Labs, a group that does independent research on the practices of Big Tech and EdTech. I love their work and cite it often, and I would be thrilled to have more people know about them.
When you use a mobile app, you're entering into a kind of digital relationship with that developer. The signup process makes it clear that you’re sharing data and perhaps giving money to that developer.
In truth, you're in a relationship with many developers – not just the one that published the app.
When I first started my software career in the late 80s, software was often completely developed by a single developer. They had creative and functional control. As "apps" took off and created a thriving demand for consumer applications (think of the Apple App Store or Google Play), this spawned an incumbent ecosystem of software developers. Third-party software "components" or developer kits also took off to speed up the development process. Fast forward to where we are now, and it's virtually unheard of for an app to not include third-party kits.
An application is like a commercial building. To make a building, you need an architect, a project manager, contractors, and subcontractors. Contractors are specialists in different aspects of the building process who bid to participate in building construction. For example, one contractor may specialize in pouring concrete, and another may specialize in building the metal structure or fitting the building to meet local codes (like an ordinance that covers earthquake requirements).
SDKs (software development kits) provide an aspect of the program so the primary application developer doesn’t have to build the entire application themselves. Perhaps they outsource geo-location and mapping or analytics infrastructure. These equivalents to “construction contractors” can also subcontract out to other developers, and each layer comes with its own risks and agreements.
At Internet Safety Labs (ISL), we believe that app users deserve to know what kinds of risks the hidden components of an application may carry. This article will explore SDKs and how each application component creates data-sharing channels with third parties.
SDKs
Software development kits are very much what they sound like: they are packaged software "kits" that can be added to a piece of software to perform specific functions. They're used so app developers don't have to recreate the wheel, so to speak, particularly for functions that aren't a core competence.
For example, a puzzle game developer may use a component for payment collection – because their team wants to focus on the puzzle game. In this example, they would probably use an SDK from a payment service like Paypal or Stripe rather than write their own credit card processing software. Using a well-known SDK is more efficient than learning how to build an aspect of the app from scratch, and it allows access to a (hopefully) trusted payment processing system.
Getting Biz-y: You can think of SDKs as part of the software development supply chain. In fact, we wish developers would think more rigorously about their software supply chains. Instead of nuts and bolts and other physical parts, it's software parts. Unfortunately, sometimes, the process for integrating SDKs is nothing more than an online click-through agreement.
Yep, the same mechanisms you routinely accept for almost anything on the internet.
In addition to recognizing the software supply chain, there's another supply chain that vendors will need to track more carefully in the future due to regulatory changes. That's the data supply chain –the mix of user information that is volunteered by the user, derived by the app or SDKs, or otherwise procured, and how it is all used and shared.
Software developers, in an ideal world, should know precisely the origins and destinations of all user data in their app – and for what purpose their data is being used (usage information to improve design? identity theft? advertising data to better sell relevant pet products to specific individuals?).
SDKs can be benign and helpful, and sometimes, they can be deliberate mechanisms for data collection and monetization. Internet Safety Labs has been maintaining an SDK Risk Dictionary since 2021. There are currently 583 SDKs in our SDK Risk Dictionary, which cover virtually all SDKs currently used by non-subscription or up-front payment apps in US app stores.
The list includes a safety rating. The lower the rating, the higher the risk that data is being used against the end user’s best interest. Of the 583 SDKs in the ISL SDK Risk Dictionary, 46.0% of them are used for Advertising or Marketing purposes/functions. It's clear that advertisers and marketers understand the data-collecting value of SDKs (it also makes sense that most app developers don't want to create new adtech/martech in their apps).
Figure one below breaks down all the SDKs in the risk dictionary by primary function.
Figure 1
An important fact to remember is that SDKs can access any of the allowed data for which the app has sought permission. If the app asks for permission to access the end user’s address book and their precise geo-location, the SDK code will also be allowed to access that information. The app may need location data, but we should ask whether the SDKs do as well. In the example of using an SDK from Stripe to process payments, do they really need access to your entire contact list in your phone (address book)?
At ISL, we score the privacy risk of SDKs based on the SDK's functions, the privacy track record, and the data monetization practices of the company that developed the SDK. There are companies you may recognize (Meta, aka Facebook and Instagram), and many of them will be new to you.
Figure two below shows the breakdown of the 583 SDKs in our database by risk score. The type of information, paired with the likelihood the data will be monetized (or sold to third parties), determines the degree of risk. With many advertising and marketing SDKs, which are highly incentivized to mine and sell data to improve the performance of ads, it's no surprise that 67.2% of them are either High Risk or Critical Risk.
Figure 2
Exposing App Ingredients
There are currently no regulations requiring developers to publish which SDKs and which third parties they integrate, and currently, neither the Apple or Google app store displays this information. Internet Safety Labs, however, provides detailed component or app-building block labels for all the apps in our 2022 EdTech benchmark through our App Microscope.
In 2022, ISL conducted a US-wide K-12 EdTech safety benchmark, identifying more than 1,700 apps either recommended or required by schools across the US.
We've published several resources from this research, including:
Research:
Tools:
Technology has operated largely under the cover of opacity, but those days are now numbered, and people are increasingly aware of privacy and other risks in technology, and more tools and resources are being developed.