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.
> 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.
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.
A stop gap solution is to add an api for “secure copy” that 1Password and the like can implement which makes it unreadable without a user initiated paste. This would take far less time to implement from Apple’s side.
It's weird that apps can straight read from the clipboard at all. I would think the OS just hands the app a pointer to the data and maybe some meta data for type.
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?
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.
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.
I think this is largely a business model thing - because your phone is virtually always on your person, it is a very rich source of information useful for advertising. Because of that, there are more apps that build their business model around harnessing that kind of data on your phone than on your pc. The ones on your pc that do this are mostly websites, not installed software - if your browser allowed that kind of access, you'd probably see a ton of websites abusing it in the same way as mobile apps.
I think it's partially because we're taught to treat "Apps" like candy, and "Applications" like something a bit... well... more?
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.
Windows itself can do this. Win+V will now will up clipboard history.
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.
Many of today's apps are user-hostile. Most of those apps, on desktop, end up taking the form of a website. Web browsers have much stricter policies than desktop OSes; much more akin to mobile OSes. The desktop app model was designed with the assumption that you 100% trust everything you install.
> 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.
Not at all, hence the move into UWP and for those that insist in staying with Win32, they get their sandbox as well since introduction of MSIX.
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.
This is one reason why KeepAss (at least on linux) can use xdotool for writing passwords. You can of course use the clipboard too but the app warns that it is not safe.
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.)
A few years ago, Pasteboard was a popular way of how advertising SDKs communicated between their own instances in different apps on iOS. It allowed those SDKs to determine which apps were installed on the phone and combine/mine user profile data across apps. Meaning: if you entered a social login in one app, others immediately got your demographic data.
But don't you have to update the paste contents, and then wait for the other process to read them and update the paste contents to tell the original process that the message was received?
"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."
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.
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...
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!
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.
This is one of the few ways SDKs can enable e.g. diagnostic modes without extra integration work by the app developer, but as is often the case there's a fine line between "convenient hack" and "gaping security hole".
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.
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."
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.
I'm very surprised Apple doesn't enforce the reverse-DNS nature of these IDs and allow all sorts of jumbled strings, let alone not verifying that your in fact own the domain.
> 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).
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...
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...)
> 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.
The permissions can be unidrectional, e.g. password manager grants permission to a specific app for the next N seconds. Similar to "add photo" permission.
The OS could provide a whitelisting API and an "app picker" to the user. The password manager app itself need not know the destination app, the OS could manage the binding. The password manager could invoke an OS API to create each association, with user-OS input for app selection. This whitelist approach would be similar to SE Linux or other mandatory access control systems.
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.
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.
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.
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.
1. Upon opening, app for service XYZ sees your clipboard has the URL www.xyz.com/whatever and offers to navigate to that link within the app, saving the user from having to find it again in the app or paste the URL in the search bar (if there is a search bar).
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.
Google Maps does this (at least on iOS), and it's actually pretty convenient. As soon as I click on the search bar, I can immediately click on my copied text to go there without doing the "tap and hold" dance.
That exists on iPadOS, but not on iOS. It's a lot less useful for anything which doesn't require a keyboard though, for example "long tap to paste an image/custom app object"
Convenience. Apollo for iOS (a reddit client) pops a "Open reddit link?" if you have a reddit url on your pasteboard. There are obviously other ways to solve this (e.g. allow pasting them into the navigation bar) but they're ever so slightly less convenient. IMHO it ultimately depends on the app / the developer. As for Apollo I trust the dev enough to not abuse it and only checking for reddit url to potentially navigate to. Others, e.g. TikTok, I wouldn't
I guess what if the app needs to implement an "enhanced" paste that's different from the system default paste functionality?
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.
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.
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.
Which isn't foolproof. I just tried to change my Apple ID password[1], and the password manager will only auto-fill the password field, not the verify password field, even if you invoke it with the cursor in the verify field. The only option is to copy and paste the password (or manually copy a 64 character password).
[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).
This doesn’t work everywhere; there’s been more than one occasion that I’ve had to copy/paste a password out of Settings because the system hasn’t detected a password field or gives me incorrect suggestions.
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.
Not efficiently. There's no "clipboard changed" notification on macOS.
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.
That would be cool, if true. It was not clear to me from the documentation that this number is guaranteed to increment whenever the contents change.
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.
Never seen a general purpose utility for this, but some apps clean up their own content. For example, 1password copies your 2FA codes automatically to the clipboard when you log in and then clears them out after a few seconds.
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)
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...
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.
There are arguments for “legitamate uses” of RATs and rootkits.
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.
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...)
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.
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.
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.?
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.