
Popular iPhone and iPad Apps Snooping on the Pasteboard - clairity
https://www.mysk.blog/2020/03/10/popular-iphone-and-ipad-apps-snooping-on-the-pasteboard/
======
kennywinker
The pasteboard API is essentially the same in iOS as it is in macOS. Which
means it's an api that was likely designed more than 20 years ago. Because of
that, it was not designed for the user-hostile app world we live in, where
developers will harness any api that can leak data about the user.

A solution to this is to re-design this api so that it allows developers to
query for specific matches, but requires user-action to unlock them I.e. I can
passively ask "does the clipboard contain a photo?" or "does the clipboard
contain a url in the *.facebook.com domain?" but in order to get the contents
I have to prompt the user to manually paste. Probably this would require
putting these queries in the info plist, so that they can be validated by app
review and you don't get developers brute-forcing the contents with large
numbers of generated queries.

This is very similar to how apple solved apps detecting what other apps you
have installed using `-[UIApplication canOpenURL:]`. Apple added rate limiting
and an info-plist based whitelist, which essentially put a stop to this
practice.

~~~
saagarjha
> A solution to this is to re-design this api so that it allows developers to
> query for specific matches, but requires user-action to unlock them I.e. I
> can passively ask "does the clipboard contain a photo?" or "does the
> clipboard contain a url in the *.facebook.com domain?" but in order to get
> the contents I have to prompt the user to manually paste.

I fully expect apps to try to leak information bit-by-bit to the greatest
possible extent.

~~~
kennywinker
Addressed by the next bit in my post: force developers to list their queries
in the info plist. Only allow those queries. Validate that the query list is
not malicious during app review.

------
banana_giraffe
Something that confuses me:

Windows app can do this. Heck, in the case of a Windows app, you need not even
poll the clipboard, you can sign up for notifications when it changes. The API
is ancient, well documented, and provides no feedback when it's being used.
And some apps indeed use it, one obvious one is remote desktop apps use it to
"sniff" what's in the clipboard to mirror it along.

Is there a reason whatever security trade offs are OK in Windows, but not on a
phone?

~~~
lathiat
These security trade-offs are not really OK on desktop either, but Windows
(and macOS) have a long tail of backwards compatibility they are trying to
maintain and slowly steer towards similar security levels (as in the case of
the mac app store or the windows store platform). Both of those platforms are
struggling to do that although have made some incremental progress but nowhere
near the degree that iOS has.

iOS was designed very early on with heavy sandboxing and as a new platform
that was happy to break many of the norms of desktops. They have been very
successful in having a usable platform that is heavily sandboxed and closes
more of these snooping holes over time. Of course the trade-off has been
flexibility and it has taken them a long time to get where they are now and
have a usable OS and also have such sandboxing. (remember the first iPhone
didn't even have an app store!)

To some extent most applications moving to being web-based has won a lot of
this sandboxing on desktop that it wouldn't have otherwise had, and web apps
cannot read from the clipboard in modern browsers.

~~~
pjmlp
The Windows 10X sandboxing for Win32 is yet another step into that direction,
each application gets their own little world thinking that they still own the
PC, when in fact they are part of a Windows container.

------
wool_gather
I wouldn't be surprised if the apps _themselves_ were not directly responsible
here -- that is, the code that's written directly by the app developers.

Instead, it may very well be be some analytics/marketing SDK that has been
included in the app because of a business request. These have no privilege
separation: they run their code in the same context as the code that the app
developers wrote. (Consider the example of games with no text UI; unless
they're truly spying on their users, what would they get from doing this?)

I've said before, this SDK privacy hole is something we need to be very aware
of as engineers and push our product/marketing folks to recognize as well. I
would love to see Apple address it too. (On the other I have no idea _how_
they would.)

~~~
stefan_
"We shipped a trojan and code-signed it, but it's okay, it is some blob from a
vendor that we included just because. We should talk to Bob from marketing to
make sure it's not doing bad things."

No.

~~~
hamburglar
Ok, well, say "No" all you want but this totally happens, only the
perpetrators are not nearly so clue-ful as to realize they've shipped a
trojan. There are "helpful" SDKs out there whose ulterior purpose is to
collect user data without the app author's knowledge. This is one reason I'm
very wary about what apps I'll install... it's not enough to trust the app
author if they include 3rd party code.

~~~
bigiain
Pretty sure at least some of those are “helpful” in the sense of “this is one
of the ways we make money, by installing someone else’s sdk in our game and
getting paid for it, while not looking too carefully at what it’s doing to our
users”. And I’d be astounded if various Facebook/Google/Twitter SDKs
(including things like Fabric/Crashlytics and Google Analytics) haven’t done
this in the past even if they’re not doing it now. Surveillance capitalists
gonna surveil...

~~~
ryandrake
This comes up all the time on HN and I’m always shocked[1] at how
controversial an idea it is that the developer is responsible for knowing what
they are shipping in their dependencies. “Oh, woe, how can you audit all of
your dependencies and their dependencies and know what’s in them?? Oh it’s
impossible! There is no way to solve this!”

Too few devs are really careful about their dependencies and do good due
diligence when evaluating them for suitability. Everyone else is just “Hey our
problem is solved by this one. YOLO! Link it and ship it LOL!” I’ve seen
projects that link and ship binary dependencies without even being able to
inspect the source. This is, to me, totally insane. But standard practice in a
lot of places!

1:
[https://news.ycombinator.com/item?id=21439953](https://news.ycombinator.com/item?id=21439953)

~~~
bigiain
While I totally agree with what you say here, I think it goes deeper. Some
devs/shops are complicit in this, knowingly adding dependencies for shady
reasons.

------
woobar
Accuweather — com.yourcompany.TestWithCustomTabs

Off topic. I can't imagine how did they shipped this app with this BundleId.

~~~
Marsymars
Presumably it got developed as such, and it never got prioritized before
release.

"Okay we've finished all the must-haves just in time for our release deadline
but the name for our app in our code isn't really configured correctly."

"How long will it take to fix?"

"Maybe a week to update our CI environments and be confident that there aren't
any regressions related to dependencies on the thing that we're changing, but
we can also fix some other issues in parallel."

"What effect will changing it have?"

"Well it will conform with best practice and won't confuse future developers."

"What user-facing change will it have?"

"None."

"Nope, not worth delaying release by a week for."

~~~
woobar
I get this for a scrappy startup trying to move fast. But this app (pretty
decent, btw) is 10+ years old.

~~~
wool_gather
It's effectively impossible to fix this once it's been shipped, though. The
bundle ID is the fundamental identifier of the app to the whole system. If
they were to change it, they would end up with a completely separate app in
the app store. They would have no way (at least no way that's not nasty and
convoluted) to move user data from the old one to the new one.

------
_bxg1
> Apps on iOS and iPadOS have unrestricted access to the system-wide general
> pasteboard, also referred to as the clipboard.

Yikes. This is horrible, and really it's unacceptable given Apple's privacy
rhetoric. Even the web doesn't have this vulnerability. And it's easy to fix,
too! Why in the world should an app be able to see the clipboard? It should
only see the text I enter into its fields (via pasting or otherwise).

~~~
katsura
Browsers use it to help you with the copied links. When you click into the URL
bar they offer you to jump to the previously copied link right away.

~~~
aaomidi
Should be a permission.

~~~
toyg
I don’t disagree but the overflowing of permission prompts is how we get
people just clicking Yes to everything. There is a balance. Location services
are worth of a permission, but the clipboard seems a bit on the trivial side
of things. Then again, people paste passwords, so...

~~~
bigiain
> Then again, people paste passwords, so.

It’s more serious than that, current security best practice is telling
everybody to use a password manager. People are being told that pasting
passwords is “the right way to do things”. And that behaviour (at least for
me) has morphed into keeping account numbers, credit card numbers, and other
important private information in the password manager, and copy pasting those
when I need to.

(1Password on Mac seems to have a trick where it empties the clipboard after a
certain amount of time, I’ve noticed that occasionally when a password I’d
copied a little while ago isn’t still in the clipboard when I try to paste it.
I haven’t been quite curious enough to look into it. Yet...)

~~~
saagarjha
[https://developer.apple.com/documentation/uikit/uipasteboard...](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/1829414-expirationdate)

------
stereo
Some apps use this to offer to open an URL in the app.

"Your clipboard contains a link to a $localnewspaper article, do you want to
open it?"

~~~
dhritzkiv
The Deliveries app offers this with tracking numbers and it's very helpful

------
acwan93
I really hope we don’t start getting into a parade of dialogs going “X app
requests permission to use Y”.

I get why it’s important from a privacy-perspective, but most people aren’t
going to care. They’ll just mash the “Allow” button until they get what they
want.

~~~
_bxg1
I don't see why this even _needs_ a dialog. What legitimate reason is there
for an app to see my clipboard without me pasting anything?

~~~
jws
The app might be implementing the paste function. The most common use case of
copying and pasting text could probably be hidden inside the standard text
fields, but consider images, sounds, or custom data types. The app needs to
grab these off the clipboard and do something with them and will be triggering
the action from some custom user interface element. Even for text, a terminal
emulator or word processor is not going to be using a standard text field as
the target.

Most apps could probably live happily with there being an entitlement for
‘unsecured clipboard access’ to enable anything but text into a text field.

~~~
_bxg1
The OS could provide a dedicated button of its own for pasting images, etc. It
could be recognizable and standard and apps could embed it as needed.

The key is that apps shouldn't have silent, _arbitrary_ clipboard access. The
user should have to do an action for the clipboard's contents to be
transferred. The only way to prevent abuse is for a system-provided widget to
be the one making the actual API call.

Another option would be to provide apps an API call that opens a system "paste
dialog", asking the user, "Paste X into this app?". This would have the added
bonus of giving the user a preview of what they have in their clipboard before
actually performing the paste. It could even show a history of the last
several copied items in case they want to paste one of those instead, which
would be a genuine productivity-booster.

------
Too
Would be interesting to see this correlated with network logs to see if the
apps phone home or just process it locally.

Now you'd never know if the app buffers until a convenient time but a less
sophisticated implementation would be instant giveaway.

------
0x0
This was quite obvious for a short while after Apple introduced cross-device
pasteboards (handoff/continuity) - if your mac had recently copied something
into its pasteboard, and you opened the facebook app on your iphone, the
system would show a "Pasting from mac..." modal progress bar for a second even
with no user interaction.

------
npunt
Unfortunately because of the incentives that drive developer business, we have
to treat apps with minimal trust for anything potentially sensitive.
Clipboards often contain people's names, contact info, passwords, and personal
writing. Carte blanche access is something that reveals these and personally
I'm not comfortable with it.

There's obviously a balance to be struck with:

a) not introducing unnecessary permissions prompts, causing prompt fatigue in
users (thus lowering security)

b) improved UX by saving a step for apps that may use clipboards for
legitimate purposes (e.g. shipment tracking numbers, photos, emails, etc)

Here's how I'd solve the problem through improved App Store review:

1\. Carte blanche access to pasteboard is removed, replaced with system data
detectors, which delineate common data types like shipment tracking numbers,
photos, emails/contacts, plaintext, etc.

2\. During app submission, any request to access a specific pasteboard data
type has to be met with a UX justification, specifically that it has to
significantly improve the core user experience in a meaningful way, and
developers must promise to not scrape or store the data remotely.

3\. If justification is not approved, app may still be published. Routines
that call for access to data detector pasteboard must be able to gracefully
fall back to non-pasteboard access (since they are used solely for simplifying
a UX step).

4\. If it is discovered a developer breaks their promise, their app may be
pulled from the app store.

(optional) 5. When users get to the particular part of the app that uses
pasteboard data AND the current pasteboard data is of the data type that the
app has been approved to use, user is presented with a permission prompt to
allow it. The permission prompt should not just be boilerplate, it should show
the current contents of the pasteboard the app is trying to access.

The last step is a judgment call based on balance of permission prompt fatigue
and user trust. If its believed the app store submission process is believed
to be a good enough filtering process, then don't present prompts. One way to
approach is add the above 4 and see how developers respond, and if it seems
insufficient then add #5 in the next iOS release.

------
greenice
What are the security implications for password managers here - not
copy/pasting any passwords?

~~~
dhosek
iOS has a system-level interface for password managers so that the passwords
are accessed without using the pasteboard.

~~~
dwighttk
when that works... pretty sure the fallback is to copy/paste, unless
copy/paste from password manager apps also bypasses the clipboard

~~~
bigiain
Also, once you’ve got a password manager installed, it tends to get used for
more things than just passwords. iOS’s non clipboard password/login doesn’t
help me any when I’m copy pasting, say, my bank details from a secure note in
1Password.

------
lazyjones
Is there a MacOS utility that clears the pasteboard N minutes after its last
content change?

~~~
andrekandre
not sure, but i do seem to remember that passwords copied from the “passwords”
screen in system preferences get removed after a minute or so... so that
functionality seems to exist in some form... (if i am remembering correctly
that is)

~~~
xenadu02
Having a "password" pasteboard might not be a bad idea. Disallow reading its
contents except by built-in system password input fields.

~~~
saagarjha
Of course, this only solves the problem for passwords.

------
FreakyT
There are probably other legitimate uses of this, but one is
dictionary/translator apps. I can copy a word in Japanese, open my dictionary
app, and it will automatically open the entry for the clipboard contents
without my needing to take extra steps.

~~~
_-___________-_
This is a really tiny bit of convenience in return for allowing every app to
read whatever is on your clipboard whenever they like it.

------
diebeforei485
As web browsers have gotten more privacy-aware, native apps have fallen
behind. This is just another example of that.

Recent versions of Chrome show a prompt when websites do this in javascript.

~~~
bigiain
> Recent versions of Chrome show a prompt when websites do this in javascript.

Tin foil hat version: “ ... when website’s other then Google’s do this in
JavaScript”...

(It’s sad how much trust Goog have lost, at least with me. I don’t seriously
thing Goog would try to slip that behaviour into Chrome, but it’s close enough
to believable to make it a funny/not funny response...)

~~~
Dylan16807
Well, I mean...

Chrome does ship with a Google Docs "app" that lets the site access the
clipboard for right-click pasting.

------
saagarjha
One good way to find these apps is that they’ll often throw up a “Pasting…”
alert if you have clipboard sync enabled, as it tries to fetch your Mac’s
pasteboard contents.

------
nreece
If iOS apps are snooping on the pasteboard/clipboard, then surely many Android
apps are doing so too. It's worrisome specially when copy-pasting from
password managers. Not sure if 1Password, LastPass, Dashlane etc. offer any
protection.

~~~
ryandrake
Android recently [1] blocked app background access to the clipboard.

1: [https://www.xda-developers.com/android-q-blocks-
background-c...](https://www.xda-developers.com/android-q-blocks-background-
clipboard-access/)

~~~
veeti
This is about apps snooping in the foreground, which is still possible in
Android. I don't think iOS offers background access at all.

------
roflchoppa2
yikes, so many passwords getting snooped on if you copy them to the clipboard

------
fortunajs
Hey Apple - it's simple as creating yet another permission to read/write the
clipboard. How many iOS versions before that happens?

------
surround
IIRC Apple syncs (or _can_ sync) your clipboard data to the cloud, which is an
issue if you’re copying passwords.

~~~
saagarjha
Password apps should enable this option to disable the behavior:
[https://developer.apple.com/documentation/uikit/uipasteboard...](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/1829412-localonly)

------
forkexec
17Track does but only while starting the app and exiting the add tracking
number dialog. It doesn't appear to snoop in the background, but there's no
way to know for certain. Maybe clipboard access should be gated with a privacy
permission like position, contacts, camera, etc.?

------
soulchild37
If the app is free, you are the product. Who knew?

