Popular iPhone and iPad Apps Snooping on the Pasteboard
mysk.blog
mysk.blog
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.
I fully expect apps to try to leak information bit-by-bit to the greatest possible extent.
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?
Obviously the Windows APIs are far older and are from a time when there wasn't the same concept of untrusted code.
Also, people do tend to install more random software on their phones than their desktops and laptops in my experience. Someone will install a funny Chinese app in the pub based on a recommendation from a friend. They wouldn't do that to their desktop system.
I had no idea it existed initially, but until i disabled it there was a nice easy-access list of all of my recently used passwords. I assume other programs can't access that. But I don't want Microsoft syncing all my clipboard history to the cloud. No thanks.
At some level, I think this means that the expectation is that I should just, on a whim, download and play with an App. But when it comes to Applications, I should do my homework. Plus, Apple's already done my homework for me amiright /s.
This is of course completely backwards, since the App Store doesn't let me try before I buy, while Applications (as I'm trying to use the term) exist on platforms with less hostile restrictions.
---
It's also partially because we're becoming more sensitive to these issues as society, and most people use their phones a lot more than their computers, honestly.
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.
One of the ways Tor users are being identified is by snooping on their pasteboards from collaborating apps.
On the upcoming Windows 10X, each Win32 gets their own little world, as the next step since Microsoft decided to merge UWP and Win32 sandboxing concepts.
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.)
I assumed Apple plugged this hole by now :/
No.
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!
> ...we included just because...
Bob from marketing is the one who asked for the integration.
> We should talk to Bob from marketing to make sure...
Bob has no clue about this stuff.
We're not asking Bob what the SDK is doing, we're telling him. And any other decision makers in the vicinity.
Then we see whether the decision about the SDK changes. If not, we have to make our own personal ethical decision about what to work on.
Obviously this sort of thing needs super-explicit user opt-in and needs to be secured sufficiently that it can't leak private data, and it's possible/likely that a lot of SDKs aren't great about this.
For example, if the clipboard contained “FPS” when started, an FPS counter would be shown in game.
Note: this was a long time ago, there are better methods now.
Off topic. I can't imagine how did they shipped this app with this BundleId.
"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."
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).
This kind of inter-app policy could also be useful for opening URLs, e.g. open all URLs from untrusted app A in Brave browser where Javascript can be easily whitelisted on a per-site basis.
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...)
I think this is pretty standard. KeePass makes it immediately obvious as it has a bar on the bottom of the window that starts a 12-second decrement when you copy a password.
"Your clipboard contains a link to a $localnewspaper article, do you want to open it?"
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.
Most apps could probably live happily with there being an entitlement for ‘unsecured clipboard access’ to enable anything but text into a text field.
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.
Complicated buffer access would require an "allow" dialog.
I am probably oversimplifying things.
2. When using 2FA, 1Password will automatically write your one time code to the clipboard so it can easily be pasted. As a convenience, after 45 seconds or so it restores your previous clipboard contents for you. To do this it has to be able to read them.
3. An OCR app has a "OCR from clipboard" button to extract text from the image currently in the clipboard.
- Apps can and should let the user paste it themselves. (Examples #1 and #3 offer only slight convenience at the cost of user privacy and security.)
I believe the photo picker has had a similar evolution. In the early days of iPhone OS apps used the system-default photo picker, and nowadays it's for apps to use that in favor of reimplementing.
Some apps do little UX tricks like a parcel tracker app that I have would prompt saving a new parcel if it detects a tracking number in the clipboard.
Same as the last one; one of my banking apps detect IBAN numbers in clipboard, offer to initiate a wire directly.
Now you'd never know if the app buffers until a convenient time but a less sophisticated implementation would be instant giveaway.
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.
[1] I'm fairly sure I've copy-and-pasted my Apple ID password recently - I had to reauthorise my Apple ID (I think I was changing payment details), and there was no option to use the password manager (might be pre-iOS 13, so I'm not sure if that's still the case).
I just looked on iOS, it’s got an option to “clear clipboard” which says “Clears any item copied from 1Password to the clipboard after 90 seconds”
I notice that occasionally, but it seems to be a reasonable compromise of security over annoyingness, in the absence of proper access controls to the clipboard contents...
Such a utility would have to run in the background and constantly query the clipboard. And since the clipboard basically holds a list of types and a way to ask the owning application for data, you'd have to keep waking up the clipboard owner, too, to ask it for data. Would you check every type it declares? Some applications support dozens of types.
You would not need to constantly wake up the clipboard owner. To “clear” the clipboard you just upload a new clipboard with an empty string.
The value is described as counting "pasteboard ownership changes", and its use is to "determine whether you still have ownership". -clearContents doesn't say anything about necessarily changing it if you were already the owner, though that does seem to be the behavior today.
I suppose this could be one of those cases where we can go by what it actually does, not just what the documentation says it does. I hate doing that, because it has a way of coming back to bite me.
Im not convinced the convenience of not needing to paste into your dictionary app is a sufficient counter argument to the potential bad uses of completely unrestricted clipboard access...
Recent versions of Chrome show a prompt when websites do this in javascript.
Yep, and here is the spec for others who might be wondering about how it works:
https://developers.google.com/web/updates/2018/03/clipboarda...
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...)
Chrome does ship with a Google Docs "app" that lets the site access the clipboard for right-click pasting.
1: https://www.xda-developers.com/android-q-blocks-background-c...