iOS 14 Clipboard Data Theft Panic: The Dilemma of Privacy and Convenience

Why do so many iOS apps read your clipboard?

$Photo by [Clint Patterson](https://unsplash.com/@cbpsc1?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText){:target="_blank"}$

Photo by Clint Patterson

⚠️ 2022/07/22 Update: iOS 16 Upcoming Changes

Starting from iOS ≥ 16, if the user does not actively perform a paste action, a prompt will appear when an app attempts to read the clipboard. The user must click allow for the app to access the clipboard information.

$[UIPasteBoard’s privacy change in iOS 16](https://sarunw.com/posts/uipasteboard-privacy-change-ios16/){:target="_blank"}$

UIPasteBoard’s privacy change in iOS 16

Issue

Top prompt message when the clipboard is read by an app

Starting from iOS 14, users are notified when an app reads their clipboard. This has caused significant privacy concerns, especially with apps from China, which already have a notorious reputation. The media has amplified these concerns, leading to widespread panic. However, it’s not just Chinese apps; many apps from the US, Taiwan, Japan, and around the world have been found to read the clipboard. So why do so many apps need to read the clipboard?

Google Search

Security

The clipboard may contain personal information or even passwords, such as those copied from password managers like 1Password or LastPass. Apps that can read the clipboard can potentially send this information back to their servers, depending on the developer’s integrity. To investigate, one can use man-in-the-middle sniffing to monitor the data being sent back to the app’s servers to see if it includes clipboard information.

Background

The Clipboard API has been available since iOS 3 in 2009. It wasn’t until iOS 14 that a prompt was added to notify users. Over the past decade, malicious apps could have already collected enough data.

Why

Why do so many apps, both domestic and international, read the clipboard when opened?

First, let’s define the situation: I’m referring to “when the app is opened”, not when the app is actively being used. Reading the clipboard during app usage is more related to app functionality, such as Google Maps automatically pasting a copied address. However, some apps may continuously steal clipboard information.

“A kitchen knife can be used to cut vegetables or to kill, depending on what the person using it intends to do.”

The main reason the APP reads the clipboard when opened is to enhance the user experience through “ iOS Deferred Deep Link “, as shown in the process above. When a product offers both a web version and an APP, we prefer users to install the APP (as it has higher engagement). Therefore, when users browse the web version, they are guided to download the APP. We hope that after downloading and opening the APP, it will automatically open the page where the user left off on the web.

EX: When I browse the PxHome mobile web version on Safari -> see a product I like and want to buy -> PxHome wants to direct traffic to the APP -> download the APP -> open the APP -> display the product I saw on the web.

If we don’t do this, users can only 1. Go back to the web and click again, or 2. Search for the product again in the APP. Both options increase the difficulty and hesitation time for users to make a purchase, which might result in them not buying at all!

From an operational perspective, knowing the source of successful installations is very helpful for marketing and advertising budget allocation.

Why use the clipboard? Are there any alternatives?

This is a cat-and-mouse game because Apple does not want developers to have a way to track user sources. Before iOS 9, the method was to store information in web cookies and read them after the APP was installed. After iOS 10, Apple blocked this method. With no other options, everyone resorted to the final technique — “using the clipboard to transmit information.” iOS 14 introduced a new feature that alerts users, making developers awkward.

Another method is using Branch.io to record user profiles (IP, phone information) and then match the information. This is theoretically feasible but requires a lot of manpower (involving backend, database, APP) to research and implement, and it may result in misjudgments or collisions.

*Android Google supports this feature natively, without the need for such workarounds.

Affected APPs

Many APP developers may not know they also have clipboard privacy issues because Google’s Firebase Dynamic Links service uses the same principle:

  
// Reason for this string to ensure that only FDL links, copied to clipboard by AppPreview Page
// JavaScript code, are recognized and used in copy-unique-match process. If user copied FDL to
// clipboard by himself, that link must not be used in copy-unique-match process.
// This constant must be kept in sync with constant in the server version at
// durabledeeplink/click/ios/click_page.js

Therefore, any APP using Google’s Firebase Dynamic Links service may have clipboard privacy issues!

Personal Opinion

There are security issues, but it boils down to trust. Trust that developers are doing the right thing. If developers want to do evil, there are more effective ways, such as stealing credit card information or recording real passwords.

The purpose of the alert is to let users notice when the clipboard is being read. If it’s unreasonable, be cautious!

Reader Questions

Q: “TikTok responded that accessing the clipboard is to detect spam behavior.” Is this statement correct?

A: I personally think it’s just an excuse to appease public opinion. TikTok means “to prevent users from copying and pasting ad messages everywhere.” But this can be done when the message is completed or sent, without constantly monitoring the user’s clipboard information. Do they also need to manage if the clipboard has ads or “sensitive” information? I haven’t pasted and published it yet.

What Developers Can Do

If you don’t have a spare device to upgrade to iOS 14 for testing, you can download XCode 12 from Apple and test it using the simulator.

Everything is still very new. If you are using Firebase, you can refer to Firebase-iOS-SDK/Issue #5893 and update to the latest SDK.

If you are implementing DeepLink yourself, you can refer to the modifications in Firebase-iOS-SDK #PR 5905:

Swift:

  
if #available(iOS 10.0, *) {
  if (UIPasteboard.general.hasURLs) {
      //UIPasteboard.general.string
  }
} else {
  //UIPasteboard.general.string
}

Objective-C:

  
if (@available(iOS 10.0, *)) {
    if ([[UIPasteboard generalPasteboard] hasURLs]) {
      //[UIPasteboard generalPasteboard].string;
    }
  } else {
    //[UIPasteboard generalPasteboard].string;
  }
  return pasteboardContents;
}

First, check if the clipboard content is a URL (in line with the content copied by web JavaScript being a URL with parameters). If it is, then read it, so the clipboard won’t be read every time the app is opened.

Currently, this is the only way. The prompt will still appear, but it will be more focused.

Additionally, Apple has introduced a new API: DetectPattern to help developers more accurately determine if the clipboard information is what we need, then read it and prompt, making users feel more secure while developers can continue to use this feature.

DetectPattern is still in Beta and can only be implemented using Objective-C.

Or…

Switch to Branch.io
Implement the principle of Branch.io yourself
The app first shows a customized alert to inform the user before reading the clipboard (to reassure the user)
Add new privacy terms
iOS 14’s latest App Clips? Web -> Guide to App Clips for lightweight use -> Deep operation guide to the app

iOS 14 Clipboard Data Theft Panic: The Dilemma of Privacy and Convenience