About App Microscope
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”.
The current version of App Microscope contains 1722 apps studied in
the ISL 2022 K-12 EdTech safety benchmark. Over time, App Microscope will be
able to generate safety labels for all apps.
App Microscope is designed for app developers, school technology
decision-makers, journalists, privacy advocates and regulatory
enforcers, but can be used by everyone to better understand the hidden
behaviors 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.
About the ISL Safety Label
The purpose of the ISL Safety Label is to help people understand what’s
happening “under the hood” of mobile apps.
The safety label is organized into Risk Modules that identify safety
risks to people using the app as it was designed to be used. The label
is designed to add on harm/risk modules over time. Currently, the label
includes only one risk module: Privacy Risks.
Other envisioned risk modules include:
- Harmful UX Pattern Risks and
- Automated Decision-making 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
ISL Safety Label Structure
The high-level structure of the ISL Safety Label looks like this:
ISL Safety Score & Triggers
The ISL Safety Score is a “stoplight” score with four possible values:
- Some Risk (green)
- High Risk (yellow)
- Very High Risk (red)
- Not Scored (blue)
Here are the detailed explanations of each score.
- Some Risk:
- This represents the “safest” of all safety scores. Note that
“no risk” is not an option in the ISL scoring rubric as all apps
entail some level of risk.
- High Risk:
- Apps that receive this rating meet at least one of the following
high risk criteria:
- Presence of high risk SDKs
- (at least one ISL scored Very High Risk or High Risk SDK).
- App’s use of Webview APIs
- to launch web content within the app. The main problem with
Webview APIs are that they launch the platform’s default
browser, not the user’s preferred browser, including
preferred privacy settings. See
What is Webview
for more details.
- Presence of data aggregators, Google or Apple,
- as determined from either the presence of SDKs or network
- Presence of one or more dangling domains in the app.
- A dangling domain is domain that is available for purchase.
for more information.
- Very High Risk:
- This score represents the least safe apps and ISL recommends that
these apps are not safe for students. Apps receive this score if
they meet at least one of the following criteria:
- Presence of advertising
- (of any kind). The safety score doesn’t distinguish between
contextual and behavioral advertising, since no matter what
kind of advertising is present, there’s a very high likelihood
that user data is being shared into advertising networks,
though it has not yet been confirmed. The current adtech
infrastructure is risky because there is no way for the public
to inspect where the data goes or how it’s used.
- Presence of one or more Data Broker’s SDKs
- (per the California and Vermont Data Broker registries).
- Presence of data aggregators as determined by presence of
SDKs or from network traffic analysis:
Adobe, Amazon, Facebook, or Twitter.
- Presence of MaxPreps.
- Refer to
Spotlight Report #4
which examines the extremely risky behavior of MaxPreps, an
advertising-supported school sports platform. MaxPreps is
owned by CBS/Viacom, parent to Disney and used by hundreds
- Suspicious permission behavior:
- Safety tester observed inconsistencies related to app’s
permission behavior, such as the app’s use of resources
without asking for permission.
Note that this score was previously referred to as “Do Not Use” in the
first two 2022 K-12 Edtech Safety Benchmark findings reports.
- Not Scored:
- Apps that were unscored for one of the following reasons:
- App required school login credentials in order to exercise even
- App was broken.
- App was a paid app.
ISL Safety Score Triggers Summary
|SOME RISK||HIGH RISK||VERY HIGH RISK||NOT SCORED|
|Presence of at least one (1) Software Development Kit (SDK) that
is High Risk or Very High Risk||Presence of advertising (any).||App requires school- or institution-provided login credentials to
test core functionality.|
|Use of WebView APIs provided by Apple (iOS) and Google (Android).
Used to display web content within an app without launching a
separate browser.||Presence of one (1) or more registered Data Broker SDKs.||Paid app|
|Presence of up to two (2) of the following data aggregator
platforms (as observed by presence of SDKs or network traffic):
Apple, Google.||Presence of one (1) or more of the following data aggregator
platforms (as observed by presence of SDKs or network traffic):
Adobe, Amazon, Facebook, Twitter. These are very high risk
platforms because they monetize personal data.||Broken app|
|Presence of a dangling domain - i.e. a webpage that indicates
that the domain is currently available for purchase.||App links to and opens MaxPreps.com [using WebView]|
|Suspicious permission behavior.|
Third Parties Receiving Data
This section provides information on the number and riskiness of SDKs in
the app and the number of aggregator platforms receiving data as
observed in network traffic.
- Total # of SDKs:
- This is the total number of SDKs found in the app.
- Risky SDKs:
- This is the number of High Risk and Very High Risk SDKs found
in the app. [Source: SDKs from AppFigures; ISL SDK Risk
Database (to be published in 2023)]
- Data Broker SDKs:
- This is the total number of SDKs found in the app that are
owned by registered data brokers in either the California or
the Vermont data broker registries. [Source: California and
Vermont data broker registries.]
- Aggregator Platforms:
- This is the number of aggregator platforms, 0-6, with whom the app
communicated during the testing session, based on collected
network traffic. The aggregator platforms included are:
[Source: From network traffic collection performed by ISL.]
App Category Average
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 -> Other -> Games”.
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
[Source: calculated from ISL app database.]
This section indicates if risky behaviors were observed during manual
app test. The following behaviors are key risks:
- If digital ads were observed in the app, this field will show “Yes”;
if no digital ads were observed in the app, the field will show
“No”. In this case, “no” is safer and “yes” is riskier. ISL regards
digital ads risky due to the infrastructure of digital advertising
and real-time bidding, in particular, which has the capability to
share personal information to countless entities in the ad network.
[Source: observed by ISL product safety testers.]
- Behavioral Ads:
- This field reports whether the tester observed behavioral ads in the
app. Behavioral advertising refers to the capability to anonymously
‘follow’ consumers across websites, all over the Web. Behavioral ads
are ads that clearly rely on information that has followed the user
from another site. In other words, behavioral ads are using personal
information to customize ads being displayed. This behavior is
extremely risky. As above, a “yes” is riskier than a “no”. [Source:
observed by ISL product safety testers.]
- This field indicates if the app uses Webview to display webpages
within the app. [Source: observed by ISL product safety testers.]
- From pp 8-9 in Spotlight Report #4:
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
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.
App Category %
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
- Crash Logs
- include permissions that allow the app publisher to receive
information when the app crashes. There is a risk of this
information including personal details.
- include any permission that allows apps to list user data files or
their contents, whether in the cloud or on device. This access is
risky both because files and filenames can include personal
information and because it can be used to fingerprint and reidentify
a user even if they have reset other identifiers.
- Join User Identifiers
- includes any permission that directly assists advertising networks
that wish to track users across apps or across device, such as with
Apple’s ID for Advertising (IDFA).
- includes any permission that potentially allows apps to determine
the user’s geographic location. Permissions such as wifi network
names and bluetooth connections are included in this category
because in many cases these names are distinctive and can be
compared against databases to guess the location.
- Phone Service
- includes permissions that reveal who the user’s carrier is or
whether they currently have service. This can serve as a proxy for
location. It may also reveal financial wellbeing.
- Physical Environment
- includes permissions that reveal information about the user’s
physical environment, such as granting access to the camera and
- Social Information
- includes permissions that reveal who the user associates with, as
well as when or where they do so. This includes calendar and
- User Behavior
- permissions include anything that would be useful to advertising
networks seeking to learn more about a user, such as their
psychology or interests.
[Source: AppFigures, iOS App Store, Google Play Store; permission
categories created by ISL.]
3rd Party Sharing Details
This section provides details on the 3rd parties likely to be receiving
user data. This section has two main parts: (1) details on the SDKs and
(2) details on the Aggregator Platforms observed in the network traffic.
- Riskiness of 3rd Party SDKs – by SDK Risk Score:
- This section shows the companies behind the SDKs included in the
app, sorted by SDK risk score. Similar to the Safety Score, the
SDK risk score is a “stoplight” score with Very High Risk (red)
being the riskiest category, High Risk (yellow) the middle
category, and Some Risk (green) being the safest category.
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.
These are the current SDK categories:
- Computer Vision
- Crash Reporting
- Customer Chat
[Source: AppFigures, ISL SDK Risk Database]
- Aggregator Platforms Receiving Data:
- This section lists the aggregator platform companies observed in
the app network traffic. The six platforms are: Adobe, Amazon,
Apple, Facebook, Google, and Twitter.
[Source: From network traffic collection performed by ISL.]
User Data Details
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.
- Riskiness of App Permissions:
- This section lists all the permissions requested by the app.
Permissions are grouped by Permission Category. [Source: ISL]
- Permission Category:
- ISL has created permission categories based on the kind of
information accessed. Note that the same permission may be included
in multiple categories. See above for the list of permission
categories. [Source: ISL]
- This section lists all the permissions that the app either requests
access to or simply accesses without permission. [Source:
AppFigures, iOS App Store, Google Play Store]
- iOS Apps:
- In iOS apps, there are two types of permissions shown in the
safety label: (1) permissions that start with “NS”, and (2)
permissions that don’t start with NS. Permissions that start with
NS actuallyaren'tpermissions but map to fields in the Apple Privacy Nutrition
Label, which are voluntary disclosures made by the app publisher
and are subject to various exceptions that allow the publisher to
not disclose use of certain data as per the fine print in Apple's
- Android Apps:
- The permissions shown for Android apps reflect the actual permissions
requested by the app.
App Category %
This column shows the percentage of apps in the app category that use
permissions in this permission category. [Source: Calculated from ISL
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.