Internet Safety Labs believes product safety is a human right, and that everyone deserves to know what's happening "under the hood" of technology. Independent product safety testing is crucial for all the products in our lives, and ISL serves that function for software and software driven technology.
We can't do it without your support.We take no funding from industry so you can be sure that our research and Safety Labels are designed to keep people safe and informed, first and foremost.
If you find value in our research and tools, please consider a donation to support our mission to measure and expose safety risks in software.
App Microscope is a tool to display the Internet Safety Labs safety label (ISL Safety Label) for mobile applications. The information in the ISL Safety Label is designed to highlight safety risks found in the app when using it as it was designed to be used. ISL calls these inherent risks “programmatic harms”.
Most of the labels in App Microscope are from the more than 1,722 apps studied in the ISL 2022 K-12 EdTech safety benchmark. New labels are being added all the time.
App Microscope is designed for app developers, technology decision-makers, journalists, privacy advocates and regulators, but can be used by everyone to better understand the hidden risks of mobile apps.
App Microscope is a free public service, funded in part by a generous grant from the Internet Society Foundation. ISL is a US-based 501(c)(3) non-profit organization.
The purpose of the ISL Safety Label is to help various audiences understand what’s happening “under the hood” of mobile apps.
The safety label is organized into risk categories that identify safety risks for people when using the app as it was designed to be used. The label is designed to add risk categories over time. Currently, the label includes only one risk module: Privacy Risks, and the team is working on adding additional risks. Note that the Apple and Android logos are used only to communicate the version of the app and do not constitute an endorsement or affiliation with Internet Safety Labs. Each mark is the property of its respective owner.
The high-level structure of the ISL Safety Label looks like this:
All mobile apps carry some risk. The Safety Score and color indicate the level of privacy risk. Note that the ISL app score currently reflects only privacy risks, in particular, the extent of personal data monetization observed in the app.
The ISL Safety Score is a “stoplight” score with five possible values:
Here are the detailed explanations of each score.
The app safety score is fairly complex. The flow chart below illustrates the high level sequence of calculations and checks.
Please contact us if you'd like more information about how risk scores are calculated.
This section provides information on the number and riskiness of third parties found in either observed network traffic or as SDKs in the app. First, the risk assessment based on the observed network traffic.
[Source: From network traffic collection performed by ISL.] Next, the risk assessment of included SDKs.
The App Category Average column displays the average number of SDKs and aggregator platforms for the category of apps. Note that the category is the smallest sub-category as shown in the top part of the label, such as “EdTech -> Safety Platform”.
The “n=number” is the number of apps in that category/subcategory.
This information provides context as to whether the chosen app is behaving better or worse than the category with respect to third parties.
[Source: calculated from ISL app database.]
This section indicates if risky behaviors were observed during manual app test. The following behaviors are key risks:
What is WebView? All mobile apps with an “in-app browser” are using “Webview” code/APIs, and the rules and protections for these in-app browsers differ somewhat between Apple iOS and Android platforms. WebView is a low-level set of functions (APIs) provided by an operating system within a mobile device that allows native apps to present web pages, woven seamlessly into the application without having to open or close a separate browser. WebView allows native apps to selectively become a browser while keeping the user in the app. A 2011 paper on WebView attacks against Android devices explains this legacy development and data supply chain strategy: “WebView is an essential component in both Android and iOS platforms, enabling smartphone and tablet apps to embed a simple but powerful browser inside them. To achieve a better interaction between apps and their embedded “browsers”, WebView provides a number of APIs, allowing code in apps to invoke and be invoked by the JavaScript code within the web pages, intercept their events, and modify those events. Using these features, apps can become customized “browsers” for their intended web applications.” WebView in iOS relies on WebKit, an open-source browser “engine” first introduced 23 years ago in 1998, which later evolved into the Safari engine used by Apple around 2013. The WebView APIs are therefore limited by WebKit capabilities supported in the OS. iOS WebView is restricted and protected by iOS WebKit (built on Safari) limitations, and Android WebView is restricted and protected by a slightly similar concept with Chromium limitations. However, they both ultimately support in-app browsing as a seamless user experience without giving users full control over their own data sharing preferences within these in-app browsers.
The numbers in this column display the percentage of apps in the named category that are positive for the behavior. For example, 60% shown in the Ads Present row means 60% of the apps in the category have ads present. The number of apps in the category (n=32, e.g.) is shown at the very top of the column.
[Source: Calculated from ISL app database.]
This section lists the categories of sensitive permissions the app asks for. ISL has created these categories for ease of understanding the overall risks related to the app’s use of user data accessible from the device. There are eight permission categories (listed in alphabetical order):
[Source: AppFigures, iOS App Store, Google Play Store; permission categories created by ISL.]
This section provides details on the 3rd parties likely to be receiving user data. This section has two main parts: (1) details on the observed network traffic, and (2) details on the SDKs.
Both the observed subdomains and SDKs are scored using the same risk tiers and stoplight scores as the app itself (Some Risk (lowest risk), Medium Risk, High Risk, and Critical Risk (highest risk)).
[Source: From network traffic collection performed by ISL.]
ISL is unable to share the names of the SDKs in the apps, so this section displays the names of the companies behind the SDKs, as well as the ISL designated category.
[Source: AppFigures, ISL SDK Risk Database]
This section contains detailed information regarding what user information the app accesses. This part of the safety label is currently comprised of a single section: Riskiness of App Permissions.
This column shows the percentage of apps in the app category that use permissions in this permission category. [Source: Calculated from ISL app database.]
This information provides a rough approximation of app category behavioral norms for the permission category. When this number is low (15% or less), and there are one or more permissions shown for the app, it can be viewed as atypical behavior for the category. This may or may not be significant depending on the exact purpose of the app.