> 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...)
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.
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"
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.
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.
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
> 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...
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.
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.
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...
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.
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...
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.
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?
> 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 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.
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.
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.
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.
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.
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.
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 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.
> 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.
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.
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.
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.
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).
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.?
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.
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.
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.
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.
106 comments
[ 5.4 ms ] story [ 179 ms ] threadRecent 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.
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.
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.
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.
"Your clipboard contains a link to a $localnewspaper article, do you want to open it?"
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...
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!
1: https://news.ycombinator.com/item?id=21439953
> ...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.
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.
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.
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."
[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).
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: https://www.xda-developers.com/android-q-blocks-background-c...
Now you'd never know if the app buffers until a convenient time but a less sophisticated implementation would be instant giveaway.