Sueball locked, loaded and pointed at LinkedIn over iOS privacy naughtiness
- Reference: 1594648569
- News link: https://www.theregister.co.uk/2020/07/13/linkedin_lawsuit/
- Source link:
A putative class-action lawsuit
[1]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 Universal Clipboard, which can also briefly contain data from nearby Mac devices.As well as doubtless making the podcast app a bit worse (as it seems to do with every release), the [2]upcoming version of Apple's mobile OS also features a bunch of privacy features, including a notification telling the user when an app is reading from the device's clipboard.
Those brave enough to take the beta of [3]iOS 14 out for a spin now receive notifications when the clipboard is accessed and have found that some apps – allegedly including LinkedIn's – have been reading from the clipboard without the user triggering a paste command.
The clipboard could contain all manner of private information (the lawsuit suggested cryptographic keys or medical data) as users hop from app to app "and LinkedIn was surreptitiously reading it – again and again and again – without any user-triggered paste commands, and without even notifying the user."
The suit from New York-based Bauer claimed the alleged behaviour violated federal and state law. The legal eagles are looking for class-action status thanks to the millions of users potentially affected.
LinkedIn has tried to head things off before the filing. Its VP of engineering, Erran Berger, [4]insisted that the app didn't store or transmit the clipboard contents, and the code merely did "an equality check between the clipboard contents and the currently typed content in a text box."
Berger went on to tell worried users that the company had submitted a new version of its app that removed the offending code.
Of the lawsuit, LinkedIn spokesperson Dan Miller told The Register : "We are aware and reviewing."
Regardless of whether Bauer's action proceeds or achieves class-action status, the arrival of iOS's additional privacy notifications will give developers pause for thought when it comes to what their apps (or the components upon which their apps depend) are doing.
A careless bit of code looking at things it shouldn't without a nod from the user could attract the unwanted – and expensive – attention of the legal system. ®
Get our [5]Tech Resources
[1] https://regmedia.co.uk/2020/07/13/linkedinpdf.pdf
[2] https://www.theregister.com/2020/06/27/apple_dns_macos_ios/
[3] https://www.theregister.com/2020/06/27/apple_dns_macos_ios/
[4] https://mobile.twitter.com/eberger45/status/1278843576638570496
[5] https://whitepapers.theregister.com/
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.
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.
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.
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.
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!
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.
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!!)
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.
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?
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?
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.
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?
I know not of these matters...
Is there a valid reason for one to perform such "equality checks"?