Did you know that Apple has a shared clipboard across all connected devices?

That means you can copy some text from your Mac and paste it into an app on your iPhone.

Or you can copy an image from your iPad and paste it onto your desktop on your Mac.

Or an app on your iPhone can read the contents of your clipboard whenever it wants.

Wait, what was the last one?

That’s right. Just as you the user can access the shared clipboard (Apple calls it the pasteboard) from any connected device, apps on iOS and iPadOS also have this unrestricted access. And as of iOS 13.3, there are no required app permissions for them to do so.

In this post, we’ll go over the benefits of the pasteboard as well as the security and performance ramifications of this type of access.

Benefits

First things first, as a user the shared clipboard is a great productivity tool. You can copy text, images or data on one device and then paste that on any other device in the vicinity that you are also logged into. Try it yourself by selecting some text from this article on your Mac, then on your iPhone notice that you can now paste that text – that’s a pretty cool feature!

People often toggle between devices throughout the day, and this functionality enables a more seamless transitioning between tasks and devices.

It’s also easy for mobile developers to enable this functionality.

NSLog(@"clipboard = %@", [UIPasteboard generalPasteboard].string);

Above is the code to read the clipboard in an iOS application. You can see it doesn’t take much to add this to your application. It uses UIKit’s UIPasteboard object. For more information, you can check out Apple’s documentation.

So what’s the problem?  Users think this is cool and it’s very easy to add – what’s the big deal?

Security

Any feature that involves unrestricted access to data is going to have security implications. As an example, if our app reads a block of text from the pasteboard, how do we know that text was meant to be seen by us?

What if the last thing the user copied was their master password?  A private email?  Private company data?

If we’re going to access this data, we have to treat it like any other piece of un-sanitized user input. Instead of reading or logging arbitrarily, do some basic validation first: Is the string a url or not? Are the characters all numbers?  If you perform basic validation as to what you expect to find on the clipboard, then you will throw out most invalid cases to begin with.  An attacker can put any data they want on the clipboard, so don’t leave your application vulnerable by not validating it.

Performance

While it seems like magic to the user, this shared clipboard is achieved via standard networking calls. The API is too simple though — we ask for a string and we get the value synchronously.

But what if the device was recently awoken and hasn’t fully connected to the associated Mac yet?

This call blocks, sometimes for seconds at a time, while a connection is established.  If you access this on the main thread as part of your launch process it is contributing to slow launch times for your users.  Consider wrapping the API in asynchronous accessor methods that can run on a background thread instead.

Summing it all up

Apple’s shared clipboard provides many benefits to users and application developers. But even the most innocent and simple APIs can have significant consequences for our applications. Always test and use an analytics SDK to keep track of how your application is performing in the field.

Who we are

Embrace is a data driven toolset to help mobile engineers build better experiences. If you’d like to learn more about Embrace, you can check out our website or request a demo.