Ngi0 Pet on Guardian Project

New Data Sources: API Key Identifiers and BroadcastReceiver Declarations

Tue, 15 Dec 2020 00:00:00 +0000

A central focus of the Tracking the Trackers project has been to find simple ways to detect whether a given Android APK app file contains code which tracks the user. The ideal scenario is a simple program that can scan the APK and tell a non-technical user whether it contains trackers, but as decades of experience with anti-virus and malware scanners have clearly demonstrated, scanners will always contain a large degree of approximation and guesswork. Tracking the Trackers grew out of experiments in using machine learning to detect malware. This provided the spark to apply this to privacy issues.

The malware research clearly demonstrates that network domain names and code signatures are quite reliable techniques for identifying malware. This also applies to tracking, since the majority of tracking happens via tracking companies’ SDKs which send data to specific domain names. The hard part is that code signatures and domain names are not easy to reliably extract, and are often easy to obfuscate when someone is looking to hide what an app is actually doing. This is common in malware, and we are also starting to see obfuscation in the world of tracking.

Android gives us a break with its AndroidManifest.xml. It is a hard requirement for Android apps so it is always there, it contains some key declarations that set up how the code is run, and it is easy to extract and parse. So we put extra effort in thinking about the data that is contained in the AndroidManifest.xml.

Towards the goal of simple scanners for tracking, we are excited by two new data sources that we found in the AndroidManifest.xml that are useful signals for automatically detecting tracking in Android apps: API Key Identifiers and BroadcastReceiver Declarations.

API Key Identifiers

Tracking services provide their customers with servers to submit the data for processing and analytics. These are usually part of the service’s API. A common pattern for publicly accessible network APIs is to require the use of an API Key. This key grants access to the service and provides an unique identifier for the customer so that the submitted data goes to the right place. In order to submit the key to the API, the key data must be identified to the server somehow. That is the API Key Identifier. This is generally something that never changes, since changing it could mean locking out all customers. For example, Google Firebase Analytics has used ga_trackingId as its API Key Identifier for many years. API Key Identifiers are a great way to track trackers. They are tiny and easy to extract. Most services require them. The entire set that we have found is small enough to fit into a single machine learning search space. And it is quite unlikely that an app would include them by accident or without having set up a tracking service.

We also found some evidence of obfuscated API Key Identifiers, the source has not yet been identified. We found many API Key Identifiers that were not the same but matched a pattern. This pattern looks like it could be encoding some information:

com.APpuz.lHMBA142332.APIKEY
com.BCcyZzWehh.IOfazFfwIH109433.APIKEY
com.CDwo.buYv134822.APIKEY
com.DErSuvPp.bEyhwTQb93737.APIKEY
com.EOoOEpvG.ZuepOuto31966.APIKEY
com.FIKDGlAZIZ.vrlGNzSLEm110206.APIKEY
com.GicPdlXU.iXbdAAkA69030.APIKEY

API Key Identifiers are now included as a data point gathered in Exodus ETIP. If you have some clues about any of this, please let us know.

BroadcastReceiver Declarations

In Android, apps and the system can publicly broadcast events, and any app can listen for these events. Some of these events contain detailed information, like the complete metadata about which song is currently playing. Charging and battery status can be used to re-identify users. These broadcast events are generic Android Intents which an app registers a receiver by name in order to get the info when it is sent. The specific pieces of interest are the BroadcastReceiver IntentFilter Action names.

Like other bits in the AndroidManifest.xml, the BroadcastReceiver Declarations are easy to extract. Unfortunately, BroadcastReceiver Declarations are not nearly has definitive when it comes to marking tracking. They are still worth including, since they are easy to extract, and the whole set of unique, extracted names is small enough to be used as a search space for the machine learning.

The scope of how apps can receive data via BroadcastReceivers was also recently narrowed to a large degree by Google, due to privacy concerns. The upside is that apps cannot receive system-wide broadcasts unless they are already running. The downside is that scanners have to do static code analysis, and perhaps even dynamic analysis, in order to see which BroadcastReceiver IntentFilter Action names an app has declared.

Usage Considerations

The possibility of false positives is still there. For example, if someone makes a “build flavor” that builds without tracker SDKs but forgets to exclude the API Key Identifiers, then a simple scanner will flag this as tracking, even though it could not be. The tracker SDK is not included, which is the code that gathers and uploads the tracking data. In this example, the developer can easily fix it after a scanner flags the app as a tracker, by moving the API key configuration out of the “build flavor”.

A trickier case to review is when an app includes opt-in tracking. We believe that opt-in tracking and data reporting should not be flagged as a tracker, especially when the opt-in user experience makes it clear to the user what data is being gathered, and under what condition it is being sent. In that case, the simple scanner will flag the app, since it contains the API Key Identifier.

This is why we think that machine learning is very promising for tracking apps that track us. There are many good signals, but none of them definitely mark an app as a tracker. They must always be considered as a group with the whole picture, and given well-labeled data, machine learning can do this kind of task quite accurately.

Join the Hunt!

Finding API Key Identifiers is work that can be done in bite-sized pieces, by people in their spare time. Many if not most tracker SDKs require API keys in order to use their service, so start by looking through ETIP for entries that are missing Api_key_ids entries. Usually, this is documented in their SDK developer documentation. There are also many SDKs which set the API Key via a method call rather than a declaration in an XML file. In that case, the API Key Identifier might be found by reading the strings out of the JAR file. We also welcome more information about BroadcastReceiver declarations. We are tracking new data sources and approaches in our issue tracker.

For any kind of mass scanning to be usable, future work should focus on expanding the set of easy to extract features, and finding which of those are useful. Complicated and resource-intensive extractions like domain names, code signatures, and source/sink tracing still hold promise for delivering high accuracy, but would likely remain only useful when scanning individual or small sets of apps.

(This work was supported by NLnet’s NGI Zero PET fund.)

εxodus ETIP: The Canonical Database for Tracking Trackers

Fri, 11 Dec 2020 00:00:00 +0000

There is a new story to add to the list of horrors of Surveillance Capitalism: the United States’ Military is purchasing tracking and location data from companies that track many millions of people. We believe the best solution starts with making people aware of the problem, with tools like Exodus Privacy. Then they must have real options for stepping out of “big tech”, where tracking dominates. F-Droid provides Android apps that are reviewed for tracking and other “anti-features”, and F-Droid is built into mobile platforms like CalyxOS that are free of proprietary, big tech software.

Right now, the most effective method for automatically analyzing Android APK files is to search for well known strings in the extracted contents of the APK. Domain names are one example, like if an app is sending data to google-analytics.com or facebook.com, then it is clear that it is doing some kind of tracking. These lists of well known strings must be created and managed by people, then gathered and reviewed. Exodus Privacy created their Exodus Tracker Investigation Platform (ETIP) for exactly this purpose. Yale Privacy Lab, jawz101, Guardian Project, F-Droid, and others have centralized their efforts on εxodus ETIP as the canonical database for these strings.

Searching the open web for key bits of info

Since tracking is mostly done by companies trying to get customers, they advertise and document their services on the web. We spent some time searching for that information to see what we could find. We mostly searched using two bits of information: the API Key Identifiers that we extracted and “top 10” lists of companies that provide tracking and related services. From this, we added over 50 new service profiles to the εxodus ETIP database. We also added upwards of 100 pieces of additional information to existing entries like SDK identity strings, links to documentation, privacy policies, and information on the company’s tracking methods.

From that research, we saved some choice promises from selected tracking companies:

“Glassbox offers customer experience analytics solutions that doesn’t just tell you what a customer is doing. It tells you why.”
“Target traffic from all sources, including the 50% from the hidden web where third-party cookies are blocked, to increase targetable inventory.”
“Collect customer and product data in real time, from anywhere”
“PlaytestCloud will capture the whole gameplay experience, turning you into a spectator with super powers.”
“We record the players’ screen, their touches and what they have to say at all times.”
“We curate geospatial ground truth data sets on a global scale”
“Take segmentation and analysis from overnight to real-time. Our DMP works in-session for perfect match rates even on passerby traffic.”

Crowdsourcing the hunt for trackers

Tracking the trackers is the kind of work that fits in very well with crowdsourcing. Tracking companies are disappearing and renaming themselves all the time, in order to avoid too much scrutiny. But they still must reach out to developers in order to find customers. That means we can find them. Join in the search! Non-technical people can also contribute, for example, when you read news about a tracking company, search to see if it is already in ETIP. If not, file an issue to request it is added. Android developers with little bits of spare time can add code signatures, domain names, and other key technical details to ETIP. Or even code up quick scripts with new ideas for detecting tracking.

There are a number of forums where you can ask for assistance in getting started. Hope to hear from you soon!

(This work was supported by NLnet’s NGI Zero PET fund.)

On the classification of tracking

Wed, 20 May 2020 00:00:00 +0000

This position paper tries to outline a framework for defining trackers in smart phones and lists mechanisms for identifying them. It hopes to serve as the foundation for the work done in the Tracking-the-Trackers project.

In section 1 we start with an abstract analysis of levels of unwanted behaviour in the context of tracking.

Next, in section 2, we focus on an attacker’s perspective, on anonymity and pseudonymity. This foundation allows us to define terms which are needed throughout the paper.

Finally, we list proposed mechanisms for identifying trackers - based on the threat model (attacker) as well as the level of acceptable tracking.

Scope

This document talks about trackers in general on mobile devices (smartphones). However, for the purpose of verification, we exclusively focus on Android apps. First of all, Android has a 85% global market share, secondly Android apps (APKs) are easier to work on. With iOS apps, monitoring trackers (or instrumenting running code) is not as easy as on Android based systems. Therefore, whenever any claims are made, we refer to the Android ecosystem. We however believe that very similar behaviours exist on iOS based systems.

Also, this document does not talk about contact tracing (as in Covid-19 contact tracing).

Section 1: Levels of unwanted behaviour

The following section tries to categorize tracking respectively potential unwanted behaviour in apps by level of severity. This is done with a perspective for categories (labels) in a machine learning approach.

Level 0: No tracking at all / no network communication

The most harmless situation: an app is downloaded or shared in an anonymous way (Tor, etc.) and only uses offline features and/or uses unlinkable side channels for updates (for example flash cards). An example could be a map application which only displays a map and reads a phone’s GPS position to display the user’s location. There is no network communication at all and it still offers a useful service to its users. Map updates may be installed via flash cards or other physical transportation media. The app does not need to request a new map interactively from any server.

Level 1: Inadvertent tracking

This category includes tracking but the service provider and the app never intended to actually use the resulting data / meta-data for the purpose of tracking individuals.

Example: to illustrate this category, recall our map app from above. Only this time, it does request map (base layer) updates from a map server every 7 days. It also checks every day, if the map viewer app is the latest version. Based on this information, an attack could theoretically derive weekly IP address “beacons” from some user. Since the update check was not personalized, an attack can not be for sure, if an update request is from the same person or not. Hence, a user still has potentially enough anonymity.

This and the next category probably (to be verified) constitute the majority of “clean” apps.

Level 2: Unintentional tracking by use of chatty libraries

This category tracks users already quite heavily. The motive is not to increase ad revenue, build up user profiles to sell them nor to pass on the data to an aggregator. The unintentional tracking stems more from the fact that the app developer(s) used libraries which help them in developing the app and/or which are simply useful for the overall user experience.

Example: if we revisit our map example, we could imagine that the map app now also includes a search functionality. Users can type in the initial letters of a street name and for every letter they type, an AJAX HTTP request is sent to the map server. In addition, the developers felt that it would be useful to receive APM (application performance monitoring) logs as well as crash reports as well as a set of libraries to measure which features of an app the users actually use the most. These logs are sent periodically to some log collection server run by the developers.

Note that we still do not talk about (Google, Facebook etc) cookies here. We only talk about watching what users are typing (including backspace and corrections - an attacker can literally watch their thoughts via the global click-stream).

Level 3: Ad-revenue focused tracking of users and/or user behaviour (pseudonymized)

With this category, we are entering the area often described as surveillance capitalism: users are receiving cookies (if it’s a web based app) and or have unique IDs embedded in the app and these unique identifies (which are not tied to a person in the first place and hence are a ‘nym of the user) are being sent for nearly every network interaction. These IDs may (but not necessarily have to ) serve as authentication / authorization token ( see OAUTH 1,2, OpenID Connect) or may be purely auto-generated and simply serve for tracking actions users takes over the course of his day (so that the interest of a user may be extracted). These tracking IDs may then be forwarded and sold to aggregators.

While this may be acceptable to some users, since the techniques use pseudonymization, there is an implicit trap hidden in this approach: unique IDs are usually long enough so that they are unique globally (for example UUID strings). Thus, they can easily be correlated with real PII data and the pseudonymization vanishes instantly.

Level 4: Ad-revenue focused tracking of users and/or user behaviour (linked to person)

This category fits most non-open source commercial apps such as FB messenger, twitter, etc. (but it can occur as well in open source apps). The business model is to fully understand a user, his/her interests, his/her behaviour, location (-> location tracking), and very important - his/her circle of friends (contacts), etc. The “gold” in the app gold rush is a users’ interest and intent. In order to serve him/her adds better and faster (in the sub-millisecond range). Again, as in the previous category, these tracking IDs may then be forwarded and sold to aggregators.

We assume the vast majority of apps fall into this category.

Level 5: Full scale stealthy tracking (surveilling the spouse, kids, state actors, APT attacks, general surveillance, etc.)

This category would fit any technique which tries to secretly monitor as many actions on the whole smartphone (or potentially also via the smart phone on computers) of a person.

Example: kids tracking apps. Or hidden apps which check what your husband/wife is doing on his/her phone (and forwarding call logs , messages, etc.). State actors tracking dissidents, journalists or any chosen target also would use these techniques.

Often these apps can be identified by their extended permissions but not necessarily so. Well written apps in this category may be impossible to detect without major reverse engineering efforts.

Conclusions

Our work in the Tracking the Trackers project limits itself to Levels 3 and 4. We intentionally omit level 5, since this is a cat-and-mouse game with the attackers. It is rather trivial to change some behaviour for an attacker while our detection mechanism remains open source.

Section 2: an attacker’s perspective and a taxonomy

“There is nothing as practical as a good theory” – Kurt Lewin

This section builds upon the work of Pfitzmann and Hansen¹ who did (to the author’s knowledge) the first thorough comparison of terminology in literature with respect to the concepts of anonymity, linkability, pseudonymity, etc. We believe that their work is a good framework for thought. It also hints at some connections to Shannon’s information theory and probability. However, the paper does not follow through on the maths.

The core insight of their work is that - if you include metadata of communication flows over the internet, and if you assume an attacker which can observe the whole network (passively)², then true anonymity is nearly impossible to achieve for any regular app or program.

In this paper, we first briefly describe Pfitzmann’s and Hansens’ model and especially their attacker’s model / threat model. We then replicate their definitions and add some definitions of our own. The next step is to link their definitions to our categories of tracking.

Equipped with these theoretical tools, we can proceed to define what we consider tracking in Android apps and derive feature sets for an ML based approach.

The Pfitzmann-Hansen threat model

The threat model assumes a classical sender-receiver (source/sink) information model where the communication network is usually the internet. They assume an attacker to be yet another (possibly all-knowing) passive receiver. If messages pass the communication network, attributes (i.e. meta-data³ such as time + time zone when a message was sent, received, the packet size, the protocols used etc) may be derived by a receiver. These attributes may become another new message.

If we apply Pfitzmann’s and Hansens’ model to our levels, we arrive at the following insights:

Level 0: the app is quiet → no harm, an all-knowing attacker can see the download of a level 0 app in the very best of cases.
Level 1: the passive attack may derive IP addresses (and hence some ideas of a user’s location) and time stamps of when the app was in use. → the passive attacker can already track the user to some extent iff (if and only if) he also has access to the telecom’s IP address assignment database for that particular time window. This is usually only possible for nation state attackers. → out of scope.
Level 2: In this scenario, it already depends a lot if the app is sending APMs, crash reports, or other “chatty library” messages. If unencrypted, a passive attacker may - already in this category gain a lot of information on the user. → we propose to include detection of APMs/crash reporting libraries in future versions of the tracking the trackers project.
Level 3: While it is nice to notice that the developers tried to pseudonymise tracking in this category, it does not help the user very much. As long as a passive attacker may detect the pseudonymized IDs in messages flowing to a central server, he wins. He can track the user. Countermeasure: a guaranteed rotation of these unique IDs/tokens every x seconds (at fixed intervals). → we propose to look at this level of tracking in our research in order to identify unique tokens/API keys, unique IDs in apps which are easily detectable in order to guide the F-Droid store developer on how to avoid common pitfalls associated with fixed IDs/API keys etc.
Level 4: for an attacker, this is the gold mine. Here, nearly every action may be passively observed. This is the case, we assume to be the most prevalent one in most apps (proof: just take a random app and look at the tcpdump stream of data it sends every second). We will aim to detect the most common tracking libraries.
Level 5: here the attacker basically gains an upgrade from a passive attacker to an active attacker should he wish so. Game over for the user → out of scope for our research.

Summary

We identified a rough categorization of 5 levels of tracking. We reasoned what information an attacker may gain at each level and we defined the scope of our research.

(This work was supported by NLnet’s NGI Zero PET fund.)

“Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management – A Consolidated Proposal for Terminology”, 2008, Andreas Pfitzmann (TU Dresden), Marit Hansen (ULD Kiel). http://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.31.pdf ^[return]
An assumption which is not far fetched - see the Snowden papers. ^[return]
Compare with the quote “we kill people based on metadata” by the former CIA/NSA director Hayden. https://abcnews.go.com/blogs/headlines/2014/05/ex-nsa-chief-we-kill-people-based-on-metadata ^[return]

Free Software Tooling for Android Feature Extraction

Wed, 06 May 2020 00:00:00 +0000

As part of the Tracking the Trackers project, we are inspecting thousands of Android apps to see what kinds of tracking we can find. We are looking at both the binary APK files as well as the source code. Source code is of course easy to inspect, since it is already a form that is meant to be read and reviewed by people. Android APK binaries are a very different story. They are first and foremost a machine-executable format. On top of that, many developers deliberately obfuscate as much as possible in the APK to resist inspection.

That means inspection requires using tools to look into the binary APK format. There is actually a massive amount of work that goes into inspecting APKs because this is required in order to do useful malware analysis. For the most part, these inspection techniques are the malware companies’ “special sauce”, so they are proprietary and generally kept secret. On top of that, malware companies keep secret a lot of the conclusions they about what is useful data to collect, and what should be ignored.

One key piece of the Tracking the Trackers project is to make all of research, tooling, and conclusions free, open, and publicly available. First and foremost, that means the tools must be free software. They should also be easily installable so the barrier to entry for new inspectors is as low as possible. We focus on getting software as part of Debian, since once there, so many people have access to those packages since Ubuntu, Kali, and so many other GNU/Linux distros are based on Debian.

What is available in Debian already

Our work with the Debian Android Tools Team and Debian Java Team over the years means many key tools are already included in Debian and its derivatives, including:

key Android SDK components like apksigner, dx and android.jar
apktool
dexdump/dexlist
enjarify
LibScout
libsmali
procyon

Tools we are using

One key aspect of our research is that working with terabytes of APKs, this is necessary to be able to spot and map out as many trackers as possible. Since feature extraction can be a slow and resource intensive process, we needed to use some tools that emphasize speed over flexibility. Even with fast extraction tools, we still have to build up tailored processes to speed things up. Some of these straightforward feature extraction processes would take months to run on ~3TB of APKs on a 32-thread machine with 144GB of RAM.

LibScout - detect SDKs/libraries with their version in binary APKs
https://github.com/avast/apkparser - faster manifest/resources parser
https://github.com/avast/apkverifier - faster APK signature verifier
https://github.com/jedisct1/ipgrep - ipgrep extracts possibly obfuscated host names and IP addresses from text, resolves host names, and prints them, sorted by ASN.
https://github.com/stricaud/faup - Fast URL decoder library
https://github.com/cryptax/droidlysis - Quickly analyze APKs for the most essential features: permissions, Activity and BroadcastReceiver names, and key method calls.

apkverifier, apkparser, and droidlysis are generally useful, but not yet in Debian. So we packaged them to make them easily available. They are currently in the Debian NEW queue, awaiting final review before inclusion.

These tools have been assembled into scripts to run the actual feature extract processes, they are maintained in the https://gitlab.com/trackingthetrackers/extracted-features repo. When the actual data generated is small enough and there are not copyright conflicts, the data is also included there. Mostly, the data sets are too large and sometimes touch on copyright restrictions, so they are unfortunately not publicly available.

There are lots of other tasks, including managing large APK collections, gathering data to generate statistics about the features, and downloading publicly available tracker SDK. Those scripts are maintained in https://gitlab.com/trackingthetrackers/scripts.

Gradle Plugins

When working with source code, then it is possible to do other kinds of analysis. Most Android apps are built with the Gradle tool. So we reviewed a wide range of Gradle plugins, and found these three useful in our investigations.

dependency-analysis-android-gradle-plugin - Produce a report of unused direct dependencies and used transitive dependencies.
OWASP Dependency-Check - utility that detects publicly disclosed vulnerabilities in application dependencies
gradle-dependency-graph-generator-plugin - Gradle plugin that lets you visualize your Java library dependencies in a graph.

Tools we reviewed

We looked at quite a few existing tools, and found many interesting and useful ones. While they all produced useful output, many of these were not useful to this project because they were tailored around the use case of a person inspecting a small set of apps, so for example, they were too slow or did not produce machine readable output suitable for working with large APK collections.

android_permissions_harvester - for finding which permissions are used based on method calls
droidlysis - cryptax’s (aXelle’s) tool: “DroidLysis is a property extractor for Android apps”. See also her talk at hacklu 2019
APKiD - “In addition to detecting packers, obfuscators, and other weird stuff, it can also identify if an app was compiled by the standard Android compilers or dexlib”[1]
redex - “taking advantage of Redex allows us to normalise the applications prior to analysis”[1]
kaitai_struct_formats - generic binary struct parser tool, useful for directly parsing Android classes.dex files.
binaryanalysis-ng - a framework for unpacking files recursively and running checks on the unpacked files. Great for someone who needs to inspect small sets of a wide variety of file types.
redexer - infer with which parameters the app uses certain permissions (we name this feature RefineDroid)
apk-static-xref - staticallly generate a cross-reference-graph (XRG) of a component (e.g., Service) of Android APK file
smalisca - Static Code analysis tool that generates call graphs

(This work was supported by NLnet’s NGI Zero PET fund.)

"Features" for Finding Trackers

Tue, 28 Apr 2020 00:00:00 +0000

One key component of the Tracking the Trackers project is building a machine learning (ML) tool to aide humans to find tracking in Android apps. One of the most important pieces of developing a machine learning tool is figuring out which “features” should be fed to the machine learning algorithms. In this context, features are constrained data sets derived from the whole data set. In our case, the whole data set is terabytes of APKs. This post is an outline of the features that we are focusing on in this current project.

Confirmed Features

These are features that we will definitely used, and already have good tooling to do the feature extraction.

Permissions

Android apps must request permissions from the Android OS to access sensitive user data as well as certain system features. This can naturally give big hints towards tracking attempts. Basically an app which does not request any permissions will have a much harder time of tracking its users, while an app aimed towards tracking will require a myriad of permissions depending on the properties it desires to track (e.g. location, contacts, phone IDs, Bluetooth IDs, WiFi IDs, camera/microphone-access, call-logs and many more)

Tracking Libraries and SDKs

Code re-use plays a big role in any software project, why write your own tracking functionality when someone else has already implemented a whole library geared towards tracking users. This functionality is provided by different SDKs, which are pre-configured bundles of functionality which in turn (for this use case) are provided by tracking companies. The app developer often has to choose the desired functionality. While importing a tracking library is no guarantee for tracking activities it is certainly a red flag. We compare the libraries imported by the app with a list of known tracking libraries.

Domain Names

Developers leave URLs in form of strings in the code to allow exchange of information with the world outside of the app. This can be used to transfer information about the user which in turn can be used for tracking. The domains often contain a hint about the purpose behind the data transfer (e.g. https://www.google-analytics.com). Domain names are data sinks for collecting data, which gives us a clear point to focus on analyzing since collecting tracking data does not matter if it never leaves the local device, while domain names are the point in the code where data leaves the device and is sent to be collected and analyzed on a remote server. Combined with other features like permissions and seeing tracking libraries being imported a human reviewer could get a pretty good idea of what type of information could be sent. This human “gut feeling” of recognizing fishy combinations of features is something a neural network can often learn to approximate by being trained on a sufficient amount of training data. Domain names known to be relevant to tracking are collected and maintaned by Exodus Privacy.

New Experimental Features

These are features that show a lot of promise, but there is not existing tooling to easily work with them. We are working to make it easier, and will cover that work in future posts.

API Key ID

The API Key ID is a string that identifies bit of authentication data for enabling access to an online service. Many online services require an API Key even if a library or SDK is not required to access it. Even when the SDK is detected, the presence of an API Key shows that the tracking function is actually enabled. For example, the Google Firebase SDK includes lots of functionality, not only tracking, each of which must be enabled with an API Key. So the presence of Firebase is not enough to confirm tracking. A current example of exactly this is the Austrian Red Cross’ Stopp Corona app to track the spread of covid-19 in Austria.

Natural Language Processing (NLP)

As mentioned under the section on domain names, domain names can already give a clear hint at intent. However since this property is well known, URLs might be obfuscated to hide this information. This domain name obfuscation is a well known technique in the world of malware, there is some evidence of use by tracking companies. In this case, a language model might learn that any URL that looks like random letters and numbers might be a sign to consider increasing the probability of classifying this app as tracking slightly, depending on other features like requested permissions, and imported tracking libraries.

Broadcast Receivers

Android provides a system for data to be broadcast to all apps on a device, this is known as a Broadcast Receiver. A wide range of data is available via this mechanism, both from the Android system as well as apps. The Android OS broadcasts detailed information about the battery level, health, and charging status, including details of how its charging. Many music apps will broadcast detailed information about the song being played, while also collecting those events from the system and other apps. The full extent of this activity is not well described, both what data is broadcasted, what apps are doing with it, and which apps are collecting. As a feature, Broadcast Receivers have a lot of promise since they fit the patterns of useful features for machine learning: small, globally unique, and easy to extract.

Feature Extraction Process

We are using tabular data to feed to the machine learning processes, so the process of extracting and pre-processing different features for classification includes similar steps for every feature. The number of features that can reasonably be processed this way is limited to probably tens of thousands of features, or perhaps even hundreds of thousands. Therefore we have collections of the top-n features where n is in the range of thousands: For example, the top thousand tracking libraries, or all built-in permissions. This way we extract the features out of the binary APK file, and source code when available, and loop over our collections of known features. If the feature was found in the APK/source the tabular data will be a 1, else a 0.

(This work was supported by NLnet’s NGI Zero PET fund.)

Tracking the Trackers: using machine learning to aid ethical decisions

Thu, 16 Jan 2020 00:00:00 +0000

F-Droid is a free software community app store that has been working since 2010 to make all forms of tracking and advertising visible to users. It has become the trusted name for privacy in Android, and app developers who sell based on privacy make the extra effort to get their apps included in the F-Droid.org collection. These include Nextcloud, Tor Browser, TAZ.de, and Tutanota. Auditing apps for tracking is labor intensive and error prone, yet ever more in demand. F-Droid already has tools to aide contributors in this process, visible in the app submission and Request For Packaging (RFP) issue trackers. We also have functional prototypes of using machine learning to drastically speed up this process by augmenting humans, rather than replacing them.

Since the prime motivation of the F-Droid community is ethical software distribution, algorithms will never replace humans in making ethical decisions. We have also explored using machine learning to detect tracking in a more generic way, without manually compiled lists of tracking libraries. With this funding, we will improve the F-Droid tools, and make them generally available for any use case needing to reliably detect trackers in Android apps. This builds upon our collaboration with Exodus Privacy and LibScout.

This project comes out of some proof of concept work that Aaron Kaplan and Hans-Christoph Steiner did, working with students in the Vienna Economics University’s (WU) Data Science Lab. We focused on using machine learning with Android apps, first to detect malware, then second to detect tracking libraries. It is of course ultimately an outgrowth of the F-Droid community’s efforts, and Guardian Project’s funded efforts for building systems without any tracking at all. And special thanks to F-Droid founder Ciaran Gultnieks for setting the ethical tone that inspired us all, back in 2010.

Funding

This current 44,500€ project is funded by NLnet’s Privacy & Trust Enhancing Technologies (PET) Fund. F-Droid has received large, dedicated, computing resources from the GCC Compile Farm, as well as some shared resources from Aaron Kaplan. The budget will be used entirely to pay for people’s time for the research, development, and integration work:

Software development to get the existing LibScout and Exodus Privacy tools to be fully integrated into the F-Droid stack.
Machine learning research and development.
Community management, to coordinate with F-Droid contributors, app developers, tool developers, academic researchers, etc. as well to promote these tools
Finalize and package up all the useful parts of this project, which also means getting them included in Debian

The general approach that we are taking here has been proven in the context of web pages. The Brave Browser includes machine learning techniques for blocking ads and trackers in webpages. It is a very similar idea to what we propose, but that example is embedded into a browser and only applies to web sites.

Exodus Privacy has manually compiled an extensive list of tracking libraries and domains for receiving user data. It then uses this to scan app from Google Play. Those results are then reported on their website. Exodus Privacy would directly benefit from this work, since they could use the tools we will create.

Ghostery uses AI techniques to dynamically block ads in web pages. (https://www.wired.com/story/ghostery-deploys-ai-in-fight-against-ad-trackers/)

F-Droid has its own fdroid scanner for doing checks based on manually prepared regular expressions. This was combined with Exodus Privacy into F-Droid’s issuebot which automatically scans apps that users request to be added to F-Droid.

LibScout uses machine learning to detect which versions of which libraries are included in an Android app (APK). Using the list of libraries from Exodus Privacy, we worked with the LibScout author to create a functional prototype of a tracking library detector.

Drebin clearly demonstrated that machine learning can be used to automatically classify Android apps based on certain aspects of their behavior. Their aim was to find malware. Working with CERT.at and the WU Data Science Lab, we reproduced the results of the Drebin paper.

The challenges

The biggest promise of this project is also the biggest technical challenge: finding a way to take datasets about what includes tracking libraries (e.g. F-Droid manual review, LibScout, Exodus Privacy), and turning that into a more general machine learning approach. We will have to explore a wide range of possible features to include in the machine learning that are distinct from the tracking libraries themselves. This general approach will provide tracking detection with more automation and less maintenance work of rerunning the machine learning on updated datasets as new tracking libraries are put into use.

The technical methods for determining whether an app includes trackers are well known and described. They currently require knowledge of Android development. Machine learning has been proven to be able to reliably spot trackers in apps, this project will turn working prototypes into production software, integrate it into F-Droid community-driven processes, and make these new tools easily available for anyone else to apply to their specific use cases. Given an Android apps downloaded from anywhere, these new tools will be able to mark which ones have any kind of tracking in them, with a very high degree of certainty. With the portion of the project that involves applying LibScout, at this point, the idea has been proven with prototypes. Applying it is a straightforward matter of bringing a proven prototype to production.

Organizations relying on proprietary apps that must follow strict data protection requirements, like banks under the GDPR, can use these tools to ensure that apps they rely on do not contain illegal tracking, and to ensure that such tracking is not added in future releases.

These techniques are also applicable to other platforms, like Progressive Web Apps and Apple iOS. Bootstrapping another platform would require a marked training set of apps to feed to the machine learning. F-Droid already provides this set, and Android is the most popular OS in the world, making Android the ideal platform to start this work.

Humans at the core

F-Droid is a community run free software project very much in the same spirit as Debian. The community has always aimed to provide 100% verified free software, built from source. From the beginning, there was also an interest in other ethical considerations as well, these are expressed via F-Droid’s “Anti-Features”. These are things tagged with Tracking (contains tracking), Ads (includes advertising), and NonFreeNet (requires a non-free network service). The process of ensuring that the apps are 100% free software as well as tagging apps with the required Anti-Features is a manual process that many people contribute to, that is aided by quite a bit of automation. This project fits directly into this existing ecosystem. It will both quickly provide improvements in contributors’ workflow based on the existing prototype, as well as experiments towards drastically improving the whole workflow of anyone working to track trackers.

F-Droid fits into the whole Android app ecosytem in a very specific role. It is the one source that only distributes free software, and has built a well deserved reputation for not compromising on the ethics that guide the community. This has led it to become the standard “clean set” in all manner of research into Android malware and tracking. Many academic papers covering Android malware cite f-droid.org as the source of ground truth.

In closing, it is important to highlight that it is essential to keep humans always at the center of of these tools. We are building tooling to augment humans, not replace them. Since the prime motivation of the F-Droid community is to build ethical software distribution, algorithms will never replace humans in making decisions based on ethics. The tools can automate the technical details, so that contributors do not need to understand them in order to meaningfully help with the process.

Ngi0 Pet on Guardian Project

New Data Sources: API Key Identifiers and BroadcastReceiver Declarations

API Key Identifiers

BroadcastReceiver Declarations

Usage Considerations

Join the Hunt!

εxodus ETIP: The Canonical Database for Tracking Trackers

Searching the open web for key bits of info

Crowdsourcing the hunt for trackers

On the classification of tracking

Scope

Section 1: Levels of unwanted behaviour

Level 0: No tracking at all / no network communication

Level 1: Inadvertent tracking

Level 2: Unintentional tracking by use of chatty libraries

Level 3: Ad-revenue focused tracking of users and/or user behaviour (pseudonymized)

Level 4: Ad-revenue focused tracking of users and/or user behaviour (linked to person)

Level 5: Full scale stealthy tracking (surveilling the spouse, kids, state actors, APT attacks, general surveillance, etc.)

Conclusions

Section 2: an attacker’s perspective and a taxonomy

The Pfitzmann-Hansen threat model

Summary

Free Software Tooling for Android Feature Extraction

What is available in Debian already

Tools we are using

Gradle Plugins

Tools we reviewed

"Features" for Finding Trackers

Confirmed Features

Permissions

Tracking Libraries and SDKs

Domain Names

New Experimental Features

API Key ID

Natural Language Processing (NLP)

Broadcast Receivers

Feature Extraction Process

Tracking the Trackers: using machine learning to aid ethical decisions

Funding

Related Efforts

The challenges

Humans at the core