9 ms·

Popular iPhone and iPad Apps Snooping on the Pasteboard

220 points by clairity 7y ago

diebeforei485 7y ago
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.
- deadmutex 7y ago
  > 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/clipboardapi#security_and_permissions https://developers.google.com/web/updates/2018/03/clipboarda...
- bigiain 7y ago
  > 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 7y ago
    Well, I mean... Chrome does ship with a Google Docs "app" that lets the site access the clipboard for right-click pasting.
acwan93 7y ago
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.
- ThePowerOfFuet 7y ago
  And that's fine — but it still empowers people who do care.
- _bxg1 7y ago
  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?
  - acwan93 7y ago
    Exactly. Obscuring the pasteboard or something along those lines is unfortunately the solution.
  - shoyer 7y ago
    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.
    - _bxg1 7y ago
      Maybe the iOS keyboard itself needs a "just tap" paste button? That would seem generally-useful.
      - hutattedonmyarm 7y ago
        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"
  - jws 7y ago
    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 7y ago
> 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 7y ago
  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 7y ago
    Should be a permission.
    - toyg 7y ago
      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...
      - walterbell 7y ago
        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.
        saagarjha 7y ago
        How would the password manager know which app you’re going to paste the password into?
lazyjones 7y ago
Is there a MacOS utility that clears the pasteboard N minutes after its last content change?
- andrekandre 7y ago
  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)
  - bigiain 7y ago
    1Password does this as well. 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...
  - xenadu02 7y ago
    Having a "password" pasteboard might not be a bad idea. Disallow reading its contents except by built-in system password input fields.
    - saagarjha 7y ago
      Of course, this only solves the problem for passwords.
    - tinus_hn 7y ago
      Unfortunately the number one use case is the browser which doesn’t use these.
- ken 7y ago
  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.
stereo 7y ago
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 7y ago
  The Deliveries app offers this with tracking numbers and it's very helpful
FreakyT 7y ago
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.
- bigiain 7y ago
  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...
- _-___________-_ 7y ago
  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.
wool_gather 7y ago
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.)
- izacus 7y ago
  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. I assumed Apple plugged this hole by now :/
  - cortesoft 7y ago
    Would that mess up things users actually copied?
    - saagarjha 7y ago
      You can read the pasteboard without messing it up, and then replace the contents back to what they used to be.
      - cortesoft 7y ago
        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?
roflchoppa2 7y ago
yikes, so many passwords getting snooped on if you copy them to the clipboard
banana_giraffe 7y ago
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?
- chrisseaton 7y ago
  > 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.
  - kjaftaedi 7y ago
    Webpages have been able to read your clipboard for decades without prompting you and was only taken seriously recently.
- kennywinker 7y ago
  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.
- snailmailman 7y ago
  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.
kennywinker 7y ago
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.
- jcampbell1 7y ago
  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.
  - keanebean86 7y ago
    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.
    - dwaite 7y ago
      It gives you a list of alternative content types and an API to get content - but pasting is an app-controlled activity, not an OS one.
- saagarjha 7y ago
  > 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.
woobar 7y ago
Accuweather — com.yourcompany.TestWithCustomTabs Off topic. I can't imagine how did they shipped this app with this BundleId.
- Marsymars 7y ago
  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 7y ago
    I get this for a scrappy startup trying to move fast. But this app (pretty decent, btw) is 10+ years old.
    - wool_gather 7y ago
      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.
- kccqzy 7y ago
  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.
greenice 7y ago
What are the security implications for password managers here - not copy/pasting any passwords?
- dhosek 7y ago
  iOS has a system-level interface for password managers so that the passwords are accessed without using the pasteboard.
  - dwighttk 7y ago
    when that works... pretty sure the fallback is to copy/paste, unless copy/paste from password manager apps also bypasses the clipboard
    - bigiain 7y ago
      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.
  - saagarjha 7y ago
    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.
  - stordoff 7y ago
    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).
forkexec 7y ago
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.?
dingo_bat 7y ago
What's a pasteboard? Are we talking about the clipboard?
npunt 7y ago
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.
nreece 7y ago
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 7y ago
  Android recently [1] blocked app background access to the clipboard. 1: https://www.xda-developers.com/android-q-blocks-background-clipboard-access/ https://www.xda-developers.com/android-q-blocks-background-c...
  - veeti 7y ago
    This is about apps snooping in the foreground, which is still possible in Android. I don't think iOS offers background access at all.
surround 7y ago
IIRC Apple syncs (or can sync) your clipboard data to the cloud, which is an issue if you’re copying passwords.
- saagarjha 7y ago
  Password apps should enable this option to disable the behavior: https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/1829412-localonly https://developer.apple.com/documentation/uikit/uipasteboard...
- pvg 7y ago
  It doesn't, the data is copied device to device.
saagarjha 7y ago
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.
Too 7y ago
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.
soulchild37 7y ago
If the app is free, you are the product. Who knew?
0x0 7y ago
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.
fortunajs 7y ago
Hey Apple - it's simple as creating yet another permission to read/write the clipboard. How many iOS versions before that happens?

220 points by clairity 7y ago

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.

deadmutex 7y ago
> 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/clipboardapi#security_and_permissions https://developers.google.com/web/updates/2018/03/clipboarda...
bigiain 7y ago
> 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 7y ago
  Well, I mean... Chrome does ship with a Google Docs "app" that lets the site access the clipboard for right-click pasting.

acwan93 7y ago

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.

ThePowerOfFuet 7y ago
And that's fine — but it still empowers people who do care.
_bxg1 7y ago
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?
- acwan93 7y ago
  Exactly. Obscuring the pasteboard or something along those lines is unfortunately the solution.
- shoyer 7y ago
  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.
  - _bxg1 7y ago
    Maybe the iOS keyboard itself needs a "just tap" paste button? That would seem generally-useful.
    - hutattedonmyarm 7y ago
      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"
- jws 7y ago
  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 7y ago

> 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 7y ago
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 7y ago
  Should be a permission.
  - toyg 7y ago
    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...
    - walterbell 7y ago
      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.
      - saagarjha 7y ago
        How would the password manager know which app you’re going to paste the password into?

lazyjones 7y ago

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

andrekandre 7y ago
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)
- bigiain 7y ago
  1Password does this as well. 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...
- xenadu02 7y ago
  Having a "password" pasteboard might not be a bad idea. Disallow reading its contents except by built-in system password input fields.
  - saagarjha 7y ago
    Of course, this only solves the problem for passwords.
  - tinus_hn 7y ago
    Unfortunately the number one use case is the browser which doesn’t use these.
ken 7y ago
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.

stereo 7y ago

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 7y ago
The Deliveries app offers this with tracking numbers and it's very helpful

FreakyT 7y ago

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.

bigiain 7y ago
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...
_-___________-_ 7y ago
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.

wool_gather 7y ago

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.)

izacus 7y ago
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. I assumed Apple plugged this hole by now :/
- cortesoft 7y ago
  Would that mess up things users actually copied?
  - saagarjha 7y ago
    You can read the pasteboard without messing it up, and then replace the contents back to what they used to be.
    - cortesoft 7y ago
      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?

roflchoppa2 7y ago

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

banana_giraffe 7y ago

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?

chrisseaton 7y ago
> 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.
- kjaftaedi 7y ago
  Webpages have been able to read your clipboard for decades without prompting you and was only taken seriously recently.
kennywinker 7y ago
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.
snailmailman 7y ago
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.

kennywinker 7y ago

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.

jcampbell1 7y ago
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.
- keanebean86 7y ago
  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.
  - dwaite 7y ago
    It gives you a list of alternative content types and an API to get content - but pasting is an app-controlled activity, not an OS one.
saagarjha 7y ago
> 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.

woobar 7y ago

Accuweather — com.yourcompany.TestWithCustomTabs Off topic. I can't imagine how did they shipped this app with this BundleId.

Marsymars 7y ago
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 7y ago
  I get this for a scrappy startup trying to move fast. But this app (pretty decent, btw) is 10+ years old.
  - wool_gather 7y ago
    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.
kccqzy 7y ago
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.

greenice 7y ago

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

dhosek 7y ago
iOS has a system-level interface for password managers so that the passwords are accessed without using the pasteboard.
- dwighttk 7y ago
  when that works... pretty sure the fallback is to copy/paste, unless copy/paste from password manager apps also bypasses the clipboard
  - bigiain 7y ago
    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.
- saagarjha 7y ago
  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.
- stordoff 7y ago
  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).

forkexec 7y ago

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.?

dingo_bat 7y ago

What's a pasteboard? Are we talking about the clipboard?

npunt 7y ago

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.

nreece 7y ago

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 7y ago
Android recently [1] blocked app background access to the clipboard. 1: https://www.xda-developers.com/android-q-blocks-background-clipboard-access/ https://www.xda-developers.com/android-q-blocks-background-c...
- veeti 7y ago
  This is about apps snooping in the foreground, which is still possible in Android. I don't think iOS offers background access at all.

surround 7y ago

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

saagarjha 7y ago
Password apps should enable this option to disable the behavior: https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/1829412-localonly https://developer.apple.com/documentation/uikit/uipasteboard...
pvg 7y ago
It doesn't, the data is copied device to device.

saagarjha 7y ago

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.

Too 7y ago

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.

soulchild37 7y ago

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

0x0 7y ago

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.

fortunajs 7y ago

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