Link Previews: How a Simple Feature Can Have Privacy and Security Risks

By Talal Haj Bakry and Tommy Mysk

If you enjoyed this work, you can support us by checking out our apps:


Link previews in chat apps can cause serious privacy problems if not done properly. We found several cases of apps with vulnerabilities such as: leaking IP addresses, exposing links sent in end-to-end encrypted chats, and unnecessarily downloading gigabytes of data quietly in the background.

We think link previews are a good case study of how a simple feature can have privacy and security risks. We’ll go over some of the bugs we found while investigating how this feature is implemented in the most popular chat apps on iOS and Android.


Instagram servers download any link sent in Direct Messages even if it’s 2.6 GB
How hackers can run any JavaScript code on Instagram servers

What are link previews?

You’ve probably noticed that when you send a link through most chat apps, the app will helpfully show a preview of that link.

Whether it’s a news article, a Word or PDF document, or a cute gif, you’ll see a short summary and a preview image inline with the rest of the conversation, all without having to tap on the link. Like so:

Link previews in Signal
Link previews in Signal

Sounds like a nice feature, doesn’t it? But could a simple feature like this come with a few unexpected privacy and security concerns?

Let’s take a step back and think about how a preview gets generated. How does the app know what to show in the summary? It must somehow automatically open the link to know what’s inside. But is that safe? What if the link contains malware? Or what if the link leads to a very large file that you wouldn’t want the app to download and use up your data?

Let’s go over the different approaches that an app could take to show a link preview.

Approach 0: 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.

In our testing, the apps listed below follow this approach:

  • Signal (if the link preview option is turned off in settings)
  • Threema
  • TikTok
  • WeChat

Approach 1: 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 reciever 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.

In our testing, the apps listed below follow this approach:

  • iMessage
  • Signal (if the link preview option is turned on in settings)
  • Viber
  • WhatsApp

Approach 2: 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.

Our testing did find two apps that followed this approach:

  • Reddit (only in the chat, not when viewing posts and comments)
  • β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ

We reported this problem to the security teams at Reddit and β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ, and we’re happy to report that both apps have been fixed before we published this blog post. (Actually, β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ is still in the process of fixing the issue, hence their name is redacted until a fix is deployed).

Approach 3: 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).

These were some of the apps that followed this approach, although they differ significantly in how their servers opened links:

  • Discord
  • Facebook Messenger
  • Google Hangouts
  • Instagram
  • LINE (this one actually deserves a 🀬, but we’ll get to it later)
  • LinkedIn
  • Slack
  • Twitter
  • Zoom
  • β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ

Digging Deeper

Now that we’ve covered the basic approaches to generate link previews, we can go over the more specific details of the risks and the privacy implications we’ve discovered. Here we’ll describe each of the risks we found in our testing:

Unauthorized Copies of Private Information

Links shared in chats may contain private information intended only for the recipients. This could be bills, contracts, medical records, or anything that may be confidential. Apps that rely on servers to generate link previews (Approach 3) maybe be violating the privacy of their users by sending links shared in a private chat to their servers.

How so? Although these servers are trusted by the app, there’s no indication to users that the servers are downloading whatever they find in a link. Are the servers downloading entire files, or only a small amount to show the preview? If they’re downloading entire files, do the servers keep a copy, and if so for how long? And are these copies stored securely, or can the people who run the servers access the copies?

Also, some countries have restrictions on where user data can be collected and stored, most notably in the European Union as enforced by the GDPR.

In our testing, apps vary widely in how much data gets downloaded by their servers. Here’s a rundown of what we found:

  • Discord: Downloads up to 15 MB of any kind of file.
  • Facebook Messenger: Downloads entire files if it’s a picture or a video, even files gigabytes in size. * πŸ‘‹
  • Google Hangouts: Downloads up to 20 MB of any kind of file.
  • Instagram: Just like Facebook Messenger, but not limited to any kind of file. The servers will download anything no matter the size.* πŸ‘‹
  • LINE: Downloads up to 20 MB of any kind of file. (This one still deserves a big πŸ‘Ž as we’ll discuss later)
  • LinkedIn: Downloads up to 50 MB of any kind of file.
  • Slack: Downloads up to 50 MB of any kind of file.
  • Twitter: Downloads up to 25 MB of any kind of file.
  • Zoom: Downloads up to 30 MB of any kind of file.
  • β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ: β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ

(πŸ‘‹ We did contact Facebook to report this problem, and they told us that they consider this to be working as intended.)

Though most of the app servers we’ve tested put a limit on how much data gets downloaded, even a 15 MB limit still covers most files that would typically be shared through a link (most pictures and documents don’t exceed a few MBs in size). So if these servers do keep copies, it would be a privacy nightmare if there’s ever a data breach of these servers. This is especially a concern for business apps like Zoom and Slack.

Slack, for example, has confirmed that they only cache link previews for around 30 minutes.

So that secret design document that you shared a link to from your OneDrive, and you thought you had deleted because you no longer wanted to share it? There might be a copy of it on one of these link preview servers.

Getting Servers to Download Large Amounts of Data

As we covered in the previous section, apps that follow Approach 3 will rely on servers to generate link previews. Most of these servers 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 we 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.

Crashing Apps and 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 this 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.

Before they were fixed, both Reddit and β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ apps had this problem. Viber is still vulnerable to this problem.

Exposing IP Addresses

As we explained earlier, in order to open a link your phone has to communicate with the server that the link points to. Doing so means that the server will know the IP address of your phone, which could reveal your approximate location. Normally, this wouldn’t be much of a problem if you can avoid tapping on links you believe to be malicious.

In Approach 1, where the sender’s phone opens the link to generate the preview, the server will know the sender’s IP. This might not be a problem if we can assume that the sender trusts the link that they’re sending, since they’re the ones taking action to send a link.

Approach 2, however, is entirely unsafe. Since the receiver’s phone will be opening the link to generate the preview, the receiver’s IP will be known to the server. This would happen without any action taken by the receiver, and this can put them in danger of having their location exposed to the server without their knowledge.

The chat feature in the official Reddit apps were vulnerable to this problem, so we reported this problem to their security team. We were extremely pleased with their quick response to our report, and they promptly released fixed versions of their iOS and Android apps. πŸ‘

Leaking Encrypted Links

Some chat apps encrypt messages in such a way that only the sender and receiver can read the messages, and no one else (not even the app’s servers). This is referred to as end-to-end encryption. Among the apps we tested, these were the ones that utilized this type of encryption:

  • iMessage
  • LINE
  • Signal
  • Threema
  • Viber
  • WhatsApp

Since only the sender or receiver can read encrypted messages and the links contained in them, Approach 3 shouldn’t be possible in these apps since it relies on having a server to generate link previews.

But, didn’t we say that LINE followed Approach 3?

Well, it appears that when the LINE app opens an encrypted message and finds a link, it sends that link to a LINE server to generate the preview. We believe that this defeats the purpose of end-to-end encryption, since LINE servers know all about the links that are being sent through the app, and who’s sharing which links to whom.

Basically, if you’re building an end-to-end encrypted app, please don’t follow Approach 3.

Running Potentially Malicious Code on Link Preview Servers

Most websites these days contain Javascript code to make them more interactive (and sometimes to show you ads and track you, but that’s a topic for another day). When generating link previews, no matter which of the above approaches is followed, it’s a good idea to avoid running any code from these websites, since as a service provider you can’t trust code that may be found in all the random links that get shared in chats.

We did find, however, at least two major apps that did this: Instagram and LinkedIn. We tested this by sending a link to a website on our server which contained JavaScript code that simply made a callback to our server. We were able to confirm that we had at least 20 seconds of execution time on these servers. It may not sound like much, and our code didn’t really do anything bad, but hackers can be creative.

App Developers Respond to our Findings


Discord follows Approach 3, and their servers download up to 15 MB to generate link previews. However, we still have concerns about how long this data gets stored on their servers.

We contacted Discord to report our findings on September 19th, 2020, but we have not received a response from them.

Facebook Messenger and Instagram

Facebook Messenger and Instagram Direct Messages follow Approach 3, and since they are both owned and operated by Facebook they actually share the same server infrastructure. These servers were the only ones in our testing that put no limit on how much data gets downloaded.

To demonstrate this, we hosted a 2.6 GB file on our server, and we sent a link to that file through an Instagram DM. Since the file was on our server, we were able to see who’s downloading the file and how much data gets downloaded in total.

The moment the link was sent, several Facebook servers immediately started downloading the file from our server. Since it wasn’t just one server, that large 2.6 GB file was downloaded several times. In total, approximately 24.7 GB of data was downloaded from our server by Facebook servers.

This was so surprising to us, so we had to take a video of what we saw:

Instagram servers download any link sent in Direct Messages even if it’s 2.6 GB

As we mentioned earlier, Facebook was given a noticed of these issues when we submitted two reports to them along with the videos on September 12th, 2020.

Facebook servers download any link sent in Facebook Messenger even if it’s 2.6 GB
How hackers can run any JavaScript code on Instagram servers

Google Hangouts

Google Hangouts follows Approach 3, and their servers download up to 20 MB to generate link previews. Again, there is the concern about how long this data gets stored on their servers.

We submitted a report to Google on September 16th, 2020, but we have not received a response from them.

LINE πŸ‘•πŸ‘•

Even though LINE is an end-to-end encrypted chat app, they do forward links sent in a chat to an external server that generates link previews. This server also forwarded the IP addresses of both the sender and receiver to that link. πŸ€¦β€β™€οΈ

We sent a report with our findings to the LINE security team. They agreed with us that their servers shouldn’t be forwarding the IP addresses of their users to generate link previews, but they still think it’s acceptable for an end-to-end encrypted chat app to use an external server to generate link previews. They have however updated their FAQ to include this information and to show how to disable link previews.

As of versions 10.18.0 for Android and 10.16.1 for iOS, the apps no longer leak IP addresses when generating link previews.

LINE leaks IP addresses of users and bypasses end-to-end encryption πŸ‘•πŸ‘•


LinkedIn Messages follows Approach 3, and their servers download up to 50 MB to generate link previews. But their servers were vulnerable to running Javascript code, which allowed us to bypass the 50 MB download limit. We also had concerns about how long the link preview data gets stored on their servers.

We sent a report with our findings to the LinkedIn security team on September 16th, 2020 but we have yet to receive a response from them at the time of publishing this blog post.

How hackers can run any JavaScript code on LinkedIn servers


The chat feature in the official Reddit apps on iOS and Android were vulnerable to leaking the IP addresses of anyone who receives a link, since it followed Approach 2.

We are pleased with the response we got from the team at Reddit. They were prompt in responding to our report and released fixed versions (2020.36.0 for Android and 2020.37.0 for iOS) of their iOS and Android apps quickly. Kudos to them!

Bug in Reddit app causes it to leak the IP address of any user (FIXED)
Bug in Reddit for iOS causes it to download large files until it crashes (FIXED)


Slack follows Approach 3, and their servers download up to 50 MB to generate link previews. However, we are still concerned about how long this data gets stored on their servers, especially since Slack is used primarily by businesses which may be sharing sensitive or confidential links through chats and channels.

Slack reported to us that link previews are only cached for approximately 30 minutes. This is also confirmed in their documentation.


Twitter Direct Messages follows Approach 3, and their servers download up to 25 MB to generate link previews. There is still the problem of how long this data gets stored on their servers.

We contacted Twitter and they told us that this is working as intended. They have not disclosed how long the link preview data is kept for.


Viber is end-to-end encrypted and follows Approach 1, where the sender would generate the link preview. Though we did find a bug: if you send a link to a large file, your phone will automatically try to download the whole file even if it’s several gigabytes in size.

It’s also worth mentioning that even though Viber chats are end-to-end encrypted, tapping on a link will cause the app to forward that link to Viber servers for the purposes of fraud protection and personalized ads. You can find more info about this on their support website.

A bug in Viber causes the app to download large files even gigabytes in size


Zoom follows Approach 3, and their servers download up to 30 MB to generate link previews. However, we still have concerns about how long this data gets stored on their servers, especially since Zoom is used primarily by businesses which may be sharing sensitive or confidential links through chats.

We submitted a report to Zoom on September 16th, 2020, and they have told us that they’re looking into this issue and that they’re discussing ways to ensure user privacy.




Where to go from here?

Since we’re only two people doing this research in our spare time, we could only cover a small set of the millions of apps out there. Link previews aren’t just limited to the handful of chat apps we looked at: 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.

We think 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 here we’ve showcased the wide range of problems this feature can have when privacy and security concerns aren’t carefully considered.

If you’re not a developer, we 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.


App NameEnd-to-End EncryptedUnauthorized Copies of Private InformationGetting Servers to Download Large Amounts of DataCrashing Apps and Draining the BatteryIP ExposureLeaking Encrypted LinksRunning Potentially Malicious Code on Link Preview Servers
DiscordUp to 15 MBβœ…βœ…βœ…βœ…βœ…
Facebook Messenger❌ Unlimited!βŒβœ…βœ…βœ…βŒ
Google HangoutsUp to 20 MBβœ…βœ…βœ…βœ…βœ…
Instagram❌ Unlimited!βŒβœ…βœ…βœ…βŒ
LINEβœ…Up to 20 MBβœ…βœ…βŒ (Fixed!)βŒβŒβŒβœ…
LinkedInUp to 50 MB❌ (Through Javascript)βœ…βœ…βœ…βŒ
Redditβœ…βœ…βŒ (Fixed!)❌ (Fixed!)βœ…βœ…
SlackUp to 50 MBβœ…βœ…βœ…βœ…βœ…
TwitterUp to 25 MBβœ…βœ…βœ…βœ…βœ…
ZoomUp to 30 MBβœ…βœ…βœ…βœ…βœ…

Comparison of all apps we tested

Boring Yet Necessary Information

Here’s the table summarizing all the apps we tested and their version numbers:

App NameiOS VersionAndroid Version
Facebook Messenger280.
Google Hangouts35.0.32484637035.0.327050771
Zoom5.2.2 (45104.0831)5.2.2 (45092.0831)

TikTok Vulnerability Enables Hackers to Show Users Fake Videos

By Talal Haj Bakry and Tommy Mysk

UPDATE (MAY 5, 2020): TikTok rolled updates for iOS and Android in May that fixed this vulnerability.

If you enjoyed this work, you can support us by checking out our apps:


  • Video manipulation of popular TikTok accounts

  • Demonstration of posting spam on WHO’s feed


The TikTok app uses insecure HTTP to download media content. Like all social media apps with a large userbase, TikTok relies on Content Delivery Networks (CDNs) to distribute their massive data geographically. TikTok’s CDN chooses to transfer videos and other media data over HTTP. While this improves the performance of data transfer, it puts user privacy at risk. HTTP traffic can be easily tracked, and even altered by malicious actors. This article explains how an attacker can switch videos published by TikTok users with different ones, including those from verified accounts.


Modern apps are expected to preserve the privacy of their users and the integrity of the information they display to them. Apps which use unencrypted HTTP for data transfer cannot guarantee that the data they receive wasn’t monitored or altered. This is why Apple introduced App Transport Security in iOS 9, to require all HTTP connections to use encrypted HTTPS. Google has also changed the default network security configuration in Android Pie to block all plaintext HTTP traffic. 

Apple and Google still provide a way for developers to opt-out of HTTPS for backwards-compatibility. However, this should be the exception rather than the rule, and most apps have made the transition to HTTPS. At the time of writing, TikTok for iOS (Version 15.5.6) and TikTok for Android (Version 15.7.4) still use unencrypted HTTP to connect to the TikTok CDN.

After a short session of capturing and analyzing network traffic from the TikTok app with Wireshark, it is hard to miss the large amounts of data transferred over HTTP. If you inspect the network packets closer, you would clearly spot data of videos and images being transferred in the clear and unencrypted. 

Consequently, TikTok inherits all of the known and well-documented HTTP vulnerabilities. Any router between the TikTok app and TikTok’s CDNs can easily list all the videos that a user has downloaded and watched, exposing their watch history. Public Wifi operators, Internet Service Providers, and intelligence agencies can collect this data without much effort.

Figure 1 illustrates the network traffic as captured by Wireshark.

TikTok transports the following content via HTTP:

  • Videos: all videos that the app shows
  • Profile photos: the profile photos of TikTok accounts
  • Video still images: the preview image of a video that is displayed while the video is being downloaded

The captured data shows that videos are downloaded from the following domain names:

  • http://v19.muscdn.com
  • http://v21.muscdn.com
  • http://v34.muscdn.com

In addition, profile photos and still images are downloaded from http://p16.muscdn.com.

Figure 1: HTTP network traffic used by TikTok

All the content types listed above are prone to tracking. For example, watch history can be created by capturing network traffic downloaded from http://v34.muscdn.com.

Moreover, a man-in-the-middle attack can alter the downloaded content. For example, swapping profile photos of accounts with forged photos. However, this is not as critical as swapping videos. While a picture is worth a thousand words, a video is certainly worth more. Thus, the attacker can convey more fake facts in a spam video swapped with a video that belongs to a celebrity or a trusted account.

The circulation of misleading and fake videos in a popular platform such as TikTok poses huge risks. That encouraged us to stage a man-in-the-middle attack to swap videos and demonstrate the results. The following section delves deeper into the technical details of our work.


We prepared a collection of forged videos and hosted them on a server that mimics the behavior of TikTok CDN servers, namely v34.muscdn.com. To make it simple, we only built a scenario that swaps videos. We kept profile photos intact, although they can be similarly altered. We only mimicked the behavior of one video server. This shows a nice mix of fake and real videos and gives users a sense of credibility.

To get the TikTok app to show our forged videos, we need to direct the app to our fake server. Because our fake server impersonates TikTok servers, the app cannot tell that it is communicating with a fake server. Thus, it will blindly consume any content downloaded from it.

The trick to direct the app to our fake server is simple; it merely includes writing a DNS record for v34.muscdn.com that maps the domain name to the IP address of our fake server.

This can be achieved by actors who have direct access to the routers that users are connected to. First, a record mapping the domain name v34.muscdn.com to a fake server has to be added to a DNS server. Second, the infected routers have to be configured to use that corrupt DNS server. Now, when the TikTok app tries to look up the IP address of v34.muscdn.com, the corrupt DNS server returns the IP address of the fake server. Then, the app will send all subsequent calls to the fake server that is impersonating TikTok’s v34.muscdn.com.

Those actions can be performed by any of the following actors:

  • Wifi Operators: operators of public wifi networks can configure the router to use a corrupt DNS server
  • VPN providers: a malicious VPN provider can configure a corrupt DNS server for its users
  • Internet Service Providers (ISPs): Internet Service Providers such as telecom companies have full access to the internet connections of their customers. They can configure a corrupt DNS server for their customers to swap content or track user activities
  • Governments and intelligence agencies: in some countries governments and intelligence agencies can force ISPs to install tools that track or alter data

If you distrust any of these actors, then what you watch on TikTok may have been altered. This also applies to any internet service that uses HTTP.

Figure 2 illustrates the HTTP network traffic directed to the fake server. The highlighted row shows a video request sent by the app to the destination IP, which is the IP address of our fake server. The fake server then picks a forged video and returns it to the app which, in turn, plays the forged video to the user as shown in the demo video. Note that only video requests are directed to the fake server. Requests to download profile photos and still images are directed to the real servers, i.e. we left them unchanged as per our scenario. In contrast, Figure 1 shows a similar video request sent to the real TikTok server with the IP

Figure 2: TikTok traffic analyzed by Wireshark


Figure 3: A hacked video appears on the British Red Cross account (iOS)

The forged videos we created present misleading information about COVID-19. This illustrates a potential source of disseminating misinformation and false facts about a contemporary critical topic.

As shown in the demo video and Figures 3-6, the forged videos appeared on popular and verified accounts like @who, @britishredcross, @americanredcross, @tiktok, @lorengray, and @dalia. (@lorengray has over 42 million followers and 2.3 billion likes)

Figure 4: A hacked video appears on TikTok’s account (iOS)


Figure 5: A hacked video appears on Loren Gray’s account (iOS)

Figure 6: A hacked video appears on WHO’s account (Android)

To recap, only users connected to my home router can see this malicious content. However, if a popular DNS server was hacked to include a corrupt DNS record as we showed earlier, misleading information, fake news, or abusive videos would be viewed on a large scale, and this is not completely impossible.


The use of HTTP to transfer sensitive data has not gone extinct yet, unfortunately. As demonstrated, HTTP opens the door for server impersonation and data manipulation. We successfully intercepted TikTok traffic and fooled the app to show our own videos as if they were published by popular and verified accounts. This makes a perfect tool for those who relentlessly try to pollute the internet with misleading facts.

TikTok, a social networking giant with around 800 million monthly active users, must adhere to industry standards in terms of data privacy and protection.

Popular iPhone and iPad Apps Snooping on the Pasteboard

By Talal Haj Bakry and Tommy Mysk

UPDATE (AUGUST 16, 2020): More apps crossed out *

UPDATE (JUNE 30, 2020): The list of apps in the original report from March 2020 is NOT an exhaustive list. We examined a sample of popular apps, and listed the ones that exhibited the behavior of excessive clipboard access. Many apps have been updated since then. In light of that, we tested the apps again. The apps that stopped reading the clipboard are crossed out.   

If you enjoyed this work, you can support us by checking out our apps:


  • Two apps; one snoops on the clipboard, the other doesn’t

  • Method to view pasteboard events using Xcode


This article provides an investigation of some popular apps that frequently access the pasteboard without user consent. These apps range from popular games and social networking apps, to news apps of major news organizations. We found that many apps quietly read any text found in the pasteboard every time the app is opened. Text left in the pasteboard could be as simple as a shopping list, or could be something more sensitive: passwords, account numbers, etc.


Apps on iOS and iPadOS have unrestricted access to the system-wide general pasteboard, also referred to as the clipboard. The potential security risks of this vulnerability have been thoroughly discussed in a previous article: Precise Location Information Leaking Through System Pasteboard. We have explored popular and top apps available on the App Store and observed their behaviour using the standard Apple development tools. The results show that many apps frequently access the pasteboard and read its content without user consent, albeit only text-based data.

The apps we chose in this investigation belong to various App Store categories, e.g. games, social networking, and news. As we described in our pervious article, the severity of the pasteboard vulnerability is greatest when popular and frequently-used apps exploit it. Thus, we targeted a variety of popular apps we found on the top lists of the App Store.


Apple provides Xcode and Xcode Command Line tools for developers to build apps for iOS, iPadOS, and macOS. We used these official tools to monitor and analyze the behavior of apps installed on our iOS and iPadOS devices. The method is simple: Once we connect and pair the devices with Xcode, we can read the system log of the device. Fortunately, all pasteboard events are clearly logged. Figure 1 shows an example of the system log output when the Fox News app is opened. The following explains the key information in the log output:

  • The logs output all events, and is filtered by the keyword β€œpasteboard”
  • The highlighted event in Figure 1 shows when the Fox News app requested access to the pasteboard with ID com.apple.UIKit.pboard.general. This is the ID of the system-wide pasteboard
  • BundleID com.foxnews.foxnews is the ID that uniquely identifies the Fox News app on the App Store
  • The event message that starts with β€œLoading item …” in Figure 2, indicates that the app has read the content of the pasteboard.
  • The type public.utf8-plain-text indicates that the content that the app has read is text.

This method can be performed by any iOS or Mac developer.

Figure 1

Figure 2


We include any app that requests and reads the content of the system-wide pasteboard every time it’s opened, and consider it to be highly suspicious. There are games and apps that do not provide any UI that deals with text, yet they read the text content of the pasteboard every time they’re opened.

Every app that is popular or on a top list according to the App Store rankings qualifies to be part of this investigation. However, we picked a diverse collection of apps to provide proof that such a suspicious practice of snooping on the pasteboard exists in many apps.

There is a considerable number of apps that only read the content of the pasteboard on launch. That is, the app reads the pasteboard only when it is opened for the first time. The next time it reads the pasteboard again is when the app is quit and relaunched. Although such a behavior is also suspicious, we decided to exclude such apps and focus on the ones that access the pasteboard more frequently.

As noted in our previous article, an app that accesses the pasteboard can also read what has been copied on a Mac if Universal Clipboard is enabled.


While unrestricted access to the pasteboard allow apps to read any data type, all the apps we investigated for this article have only requested access to text data. In other words, they are only interested in reading text and ignore other data types that may have been copied to the pasteboard, such as photos and PDF documents. Surprisingly, none of the widgets that were tested accessed the pasteboard.

Our findings only documented apps that read the pasteboard every time the app is opened. However, apps can delay snooping on the pasteboard until some time or event takes places (e.g. signing up), hence are not included in our findings.

List of Apps

This section summarizes the list of apps that snoop on the pasteboard every time the app is opened. The apps are listed alphabetically in the following format:

  • App Name β€” BundleID

UPDATE (AUGUST 16, 2020): More apps crossed out *

UPDATE (JUNE 30, 2020): The list of apps in the original report from March 2020 is NOT an exhaustive list. We examined a sample of popular apps, and listed the ones that exhibited the behavior of excessive clipboard access. Many apps have been updated since then. In light of that, we tested the apps again. The apps that stopped reading the clipboard are crossed out.   

We thank developers who updated their apps to fix this privacy issue.


  • ABC News β€” com.abcnews.ABCNews
  • Al Jazeera English β€” ajenglishiphone
  • CBC News β€” ca.cbc.CBCNews
  • CBS News β€” com.H443NM7F8H.CBSNews
  • CNBC β€” com.nbcuni.cnbc.cnbcrtipad *
  • Fox News β€” com.foxnews.foxnews *
  • News Break β€” com.particlenews.newsbreak *
  • New York Times β€” com.nytimes.NYTimes *
  • NPR β€” org.npr.nprnews
  • ntv Nachrichten β€” de.n-tv.n-tvmobil
  • Reuters β€” com.thomsonreuters.Reuters
  • Russia Today β€” com.rt.RTNewsEnglish *
  • Stern Nachrichten β€” de.grunerundjahr.sternneu
  • The Economist β€” com.economist.lamarr *
  • The Huffington Post β€” com.huffingtonpost.HuffingtonPost *
  • The Wall Street Journal β€” com.dowjones.WSJ.ipad *
  • Vice News β€” com.vice.news.VICE-News *


  • 8 Ball Poolβ„’ β€” com.miniclip.8ballpoolmult
  • AMAZE!!! β€” com.amaze.game
  • Bejeweled β€” com.ea.ios.bejeweledskies
  • Block Puzzle β€” Game.BlockPuzzle
  • Classic Bejeweled β€” com.popcap.ios.Bej3
  • Classic Bejeweled HD β€” com.popcap.ios.Bej3HD
  • FlipTheGun β€” com.playgendary.flipgun
  • Fruit Ninja β€” com.halfbrick.FruitNinjaLite *
  • Golfmasters β€” com.playgendary.sportmasterstwo
  • Letter Soup β€” com.candywriter.apollo7
  • Love Nikki β€” com.elex.nikki
  • My Emma β€” com.crazylabs.myemma
  • Plants vs. Zombiesβ„’ Heroes β€” com.ea.ios.pvzheroes 
  • Pooking – Billiards City β€” com.pool.club.billiards.city
  • PUBG Mobile β€” com.tencent.ig
  • Tomb of the Mask β€” com.happymagenta.fromcore
  • Tomb of the Mask: Color β€” com.happymagenta.totm2
  • Total Party Kill β€” com.adventureislands.totalpartykill
  • Watermarbling β€” com.hydro.dipping

Social Networking

  • TikTok β€” com.zhiliaoapp.musically
  • ToTalk β€” totalk.gofeiyu.com
  • Tok β€” com.SimpleDate.Tok
  • Truecaller β€” com.truesoftware.TrueCallerOther
  • Viber β€” com.viber
  • Weibo β€” com.sina.weibo *
  • Zoosk β€” com.zoosk.Zoosk


  • 10% Happier: Meditation β€”com.changecollective.tenpercenthappier
  • 5-0 Radio Police Scanner β€” com.smartestapple.50radiofree
  • Accuweather β€” com.yourcompany.TestWithCustomTabs *
  • AliExpress Shopping App β€” com.alibaba.iAliexpress *
  • Bed Bath & Beyond β€” com.digby.bedbathbeyond *
  • Dazn β€” com.dazn.theApp
  • Hotels.com β€” com.hotels.HotelsNearMe
  • Hotel Tonight β€” com.hoteltonight.prod
  • Overstock β€” com.overstock.app
  • Pigment – Adult Coloring Book β€” com.pixite.pigment *
  • Recolor Coloring Book to Color β€” com.sumoing.ReColor
  • Sky Ticket β€” de.sky.skyonline *
  • The Weather Network β€” com.theweathernetwork.weathereyeiphone *


Access to the pasteboard in iOS and iPadOS requires no app permission as of iOS 13.3. While the pasteboard provides the ease of sharing data between various apps, it poses a risk of exposing private and personal data to suspicious apps. We have investigated many popular apps in the App Store and found that they frequently access the pasteboard without the user being aware. Our investigation confirms that many popular apps read the text content of the pasteboard. However, it is not clear what the apps do with the data. To prevent apps from exploiting the pasteboard, Apple must act.

Media Coverage

This article was well-received in social media and has been covered by several tech websites. The following list provides links to the coverage:

Precise Location Information Leaking Through System Pasteboard

By Talal Haj Bakry and Tommy Mysk

UPDATE (JUNE 22, 2020): Apple addressed this vulnerability in iOS 14 and iPadOS 14 by showing a notification every time an app reads the clipboard.

Disclaimer: We submitted this article and source code to Apple on January 2, 2020. After analyzing the submission, Apple informed us that they don’t see an issue with this vulnerability.

If you enjoyed this work, you can support us by checking out our apps:




  • Exploit of location information stored in photos 


iOS and iPadOS apps have unrestricted access to the systemwide general pasteboard. A user may unwittingly expose their precise location to apps by simply copying a photo taken by the built-in Camera app to the general pasteboard. Through the GPS coordinates contained in the embedded image properties, any app used by the user after copying such a photo to the pasteboard can read the location information stored in the image properties, and accurately infer a user’s precise location. This can happen completely transparently and without user consent.


To clearly address the exploit described in this article, this section defines a few terms to bring the reader to the same context as intended by the authors.

User: a user using an Apple device running the latest iOS or iPadOS version, Version 13.3, at the time of writing.

Pasteboard: the systemwide general pasteboard available in iOS and iPadOS that is used for copy-cut-paste operations. It is identified with the general constant.

Malicious app: an app that repeatedly reads the content stored in the pasteboard to collect data about the user.

Camera app: the built-in camera app that is pre-installed on iOS and iPadOS

Current device: the Apple device used by the user and has a malicious app installed on it. 

Vulnerability window: the timeframe during which an app can read the pasteboard.

Affected Apple Products

All Apple devices running the latest version of iOS and iPadOS β€” Version 13.3, at the time of this writing.


Apple has designated a special permission for accessing GPS information from an Apple device. Apps can only access location information if the user has explicitly granted such access. An average user assumes that apps cannot know their location unless the location services permission is granted. However, an app can infer a user’s location without requesting that from the user β€” by analyzing the geolocation of the user’s IP address, for example. Fortunately, this method does not provide an intrusive app a high degree of accuracy. The pasteboard can potentially provide such intrusive apps with what they are going after β€” precise user location without the user’s consent. 

Once a user grants the Camera app access to the location services, which normally happens when the user opens the Camera app for the first time, the Camera app adds precise GPS information to every photo the app takes. GPS information is part of the image metadata that iOS and iPadOS store in every photo. Developers can read these properties using the Image I/O Framework API CGImageSourceCopyProperties. Thus, it is a trivial task for developers to extract GPS information from a photo.

The aforementioned facts lay the ground for a potential exploit of precise location information that can be utilized by unauthorized apps. The following three steps have to be fulfilled for the vulnerability window to open:

  1. The user grants the Camera app access to the location services
  2. The user takes a photo using the Camera app
  3. The user copies the photo to the pasteboard

An average user is very likely to have performed all three steps. Copying photos from the Photos app is an increasingly common practice. As a result, the likelihood that a user has left out a photo stored in the pasteboard is alarmingly high. With that, the user has exposed their precise location information to any app that is used after this point of time, regardless of whether the app is granted access to location services or not.

A malicious app that constantly reads the content of the pasteboard can easily abuse this data. An average user is not aware that precise location information about the photo is stored in the photo itself, hence unaware of the privacy breach.

In addition to the GPS location stored in the photo, the malicious app can read the timestamp of the photo, the device model that shot the photo, and its operating system. With simple math, the malicious app can compare the values read from the photo properties and compare them to the corresponding actual values of the current device. Eventually, the malicious app can infer with great confidence whether the photo in the pasteboard was shot by the current device, hence the extracted location information belongs to the current device or user. In addition, the timestamp stored in the photo supplies the temporal property of the leaked location information.

iOS and iPadOS are designed to allow apps to read the pasteboard only when apps are active in the foreground. However, there are other techniques a malicious app can implement in order to increase the likelihood the app can read the pasteboard. As we will discuss later in the demonstration app, a widget extension can read the pasteboard as long as it is visible in the Today View. As a result, a widget placed on top of the Today View can read the pasteboard every time the user swipes to the Today View, hence expanding the vulnerability window. On iPadOS, a user can configure the Today View to be always visible on the home screen, allowing malicious app widgets more time and frequency to access the pasteboard.


Several apps made it to the news recently with links to organizations notorious for compromising user privacy. Unfortunately, some of the apps were very popular in some countries. If such malicious apps relied on reading user location from photos left in the pasteboard as described in this article, enough data may have already been harvested to put people’s lives in danger.


Apps should not have unrestricted access to the pasteboard without user’s consent. The best fix for this exploit is by introducing a new permission that enables the user to grant access to the pasteboard by app, just like contacts, location services, and photos, etc.

Alternatively, the operating system can only expose the content of the pasteboard to an app when the user actively performs a paste operation.

As a quick fix, the operating system can delete location information from photos once they are copied to the pasteboard.

Demonstration App

To illustrate the pasteboard vulnerability, we developed KlipboardSpy – a sample app that reads the pasteboard every time it enters the foreground. If a photo with GPS information is detected in the pasteboard, the app stores the photo properties. The app lists all saved photo properties in a table view. A detailed view is provided to show the properties extracted from each photo.

The KlipboardSpy.swift file shows sample code to read and store photo properties. Namely, the readClipboard() method is called every time the app becomes active. It reads the contents of the pasteboard and if it contains a photo, the method parses its properties and looks for GPS location information. If found, it will then persist all the properties in a Core Data store.

To maximize access to the pasteboard, we added a widget extension to the app. The widget extension increased the likelihood to access the pasteboard considerably. The viewDidAppear(_:) method is called every time the widget is shown in the Today View, making it perfectly suited for the readClipboard() method. Moreover, we added an App Group so that the widget can share captured pasteboard content with our app.

After both targets, namely KlipboardSpy and KlipSpyWidget, of the Xcode project are built and run successfully on a device, open the Photos app and copy an image with GPS information stored in its metadata. Then either open the app or swipe to open the Today View and scroll to make KlipSpyWidget visible on the screen (Figure 3). That’s it. The GPS location has been captured. Open KlipboardSpy. A new row for the captured content is now shown (Figure 1). Tap on the cell to navigate to the detailed view to inspect all the properties that the app captured from the pasteboard. Repeat by copying another photo, and so on.

The following table describes the fields that appear in the detailed view (Figure 2):

Field Name Description
GPS Latitude The latitude coordinate as extracted from the photo in the pasteboard
GPS Longitude The longitude coordinate as extracted from the photo in the pasteboard
Image Time The timestamp when the photo was taken as extracted from the photo in the pasteboard
Image Device The device model of the device used to take the photo as extracted from the photo in the pasteboard
Current Device The device model of the device that is running KlipboardSpy
Image OS Version The OS version of the device used to take the photo as extracted from the photo in the pasteboard
Current OS Version The OS version of the device that is running KlipboardSpy

The malicious app can infer the credibility of the location information extracted by matching the following properties:

Photo Property Device Propery Note
Image Time Current Time A match is not necessary, just to infer how old the coordinates are
Image Device Current Device  
Image OS Version Current OS Version A match will not occur for old photos that were taken with an older OS version 







Figure 1: KlipboardSpy main view. It shows a record for captured location information from the pasteboard

Figure 2: The detailed view of captured image properties.

Figure 3: The KlipSpyWidget in the Today View silently reading the pasteboard

Related Vulnerabilities

This article focuses on exploiting leaked location information from the pasteboard. We consider this leak very critical as it gives away precise location information without user’s consent. Exposing such precise location information can be life-threatening in some parts of our world. Having said that, unrestricted access to the pasteboard can lead to other personal data breaches.

A malicious app that actively monitors the pasteboard can store any content it finds in the pasteboard. Content ranges from contacts, photos, phone numbers, emails, IBAN bank information, URLs, PDFs of official documents, audio files, word documents, spreadsheets, to passwords. Users are always oblivious to what they might have left stored in the pasteboard. Sensitive data may reside unnoticed in the pasteboard for an extended period of time, making it vulnerable to such exploits. 

Abuse of content in the pasteboard is not only restricted to read access, an app can maliciously alter the content of the pasteboard. For example, a malicious app can alter the image properties of photos in the pasteboard to make it look as though it was taken by a particular non-Apple device. Malicious apps can bond together and add some specific data to the metadata of an image that they only understand, i.e. communicating by the general pasteboard. A malicious app could detect the presence of an IBAN bank information in the pasteboard, it can quietly replace it with some other IBAN, hoping that the user makes a bank transfer to that IBAN. Malicious scenarios are countless.

With the introduction of the Universal Clipboard some years ago, a malicious app can also read data from macOS pasteboard, expanding the reach of the app and opening a new horizon of endless malicious scenarios. 


The pasteboard in iOS and iPadOS offers a convenient method to share content between different apps. Users are often oblivious to the fact that content stored in the pasteboard is not only accessible to apps they intend to share data with, but to all installed apps. As demonstrated in this article, this false assumption opens doors to a series of malicious practices that seriously compromise users’ personal data. We developed KlipboardSpy to demonstrate a scenario that malicious apps can exploit to gain access to precise user location information simply by reading the GPS properties of a photo left in the pasteboard. As the pasteboard is designed to store all types of data, the exploit is not only restricted to leaking location information. By gathering all these types of content, a malicious app can covertly build a rich profile for each user, and what it can do with this content is limitless.


The photos featured in the demo videos of KlipboardSpy are courtesy of Dr. Christian Knirsch

Media Coverage

This article was well-received in social media and has been covered by several tech websites. The following list provides links to the coverage: