It’s a pasteboard. That’s what the iOS sdk calls it and always has.
UIPasteboard | Apple Developer Documentation
An object that helps a user share data from one place to another within your app, and from your app to other apps.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Popular iPhone and iPad Apps Reportedly 'Snooping' on Pasteboard Data
- Thread starter MacRumors
- Start date
- Sort by reaction score
oh great, yet another popup dialog coming in the future.
jokes aside, although there's really nothing new here in terms of how the clipboard works, it does present a security issue in the way apps talk to one another, as well as what people these days copy and paste.
personally, i think the best solution is one that apple already implements for apple pay. on a touch id device, the user needs to physically rest their thumb on the touch id sensor. on a face id device, you have to double click the side button. In both of these instances, the user must physically do something before a payment goes through.
this same paradigm should be used for the clipboard. i'm not saying that the clipboard should necessarily protected behind face id/touch id though I wouldn't be against that. But my point is that anything in the clipboard should be hidden from an app until the user physically taps the "paste" button.
jokes aside, although there's really nothing new here in terms of how the clipboard works, it does present a security issue in the way apps talk to one another, as well as what people these days copy and paste.
personally, i think the best solution is one that apple already implements for apple pay. on a touch id device, the user needs to physically rest their thumb on the touch id sensor. on a face id device, you have to double click the side button. In both of these instances, the user must physically do something before a payment goes through.
this same paradigm should be used for the clipboard. i'm not saying that the clipboard should necessarily protected behind face id/touch id though I wouldn't be against that. But my point is that anything in the clipboard should be hidden from an app until the user physically taps the "paste" button.
Apple simply needs to add a "Collects NO User Data" checkbox to submitted apps & app updates, & if (later) found to be in violation, Apple pulls ALL apps from the App Dev for THREE years !
That would put an IMMEDIATE end to it !
And very importantly, the checkbox would need to be presented in the App Store for each app.
That would put an IMMEDIATE end to it !
And very importantly, the checkbox would need to be presented in the App Store for each app.
IME are keyboard apps. Just stick to stock keyboard app.
Focus app restriction is to be prevent abuse by apps with background refresh, widgets (as demonstrated in video on iOS/iPadOS), etc. from accessing the clipboard when not actively in use.
Fallback is to disable clipboard access altogether for specific apps via ADB. Perhaps make this part of apps permissions since the underlying controls are already in place.
As soon as you switched to an app in Android 10, that app can read clipboard - which basically makes it the same as iOS (Google restricted access to clipboard from background apps, which are basically not a concern on iOS).
It’s not user-initiated, is the problem.
Yeah, I'm well aware of your 1st and 2nd points? Lol.
Disabling via ADB is hardly a suitable solution for a general user.
They could easily make it as a permission, but, if apps can only access the clipboard when they are in focus, why pester the user with prompts?
There's a lot more fine grained permissions in android accessible via ADB that are not exposed to the UI - I would imagine that is entirely on purpose so you don't end up with prompts left, right and centre.
Ok, I’m no code wizard...
But the code shown in the article seems to be calling to have “local access” to clipboard content ONLY.
Sooooo, wouldn’t that only be ready in case the user selects “paste”, not shunted off device, in the clutches of the 3rd party app creator, as the article seems to intimate?
But the code shown in the article seems to be calling to have “local access” to clipboard content ONLY.
Sooooo, wouldn’t that only be ready in case the user selects “paste”, not shunted off device, in the clutches of the 3rd party app creator, as the article seems to intimate?
What I'm about to say is more about macOS than iOS/iPadOS, but - if you code, having a blanket rule to "clear the clipboard every N seconds" would be annoying.
I'd rather see at least the option for more granular permissions, where the user is asked (on demand) "should application X be allowed access to clipboard output from application Y?" The user interaction would be high at first, but would taper down pretty quickly. And, off the top of my head, I can't see any reason an application shouldn't have carte blanche access to clipboard contents it itself has placed there.
No, when any app reads the pasteboard, the app has access to whatever data was in the pasteboard. It’s not locked to the device in any way. It can be shipped wherever the app developer wants (subject only to legal limitations and limitations imposed by the developer agreement).
Apple. Come in and do your thing.
Hold their dev licence and pull the app until they grovel.
These companies need a strike system. You did this stuff twice. You’re banned for life. One warning.
Hold their dev licence and pull the app until they grovel.
These companies need a strike system. You did this stuff twice. You’re banned for life. One warning.
I've been suspecting this abuse. Apple and apps like 1Password will act soon, I hope. I never trust Chinese apps and apps from marketing-based-revenue companies.
And just to be abundantly clear, Universal Clipboard works locally between devices, not over any internet connection. It uses Wi-Fi in the same sense that AirDrop does.
I know that this is what the original research article claims but I would make a (small) bet that it's not true. I don't know how Universal Clipboard is implemented but I can make a guess based on the following observations:
Scenario 1:
When you copy some text on an iPhone and tap paste, the copied text appears practically instantly.
Scenario 2:
When you copy some text on a Mac, wait a while and then tap paste on a nearby iPhone, nothing happens at first and after a while the copied text appears.
How is it possible that the iPhone in the 2nd scenario does not immediately paste its local clipboard like it does in the 1st scenario? The Mac must have notified the iPhone about the availability of Universal Clipboard data. Then, why does it take a while for the text to appear in the 2nd scenario? After all, the text appears immediately in the 1st scenario. The text must not have been sent from the Mac to the iPhone by the time paste was tapped.
I would wager that the text is never sent between devices unless user explicitly pastes within the small time window that Universal Clipboard is operational. Also, I would wager that applications are not able to make a request for the remote Universal Clipboard data by themselves.
It’s nearly impossible for any app that connects to a server to “collect no user data.” Servers produce access logs that generally include IP addresses, and this information can be valuable for investigation and resolution in case of abuse. Moreover, it’s inherently impossible for any app that requires a user account to “collect no user data” because creating an account requires the user to provide some sort of information for authentication.
So, that rules out…nearly all apps.
Damn I have friends who I exchange PH links with at home and then I also have apps I use for work. Lol. Oh well. 🤷♂️
Nah, it shouldn't be user facing. I believe Clipboard already has a notion of what it contains, whether it's an image or text, for example... just add another object type, "Sensitive" or something like that, and the OS should recognize if the thing being passed into it is ordinary text or sensitive text (IE, because it's a password field.)
If an app is trying to access sensitive text, have a pop up dialog that requires a user to grant access to the sensitive text.
===
Do we know if the apps themselves are trying to access this data, or if it's coming from a common library that they're all using?
I'm just having a play around with my iPhone and console - quite a few apps seem to request the pasteboard, but none of them seem to read any of it, except PayPal, which read it's own pasteboard:
I'm not seeing any 'reading' of any other data...
7JMU3EK8QX is requesting item 0 of type public.utf8-plain-text from pasteboard named com.paypal.dyson.linker_id with UUID 8E586D5C-251C-4795-8281-A9A6699F796AI'm not seeing any 'reading' of any other data...
This is a terrible security oversight by Apple. I always use clipboard to paste my wife's password into my keychain from iMessage, which I use to send the password from her Mac to mine and vice versa. Since Apple doesn't allow family members to share keychains, entering each other's passwords into our respective keychains is the only way to be able to access each other's accounts. So, if I have universal clipboard enabled, a password copied into my Mac's keychain will be visible to my iPhone, and some rogue iOS app can read my wife's unbreakable password generated by the macOS keychain access application.
Just this alone should shave $50 off the AAPL share price. I never expected this degree of security negligence from Apple.
Just this alone should shave $50 off the AAPL share price. I never expected this degree of security negligence from Apple.
You'd be correct, I've just proved that in copying something on my Mac and pasting it on my iPhone.
What it actually seems to do is when you copy from the Mac it sends a notification that there's something in the pasteboard.
The iPhone gets that notification then it puts the paste into a file in the iPhone cache, and changes the pasteboard contents to have a reference to a UUID, which is also saved into a manifest.plist.
Apps which request the pasteboard on focus (Huffpost being one) aren't able to read that data as they only request the local pasteboard, and that data is classed as a remote pasteboard by iOS and treated differently.
When you actually paste, iOS does something like this:
Loading item 0x102d0b4a0 CDD61DBF-8690-436D-B013-ABB8E755611B type public.utf8-plain-text from URL file:///var/mobile/Library/Caches/com.apple.Pasteboard/eb77e5f8f043896faf63b5041f0fbd121db984dd/223a6ef20f728c65d9df23f0019103e7a4e95c78Quite interesting.
[automerge]1584306869[/automerge]
The only thing is - you're entirely wrong, it seems to be the local pasteboard only which can be read. Universal clipboard (or continuity pasteboard) seems to be safe from leakage, as it's treated differently. See my previous post.
Last edited:
