Apps for opioid addiction treatment and recovery

We focus on data access and permissions, visualizing app activity via source code analysis. This report relies upon insights gleaned from static analysis, using a process similar to the one we outlined in Investigation Xoth. Building upon the techniques we used previously to analyze app source code, we generate “call graphs” that illustrate how information flows through each app. The software that was developed to generate these call graphs, as well as source code snippets corresponding to these visualizations, has now been released by Defensive Lab Agency under a free and open-source license.

Call graphs represent relationships between subroutines in a computer program and give a view into the data that components of an app can access and modify. In this example, software developed by Zoom that is present in a telehealth app accesses the list of installed packages on a smartphone:

Smartphone sensors are a battleground for personal privacy, offering a vast array of information for exploitation by malicious hackers and data brokers alike. Conversations about smartphone privacy include a steadily increasing array of sensors such as accelerometers, ambient light sensors, and LiDAR. Where privacy and security are concerned, however, five attack vectors stand out: GPS, Bluetooth, cell radio, camera, and microphone.

GPS, Bluetooth, and cell radio are commonly used for location tracking and Bluetooth, in particular, is on the rise as a channel for exfiltration of private user data. As products such as Apple’s AirTags are introduced, the physical world around our smartphones is becoming filled with Bluetooth sensors, including “beacons” which can determine movement and proximity of users to a finer degree than more coarse location methods such as cell radio triangulation.

Many of the apps we studied gather location information in some form, relying upon a mix of GPS, mobile network/cell radio, and Bluetooth technology. This location information, especially when correlated with unique identifiers, strengthens the capability for tracking an individual person who is carrying the smartphone, their daily habits and behaviors, and even pinpointing their friends and family.

• 7 out of 10 apps request permission to make Bluetooth connections (Bicycle Health, Boulder Care, Confidant Health, DynamiCare Health, Kaden Health, Loosid, PursueCare).

• 7 out of 10 apps access location data, if available (Boulder Care, Confidant Health, DynamiCare Health, Kaden Health, Loosid, Sober Grid, Workit Health). Three apps request permission to determine coarse and fine location based upon GPS and/or mobile network information (DynamiCare Health, Loosid, Sober Grid).
  

Usage of smartphone camera and microphone is notable, with nine out of ten apps requesting permission to access this hardware, but this is not surprising given their core functionality. Telehealth apps utilize the camera and microphone for treatment and other calls with the service provider. However, the potential for abuse of these permissions in smartphone apps is well-known. Unwanted access to this hardware can have dire consequences for privacy, and is a consistent worry for consumers. Additionally, core calling, calendaring, and address book functionality is available to many of these apps.

• 6 out of 10 apps request permission to determine calling information including whether a call is active, the number that call is connected to (Bicycle Health, Boulder Care, Confidant Health, Loosid, PursueCare, Sober Grid).

• 2 apps request permission to initiate phone calls (Bicycle Health, Sober Grid).

• 2 apps request permission to read and/or modify contacts in the address book (Loosid, Sober Grid).

• 3 apps request permission to read and/or modify calendar items (Confidant Health, Kaden Health, Loosid).

Though we have not observed unwanted or unauthorized access via this functionality, consumers would do well to limit permissions in these apps that relate to camera and microphone, calls, calendar, and address book unless they are actively using features that require them.

Third-party sharing

The modern-day app economy relies upon extraction of detailed user information to boost revenue and perceived value. Developers who utilize tracker Software Development Kits (SDKs) often have a stake in data collection from smartphone users. SDKs execute code and communicate over the internet in ways that may compromise user information.

In Investigation Xoth, ExpressVPN Digital Security Lab revealed the relationships between a cluster of tracker SDKs that relied specifically upon location data. In our current study, we have also discovered a high prevalence of tracker SDKs, though their approaches to data collection and processing vary.

In some cases, SDKs are designed specifically to collect and aggregate data about the behavior, location, or identities of smartphone users. In other cases, such surveillance is a valuable byproduct of the SDK’s core functionality — an app that provides navigation to a recovery center, for example, may also be tracking a user’s movements throughout the day and sending that data back to the app’s developers and third parties.

App developers have decided to include tracker SDKs in apps for a variety of reasons, and we do not categorize all usage of trackers as malicious or condemn the app authors. Additionally, given the complexity and pace of software development, some developers may not be aware that trackers are in their app or may not know the full implications of bundling such code before publishing.

The existence of tracker SDKs can reveal potential data-sharing activity. For example, this call graph generated by studying the Confidant Health app reveals that OneSignal SDK has access to the Android Advertising ID (AAID):

To supplement analysis of tracker SDKs, it is useful to study an app’s network endpoints. This can reveal the parties engaging in data collection, as well as give insight into its purpose. In the telehealth apps we studied, we found dozens of network endpoints for third parties. Though some of these are linked to SDKs and third-party services that provide app functionality, such as Stripe payment processing, others are clearly linked to ad tech and “attribution” companies. In some cases, even where core app functionality is concerned, data access also seems to be far wider than necessary. In the Kaden Health app, for example, Stripe can read the list of installed apps, location, AAID, IP address, IMEI, IMSI, SIM serial, phone number, and carrier name.