I know not of these matters...
Is there a valid reason for one to perform such "equality checks"?
Microsoft's social-media-for-suits tentacle, LinkedIn, has attracted legal fire for allegedly peering at the clipboard of iOS devices. A putative class-action lawsuit [PDF], filed on Friday by Adam Bauer in the US District Court for Northern California, has claimed that LinkedIn's iPhone and iPad apps peered at Apple's …
"Is there a valid reason for one to perform such "equality checks"?"
First, no privacy is violated unless the data is moved from the application to some other place, without the user intending it. These lawyers will have a very, very hard time proving this - mostly because it is very unlikely to happen. I will happily write code that does exactly what LinkedIn is being sued for, and have done so in the past - but if my manager or employer asked me to write code that does this and violates people's privacy, then absolutely no.
And yes, there are plenty of _good_ reasons to examine the clipboard. First, in iOS 14 (and everywhere else) it is absolutely required if you want to implement "Paste" into anything other than text views and text fields. Second, you want to know what's in there so you don't have for example a "Paste" button if there is stuff that you can't paste.
And then there's the fact that in Windows, Linux, MacOS, Android, and iOS up to 13.0, everyone does it. For good reasons.
I think most of your statements are wrong there. We'll start with the first one. You can violate privacy without immediately sending the contents of the clipboard off. As a basic example, if you copied it into an internal buffer and used it to perform on-device metrics, even if you never sent those metrics, it could be violating the privacy of data stored in the clipboard. Sure, it's relatively low-level and users should be careful (that is assuming this app only did this while in the foreground), but don't assume that violating privacy requires phoning home. In this case, I don't think LinkedIn was using this as a sneaky data collection feature because it would be so fragile. I think it's more likely that some coder thought it would be useful and didn't think of alternatives or the downsides.
Now on to the code part. You say that checking the clipboard content "is absolutely required if you want to implement "Paste" into anything other than text views and text fields." Not true, because you still only have to read from the clipboard when a user presses that button. The issue here is checking the content in a loop without any button. Then, you said that "you want to know what's in there so you don't have for example a "Paste" button if there is stuff that you can't paste." I disagree, because I find hiding controls that you sometimes have and sometimes don't confuses the users, but that's a subjective UX thing. You can implement format-specific paste in a number of ways, including cancelling a paste operation without changing the original content if the contents are not compatible. You can warn the user or not as you desire.
"And then there's the fact that in Windows, Linux, MacOS, Android, and iOS up to 13.0, everyone does it. For good reasons."
You are assuming the reasons are good. Frequently, I find that good programs wait for me to paste in the contents of my clipboard rather than snatching potentially incorrect data out, though I will admit I've seen some go the other way.
Unless you really need real-time monitoring of clipboard contents for some reason, you are also making your application do a lot of pointless busy looping. This isn't great for performance or power usage if you do it for long enough.
Although I use LinkedIn for business, the App is installed on a personal phone. The App does not and has never had permission to access the contacts on my personal phone, yet it is regularly suggesting I might want to connect with contacts only on that phone who I have nothing to do with in my business life.
LinkedIn has been trying for years to get me to allow it to access email and contacts so it can go and mine my data for the benefit of its owners. Not going to happen.
As a matter of fact, I have deliberately abstained from putting my professional life up at LinkedIn exactly because my business is privacy, and I have in some cases even a legal obligation to be very careful with the data I hold. Letting a 3rd party access that is quite simply not going to happen - it's also why I absolutely refuse to use WhatsApp and other asocial media apps.
.. then people will use it
I thought a big selling point of the Apple walled garden was that it is locked dowm & apps are prevented from doing naughty stuff without user OK?
.. Not an Apple user, but its my perception of what I would expect if I purchased one - sacrificing some freedom / control for better security (hopefully!!)
iOS 14 includes something that will let you know if an application has read the clipboard. Not sure if it will let you control each access or not.
It also puts up little dots in the notification area if the application is accessing the camera or the microphone (each of which do require permission) so you can tell if something you've given permission to listen/watch is doing so at times when it should not or you do not expect it.
It also lets you limit access not just to the photo roll, but to a particular photo from the photo roll, should an app that you give permission so it can upload one photo decide to help itself to all of them. Not sure if they did that because an app was discovered doing so, or just being extra cautious.
They do improve on the privacy in new ways every rev, because developers keep coming up with new ways to act shitty.
"I thought a big selling point of the Apple walled garden was that it is locked dowm & apps are prevented from doing naughty stuff without user OK?"
It is, and I can see Apple closing this loophole permanently, very soon.
It seems like initiating the paste functionality will have to move completely out of any app's responsibility in the future.
It does seem to me that they got this new version out remarkably quickly. Almost as though they had done some testing of the new OS to see what it would show up and were poised to see if anyone was going to complain.
Well, it's not as simple as that because you may not always use the standard edit controls. In an app that implements a different edit box with different features, say for an actual word processor, you may want to be able to paste into your new area. Apple saw this need and implemented your basic clipboard where you could read at any time. Logically, they could easily have asked the user about whether the app was intended to be reading the clipboard, implemented rate limits, or various other security patches, but they didn't do that. Maybe their IOS 14 changes will include one or more of those preventative patches in addition to the retroactive warning mentioned.
Yes while I don't use it much since I prefer DDG I have noticed in the last few months the google search app will show an option "from clipboard" among the search options if I have recently copied something but not pasted it elsewhere. If that's what you wanted to search on you can just click there and save a second over doing regular paste and hitting search.
The fact it doesn't show that if what was copied has been pasted elsewhere is interesting. I'm not sure if the app still has access to it but knows it has already been pasted so it isn't likely to be what you want to search on, or once it has been pasted it is no longer accessible to the app.
I made an Android app that reads the clipboard on startup without asking. It does it to see if the clipboard contents is a URL, in which case it pre-populates a text field with that URL. I could have added an extra Paste button, but then I'd have to worry about issues like "would the button take up too much room on small displays" (or if it's hidden, would users be able to find it), and "would users be confused if pressing the button causes an error message because the clipboard contents is not something we can handle—would it be better to simply not offer the option in that case". So I decided (rightly or wrongly) that reading the clipboard without asking would be the least-bad thing to do by default.
But my app is Free/Libre and Open Source Software. If you don't trust me, you can read the source code (or trust that others will have read it and called me out already if necessary). To make really sure, you can compile it yourself and verify that the bytecode you get is the same as the bytecode on the Play Store version (if you use the exact same compiler version and options as I did).
Unfortunately for LinkedIn, they have so far not been brave enough to show the source code of their app, so it's not as easy for them to use the "just read the code" defence. (Perhaps they'll now invite lawyers to look at it behind closed doors, but publishing it could have saved that trouble.) LinkedIn has open-sourced some minor components, but not the app itself. I don't know the business reasons for that decision, but it seems clear to have this PR disadvantage at least.
That said, the iOS ecosystem itself isn't exactly helping. It doesn't make it at all easy to verify that what you get from the App Store is the same as what you can compile from source code, plus its incompatibility with certain licenses (along with the general high financial cost of being an Apple developer) seems to have resulted in an environment somewhat devoid of Free/Libre and Open Source Software (so iOS users are missing out on some of the best software). But in LinkedIn's case I have not been able to find their published source code for the Android app either, sorry to say.
"I made an Android app that reads the clipboard on startup without asking. It does it to see if the clipboard contents is a URL, in which case it pre-populates a text field with that URL"
That's your choice, but I think it's not that useful for a few reasons.
"I could have added an extra Paste button, but then I'd have to worry about issues like "would the button take up too much room on small displays" (or if it's hidden, would users be able to find it)"
This is why consistent UI decisions across apps are so useful. In most operating systems, there is a typical way to copy and paste and any app supporting those actions does it the same way. If your paste function was available and followed a convention, most users would know how to use it.
"and "would users be confused if pressing the button causes an error message because the clipboard contents is not something we can handle—would it be better to simply not offer the option in that case?"
As I see it, this is a nonissue. If the clipboard contents are not text, you just don't paste any contents into the box. If it is text, you put it in when they paste and let the user decide what to do then. After all, you already have to have some control for a user entering an invalid URL, either a typo or testing you, so if the clipboard contents are invalid, you just report them as invalid just like you would if I mistyped the URL as "https;\\".
These are subjective decisions, and everyone will probably have their own opinion on what is best. For what it's worth, mine and yours differ.
Biting the hand that feeds IT © 1998–2021