Exodus Privacy: The Tracker-Checker

Trackers found in an app;
© Exodus Privacy (CC-BY)

Trackers are meanwhile part of more than two thirds of all Android apps. Even in paid ones. Its not rare that you find 10 or more trackers in a single app; I even found apps with more than 20 trackers included – and the „Tracker Checker“ Exodus Privacy also lists a bunch with over thirty of these fiends.

But what are „Trackers”? They are third party modules integrated into apps to track the user and „call home“ with their findings. These modules have access to everything the app itself has access to – as by inclusion, they became part of it. And thus sometimes your entire addressbook or logins (including passwords) end up on servers of those third parties.

Google Play Store doesnt tell you if (or even what) trackers are shipped with an app – transparency is missing there. For many apps, Appbrain lists the libraries they use. But unfortunately not for all apps, as Appbrain depends on the support of its users: required data is collected on their devices if theyve installed the Appbrain Ad Detector.

At Exodus Privacy you can report any free app for analysis – without the need to have it installed on your device first. Provided it is available for free at Google Play Store: thats where Exodus downloads the APK file from, analyses it, and provides the results.

What OSes is Exodus available for?

Exodus itself can be used via your web browser. It can analyse Android apps only: analysis of iOS apps is not possible; as the FAQ points out, Apple’s DRM strictly forbids it. Technically it would be possible – but unfortunately illegal (with „research” being the only exception). The Exodus-Team points out, though, that most iOS apps use the same tracking libraries as their Android pendants. So if theres such an Android pendant to the iOS app you’re interested in, just have that checked..

What languages is the service offered in?

At the time of this writing, the website is available in French and English only. Exodus would really like to offer support for more languages (especially German and Spanish). But the entire team consists of (mostly French) volunteers. None of those volunteers is familiar enough with German or Spanish to translate the projects (website, videos etc) into those languages. So they gladly welcome other volunteers who could fill that gap. Please check the website for how to get into contact.

Who’s behind it?

Exodus Privacy is a French non-profit organization. It is managed by hacktivists – with the goal to protect privacy wherever possible. On its website the team lists its members in the „Who“ section – and also offers possibilities to get in touch with them.

A team member told me¹ on the origins of Exodus Privacy:

In the late summer 2017, a French online paper talked about the discovery of a particular tracker in more than 50 popular French applications (for a total of 10 million French users). Several people started to ask themselves „What about other applications?” A small group was formed on Twitter and we developed the first working platform within a few days. Then we created a French non-profit organization in order to make the project sustainable.

Our goal is to make people (including non-tech people) aware of the tracking done by the applications on their smartphones. That’s why we developped analysing tools and pedagogic content, such as our videos. We are now working on several projects, including improving the UX of the platform, to make our analysing reports more understandable for everyone.

How does Exodus work – technically?

Exodus Privacy only performs statical analysis – i.e. it scans which libraries are included with the code of an app. So results don’t tell whether certain code indeed is executed, partly or at all – just that its code is present. How this scan works is explained in detail on their website – so please read it there if you’re interested. As a very short extract, the process takes advfantage of the fact that class names can be found inside the APK of an app and extracted using dexdump, a utility provided by Google. Results are then cross-checked with a list of signatures from trackers known to Exodus, using regular expressions to match them.

One short example, taken from the linked document: to check for the presence of Flurry’s library, the signature/regular-expression com.flurry. is used. So lets see whether my.apk contains Flurry’s classes:

$ dexdump my.apk | grep "Class descriptor" | sort | uniq | grep -E "com.flurry." | head -n 10
  Class descriptor  : ’Lcom/flurry/android/Constants;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent$Builder;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgentListener;’
  Class descriptor  : ’Lcom/flurry/android/FlurryEventRecordStatus;’
  Class descriptor  : ’Lcom/flurry/android/FlurryGamingAgent;’

Überblick über den statischen Analyse-Prozess
© Exodus Privacy (CC-BY-SA)

So yes: my.apk contains classes of Flurry’s library.

If you submit an app to εxodus for analysis, εxodus downloads it from Google Play Store, extracts the .apk file, runs dexdump against it, saves the filtered output to a file (which is used with updates to the report to speed up analysis), takes the signature of each tracker known to εxodus and checks whether matching classes are found. If there’s one or more hits this is interpreted as the tracker’s presence – no hit as its absence.

Currently (Juni 2019), εxodus has signatures for 196 trackers.

What are the weaknesses of this procedure, and how can the gaps be filled by other means?

As stated above, static analysis can only report the existence (or absence) of code – but cannot tell whether the relevant code is active (i.e. executed at any time) or not. Currently, in France only researchers are allowed to decompile applications (and thus to figure out which part of the code is active and which is not). This is not a weak point of Exodus, but rather of the law. On the day the laws permit decompiling and checking for activity of code fragments, Exodus intends to do so. The biggest weakness is that each tracker signature must be identified and recorded manually, based on the help of the community.

But as a user, you can e.g. check the network activity of an app – e.g. using Net Monitor – though it might not always be easy to tell which tracker might be responsible for a given network request. You can also use ClassyShark3xodus to scan apps directly on your device, regardless of where you installed it from.

Other than Exodus Privacy, e.g. AppCensus performs a dynamical analysis: Apps are executed inside a runtime environment, and network traffic is checked for transmission of sensitive data like PII and identifiers. A short (German) description can be found in the blog of security expert Mike Kuketz. But with the most recent analysis dating August 2018 it is rather unlikely this service is still active. And unlike with Exodus, end users cannot report apps for scanning but only search in existing results.

Examples of prominent trackers

A list of the most tracker-ridden apps can of course be found at Exodus Privacy. And did I speak of having seen apps with more than twenty trackers, there you can even find twice as much per app – for even 6 apps in a row²!

Also available at Exodus Privacy: Statistics with most frequent trackers.

There are multiple categories of trackers. What they all have in common is their collecting and sending data without asking the users’ consent (with few exceptions):

Crash reporter automatically send crash reports whenever an app terminates abnormally (crashes). Data transfered in such cases very much depends on the library used; compared to trackers of the other categories, they are usually quite „harmless”. Into this category e.g. belong Bugsee and Bugsnag, which send their reports without asking the user. That other approaches are indeed possible is proven by e.g. ACRA and Bugclipper, which work rather privacy-oriented: if and what is sent, is decided by the user.
Analytics Modules monitor user behavior – and send (often quite detailed) reports, again usually without the user’s consent, to their master’s (third-party) servers. This becomes especially critical if those third-parties are networks already known for creating extensive user profiles – like Google or Facebook. And who would have guessed the most widespread candidates in this segment include Google Crashlytics, Google Firebase Analytics and Facebook Analytics? What a surprise.
Ad modules shall provide the user with (often „personalized“) advertizements. This might sound harmless – but often is not: these ad modules have, like all other components of the app, access to everything the app itself can access – as explain in detail in my article What’s it all about those modules apps contain. And to „personalize” your ads they make use of your personal data quite extensively, see Beware those snooping mods. Best known candidates in this category are Google Ads, Google DoubleClick, AdMob and Facebook Ads – but also Twitter’s MoPub. Surprise: again the „profiling companies“.
Social Networks are often used to „Share“ content with friends – though users who want to do so usually have the corresponding apps installed on their devices and can use Android’s built-in share functionality for that. Especially mean in this context: even if you are not active in such a network (and not even have an account there), thanks to these modules your (partly quite sensitive) data end up there. Most frequently found are Facebook modules. No profile there? I doubt that. Just watch out for the term „shadow profile“.

Developers are often found unaware of this issue; but too often they are simply closing their eyes and don’t want to know. Especially for analytics and crash reporting the argument often is those services are so convenient and offer additional/more granular details. Tell them, listen to their answers, and draw your own conclusions – after all, it’s your privacy (not theirs) which is at stake.

Is IzzyOnDroid affiliated with Exodus?

In a way, yes: the app listings are making use of Exodus’ services. Whenever an app is (added or) updated, the „app list updater“ asks Exodus for its results on the new version – if there is none, it even submits the new version for Exodus to scan. Results are then stored to the database, and used for the lists: you see a Contains no known trackers o/ if Exodus reported an app „tracker free“ – or a (number of) if the app contains especially intrusive trackers. So at this place my personal thanks to the Exodus team!

IzzyOnDroid