back to article Sueball locked, loaded and pointed at LinkedIn over iOS privacy naughtiness

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 …

  1. Olafthemighty

    I know not of these matters...

    Is there a valid reason for one to perform such "equality checks"?

    1. gnasher729 Silver badge

      Re: I know not of these matters...

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

      1. doublelayer Silver badge

        Re: I know not of these matters...

        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.

  2. Steve Davies 3 Silver badge

    Little chance of this going anywhere

    but down the toilet. Against Microsoft's army of lawyers his team will get tied up in a legal minefield that will last years and years.

    That's if it gets that far and a court throws it out at the first hurdle.

  3. Anonymous Coward
    Anonymous Coward

    Interesting

    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.

    1. UCAP

      Re: Interesting

      While I use LInkedIn, I flat refuse to allow its app on my phone. My assumption was that LinkedIn would try to scrape any information it could about me, with or without my permission. Unfortunately it seems that I was right!

      1. bpfh

        Re: Interesting

        Same. And I wish there was a way on mobile (iOS) to stop the prompt to download the mobile app Every. Single. Time...

    2. IGotOut Silver badge

      Re: Interesting

      You do know how Social Mmedia works?

      You can lock it down as much as you want on YOUR phone, but if most of the other morons say yes to defaults, they (social media co) have your associates details.

    3. Anonymous Coward
      Anonymous Coward

      Re: Interesting

      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.

  4. tiggity Silver badge

    iif clipboard read allowed without user OK

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

    1. katrinab Silver badge
      Meh

      Re: iif clipboard read allowed without user OK

      It is certainly better than Android in that respect, but without an operating system that is even more locked-down than OpenBSD, it is difficult to completely stop these things.

      1. Sanctimonious Prick
        Trollface

        Re: iif clipboard read allowed without user OK

        Yes... umm... my next phone upgrade is likely to have a fruity flavour. I could be swayed; depends on what Nokia and WhooHoo do over the next 12 months or so?

    2. DS999

      Re: iif clipboard read allowed without user OK

      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.

      1. Anonymous Coward
        Anonymous Coward

        photos

        Pretty sure that if you allow the FB app access to the gallery to upload a photo, it will look at all of them. I've certainly seen some behaviour on my phone that suggests that is the case.

        1. DS999

          Re: photos

          iOS 14 changes that so you can limit its access to a single photo instead of the entire roll.

    3. anonymous boring coward Silver badge

      Re: iif clipboard read allowed without user OK

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

  5. heyrick Silver badge

    had submitted a new version of its app that removed the offending code

    Oh bollocks.

    You've removed the offending bit of code that you just got caught out on. Given that you seemed to think it's perfectly fine to snoop on the clipboard, what else are you snooping on?

    1. Kevin Johnston

      Re: had submitted a new version of its app that removed the offending code

      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.

      1. heyrick Silver badge
        Happy

        Re: had submitted a new version of its app that removed the offending code

        Or maybe just:

        #define SNOOP_ON_LUSER 0

        (until they roll out an update in a couple of weeks with the other code back in place)

  6. Nifty Silver badge

    I'm baffled

    I'd expect IOS to be fully in charge of the clipboard. Only at the moment you paste does the currently open app gain 'access' to the clipboard contents due to you holding down a finger for a second or so. Was it really ever otherwise?

    1. doublelayer Silver badge

      Re: I'm baffled

      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.

      1. DS999

        Re: I'm baffled

        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.

  7. Silas S. Brown

    Free/Libre and Open Source advantage

    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.

    1. doublelayer Silver badge

      Re: Free/Libre and Open Source advantage

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

  8. anonymous boring coward Silver badge

    I told LinkedIn to stop fecking nagging me. But it just won't stop.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021