What some messaging apps are taking away about you – You would think that apps such as Facebook Messenger, Instagram and LinkedIn would be more mindful about Data leakage happening through their apps. But research has shown that especially those apps are the big culprit.
Researchers found several cases of apps with vulnerabilities such as: leaking IP addresses, exposinglinks sent in end-to-end encrypted chats, and unnecessarily downloading gigabytes of data quietly in the background. We all have been there, you have file you want to send to somebody but you don’t want to send the complete file so… you send a link to Dropbox, iCloud or Google Drive. In the future you may want to give that a second thought. Security experts have found that sending a link gives away more data about you then youwould have wanted. Hold up don’t run to the store to buy a new device just yet, cause it’s not your device. This issue has been observed in both iPhone and Android.
Links and Previews
In the spirit of user friendliness, when you send a link to somebody using apps like WhatsApp, iMessage or Facebook the app will make a preview of the link. This is very useful for the receiver cause the preview often contains an image, title and sometimes a short description. The goal of the preview is so the receiver can decide if the file is worth opening.
In order for the app to make a preview, it opens the link and extract the data needed and this is where experts say the problem lies. Why? There are many methods available to do so and they are not always safe.
There are 4 ways to approach generating previews:
1. Don't generate a link preview
This one is straightforward: Don’t generate a preview at all. Just show the link as it was sent. This is the safest way to handle links since the app won’t do anything with the link unless you specifically tap on it.
Some examples of apps that already do this:
- Signal (if the link preview option is turned off in settings)
You can see what a link preview looks like in this image. Both text messages show a the link, but also a site name, page title and even a page content preview.
2. The sender generates the preview
.In this approach, when you send a link, the app will go and download what’s in the link. It’ll create a summary and a preview image of the website, and it will send this as an attachment along with the link. When the app on the receiving end gets the message, it’ll show the preview as it got from the sender without having to open the link at all. This way, the receiver would be protected from risk if the link is malicious. This approach assumes that whoever is sending the link must trust it, since it’ll be the sender’s app that will have to open the link.
The following apps use this technique, for example:
- Signal (if the link preview option is turned on in settings)
3. The receiver generates the preview
This one is bad. This approach means that whenever you receive a link from someone, your app will open the link automatically to create the preview. This will happen before you even tap on the link, you only need to see the message. What’s wrong with this approach? Let’s briefly explain what happens when an app “opens” a link. First, the app has to connect to the server that the link leads to and ask it for what’s in the link. This is referred to as a GET request.
In order for the server to know where to send back the data, the app includes your phone’s IP address in the GET request. Normally, this would be fine if you know that you’re planning on opening the link. But what if an attacker wants to know your approximate location without you noticing, down to a city block? If you’re using an app that follows this approach, all an attacker would have to do is send you a link to their own server where it can record your IP address. Your app will happily open the link even without you tapping on it, and now the attacker will know where you are. You can see for yourself how an IP address can determine your approximate location.
Not only that, this approach can also be a problem if the link points to a large file, like a video or a zip file. A buggy app might try to download the whole file, even if it’s gigabytes in size, causing it to use up your phone’s battery and data plan.
4. A server generates the preview
This takes the “middle” approach, quite literally. When you send a link, the app will first send the link to an external server and ask it to generate a preview, then the server will send the preview back to both the sender and receiver. At first glance this seems sensible. Neither the sender nor receiver will open the link, and it avoids the IP leaking problem in Approach 2. But say you were sending a private Dropbox link to someone, and you don’t want anyone else to see what’s in it. With this approach, the server will need to make a copy (or at least a partial copy) of what’s in the link to generate the preview. Now the question is: Does the server keep that copy? If so, how long does it keep it for? What else do these servers do with this data?
This approach shouldn’t work for apps that use end-to-end encryption, where no servers in between the sender and receiver should be able to see what’s in the chat (at least in theory, anyway). The following apps use this technique:
- Facebook Messanger
- Google Hangouts
Unnecessary data usage
Another issue is the amount of unnecessary data usage. These apps automatically download the preview even if it is large file. Apps that rely on servers to generate link previews will limit how much data gets downloaded, since downloading too much data could in theory use up a server’s capacity and cause service disruptions.
But as highlighted in the last section, there were two apps that stood out in our testing: Facebook Messenger and Instagram, whose servers would download even very large files.
It’s still unclear to us why Facebook servers would do this when all the other apps put a limit on how much data gets downloaded.
Draining the Battery
In Approach 1 and Approach 2, the apps will open the link to generate a link preview when sending or receiving a link. In most cases, the apps wouldn’t have to download a lot of data to show the preview, at least if done properly. The problem arises when the app puts no limit on how much data gets downloaded when generating a preview.
Let’s say someone sent you a link to a really large picture like a 1.38 GB picture of the Milky Way (if you’re using data, don’t tap on it!), a buggy app that follows Approach 2 will attempt to download the whole file on your phone, draining your battery and using up your data. This could also lead your app crashing if it doesn’t know how to deal with large files.
Where to go from here?
Link previews aren’t just limited to the handful of messaging apps, there are many email apps, business apps, dating apps, games with built-in chat, and other kinds of apps that could be generating link previews improperly, and may be vulnerable to some of the problems we’ve covered here. Read more about link previews in the original research article.
There’s one big takeaway here for developers: Whenever you’re building a new feature, always keep in mind what sort of privacy and security implications it may have, especially if this feature is going to be used by thousands or even millions of people around the world. Link previews are nice a feature that users generally benefit from but there are many cases of the wide range of problems this feature can have when privacy and security concerns aren’t carefully considered.
If you’re not a developer, I hope this report gives you an appreciation for the subtleties of the small differences in the same exact feature, and how these differences can have a massive impact on security and privacy. That’s why we start our courses by learning data ethics first thing before going into any other subject. Learn more about the SkillsUP Lab and join our community of ethical data professionals.