Every February, it’s that time of year again: florists, jewelers and exquisite restaurants rub their hands together. On the evening of the 14th, desperate men scramble for the withering remains of the last gas station flower bouquets and the leftover boxes of chocolates from the back rows. And those who do not have these problems are at least constantly and steadily reminded that they should. It is Valentine’s Day.
Not only on this special day, but of course especially in the run-up to it, dating apps enjoy great popularity and hardly any other app category can boast such gigantic download and user numbers. We take this year’s Valentine’s Day as an opportunity to subject the biggest and most popular Android apps from this category to our Android App Privacy test to answer the question of how serious privacy is taken in dating apps. A small anti-climax right at the beginning: The result should not really surprise anybody.
App selection
When selecting the apps to look at, we simply picked the most widespread apps according to their download numbers in the Google Play Store. All apps (except one) are at 50 to over 100 million downloads worldwide. For comparison, and because it is very popular in Germany, we have also included the Parship app (over 1 million downloads).
Permissions
As always with such a test, we first look at the permissions that each application requires. This step can already provide good indications of how an application will behave during operation and what data could potentially be collected in the process. If you then consider in advance which functionality these apps would like to implement and which permissions would be required for this, the list is relatively short: Of course, the apps would need access to the Internet (via WiFi or mobile WAN) – without this, the whole idea would certainly only work very poorly. In addition, it would certainly also make sense for the app to have access to the user’s rough location. Here, most people would surely prefer contacts that are at least located in the same time zone. Beyond that, and depending on the features provided, the apps might still need access to the camera and/or photo archive (no dating app without an extensive portfolio of selfies and posed vacation/adventure pics) and to audio and micro, if the whole thing also supports voice messaging and/or calls. There is no connected peripheral to communicate with, no activity to track, no contacts to manage (if you already have the contact on your contact list, you would not need the app) or any other higher function to perform. So the list of permissions for the apps under consideration should actually(!!) be pretty straightforward. Spoiler: It is not (always).
In fact, the values vary quite a bit between the different apps. The Badoo app, for example, requests a list of 51 permissions – about half of them can be explained with the provided functionality. The rest can at least be seen as “suspicious”. The permission ACTIVITY_RECOGNITION, for example, is also requested, which allows the recording of physical activity, as required by pedometers, for example. Furthermore, the app requires access to Bluetooth, localization (even if the app is not running in the foreground), PHONE_STATE (i.e. phone number, network provider, status of phone calls) and the Google AD_ID, which uniquely identifies the user and is used for personalized advertising purposes. This permission is claimed and used by all tested apps by the way.
All other apps range in the number of requested permissions between Badoo with 51 and Lovoo with 21 (see table). It is striking that all of them request the Google AD ID and all but one require the PHONE_STATE. In the case of Jaumo’s app, it is also noticeable that a whole set of custom permissions for the execution on devices of the Chinese, quasi-state-owned companies Honor and Huawei appears here. It is not quite clear for what functionality these additional permissions are needed here.
Trackers
Admittedly, the most interesting user data that can be collected specifically via a dating app is, of course, that which the users provide themselves and voluntarily. Apart from perhaps social media apps, which are naturally very similar to dating apps in terms of function and features, there is hardly any other app category in which users willingly disclose such detailed and extremely personal data. If this data can now be further associated and refined with additional metadata on cell phone and app usage, user activity, hardware, and so on, the possibilities of using it for advertising purposes can of course hardly be surpassed. This is precisely where trackers come in. And completely surprisingly (not…), the apps we examined have integrated plenty of them.
When we usually do our security analysis in the field of IoT and examine the related apps, we see on average about 2-3, sometimes 4 or 5 integrated trackers. These are mostly the typical Google Analytics and Firebase trackers. Of course, these also collect quite a bit of metadata, but for app developers, the focus here is usually actually on the analysis data to improve their product and not necessarily on data collection. In the case of the apps examined, none of them contains less than 6 clearly identifiable trackers. The peak value (for Lovoo) is even 17(!!) – also an absolute record among all the thousands of apps we have ever examined.
The aforementioned Google trackers are always present. As already mentioned, they are of course able to collect quite a bit of data, but since virtually no app comes without them nowadays, you can almost ignore the fact they are present. It is more interesting that not a single app in the test can do without the Facebook SDK. Of course, the app developers can argue with the registration option via Facebook profiles, but the Facebook Login module responsible for this is only one of the three that we could find in every single app. Facebook Ads and Facebook Analytics are the other two. Also often found are the Adjust and AppsFlyer trackers – these are also included in almost every app. All kinds of advertising trackers from Amazon or Verizon, for example, are also frequently included.
In the table, we have listed which trackers could be clearly identified in which apps. It also shows for how many of these trackers we were able to detect specific activity, i.e., observable communication.
Communication
At least: The communication of the applications looks okay from a security point of view. We did not see any conspicuous, unencrypted communication, nor any signs of critical security problems. Of course, massive data streams from the integrated tracking modules can be observed in all apps without exception, but at least this data does not seem to be easily accessible to “unauthorized” third parties. However, as mentioned, we did not explicitly perform a security analysis here, so it is rather a superficial assessment. We might save the security analysis for a later time, though.
The data streams that we could observe always look similar in principle: Lots of metadata about the device hardware, the system, and the user, along with some IDs given to the user and/or his device, as well as usually a larger section of binary data, where you can’t say much concrete about the content without further in-depth reverse engineering of the corresponding tracker. Otherwise, the communication of the same trackers in different apps does not really differ. The version of the Facebook SDK, for example, varies slightly from app to app, but there are no really noticeable differences overall.
Privacy policies
Of course, we also looked at the privacy policies of all apps, which already implies that there is one for every app – in the IoT world, this is actually not 100% true even nowadays. We subjected the privacy policy statements of all apps only to a automated analysis, but the result was already quite satisfactory: All privacy policies are quite detailed, explicitly inform about the most essential topics of data collection, processing and sharing, and can be viewed directly and easily via the Play Store. So far so good. However, there are still a few conspicuous points.
For example, not a single privacy policy statement considered it necessary to name the trackers included. At least the Google trackers are mentioned here and there, but the Facebook SDK, which is always included, is not even mentioned once. With applications that sometimes integrate far more than 10 trackers, one can certainly find this suspicious at the very least.
As far as the readability of privacy statements is concerned, we have definitely seen better here. The readability of a continuous text can be determined programmatically using the Flesch-Kincaid test, for example. The result is a value between 0 and 100, which indicates how easy it is to understand the text. 90 – 100 certifies a good comprehensibility even for school children. From 30 and down, you are on the other side of the scale with at least a university degree to be able to understand the text. The privacy statements of all the apps examined are similar with values between 10 and 20, so it would be quite difficult to make the whole thing even more incomprehensible even if one tried.
Verdict
In principle, the analysis revealed exactly what we had assumed in advance. It would have been a real surprise if dating apps were not among the larger data leeches. The information that can be obtained about users here is simply so detailed, so personal, and so far-reaching that it is more than worth its weight in gold for the companies collecting it. Only social media and health apps offer a similarly detailed insight into specific areas of a user’s life. Perhaps next we will simply look at representatives of these categories for comparison. The result is likely to be similarly surprising…
Previous article 
