LinkedIn sued over allegation it secretly reads Apple users' clipboard content | Hacker News Reader

LinkedIn sued over allegation it secretly reads Apple users' clipboard content

reuters.com

142 pointskitotik89 comments

People seem pretty upset about their clipboards, I wonder if apple/google will listen and make the reading of your clipboard something that you must get explicit user permission for (similar to your camera). IMO this is how almost every possibly permission should be and I think most users would agree with me that having 2 seconds of inconvenience when you first setup the app is worth the peace of mind gained.

it should be split into "local clipboard" and "global clipboard" so that you still have copy paste within the program but paste outside the program require privilege

there's plenty Android sketch/mind mapping apps for example that require access to storage, for saving and exchanging media, and the is doesn't allow for "allow access to some folder without giving them access to everything" and it's annoying

most permissions actually should have that kind of don't allow global access without breaking the app functionality or even telling the app itself

BlackBerry Work (for iOS and Android) can work with solely the clipboard inside the app

There's no problem if I manually copy some text from a box in one app and paste it into another app, and I don't want a permission prompt for that. It's programmatic access that I care about (apps snooping clipboard content).

Technically they could probably be implemented the same way and the "manual" action is actually just granting the programmatic permission to the keyboard app.

The copy and paste button in all apps is programmatic. Windows can't tell the difference, for example, if a user copied from edit > copy or if the website did it itself.

It could work if windows had a copy paste api with levels of access and trusted the apps to honor the access level. Then the browser could tell windows if a user clicked paste or if a website did.

I argue that the clipboard shouldn’t be given any extra levels of trust because it’s current level of trust, very low, is the correct amount.

Precisely! It's the rough equivalent of a tempfile in your home directory, I don't know why even developers have come to view it like it's some super secure and private kernel component.

That's all well and good, unless you're an attorney, author, document writer, research scientist, or literally anybody who types a lot...

At jobs I've literally copy PHI all over the place for data processing.

Copy and paste is vital and often top secret.

It’s a bad shaped tool for that problem. It’s a shared resource. There is a gaping hazard where any other piece of software can change the data you want to read before you can read it. Use a database.

If it were that simple there wouldn't be employees.

I don’t mean look up a database. I mean make a database. Write a program that skims the document, parses what’s needed, and places it into a locally running database. Then, in another program, read the values you need. The clipboard is simply the wrong tool here. A database is bog standard.

How do you write documents?

What other tool provides same order of magnitude convenience for moving data verbatim between contexts? "Share" on mobile covers some use cases, but even then, you can't open a discrete password manager app and share your password directly to the password field in your browser.

Windows on the desktop is a completely different can of worms. For example, I installed a small application last week to take screenshots of my entire screen every so many seconds and it was then that I realized the whole installation process (there is no installation process, just a simple executable with a config file in the same directory) and execution required zero root privilege.

Technically, any application (at least any application that lives in the system tray) can take screenshots of the whole screen as often as it likes. You can probably imagine it doesn't even need to store it on disk. It could just do some quick computation and send it to whoever.

This. There are plenty of situations where I'd be happy with allowing an app to store its own internal data and maybe export local backups but I don't want to give permission to enumerate and read everything on the file system. Heck, I'm using Bouncer to remove permissions after I move away from apps. I fail to understand why more granular permissions haven't been a priority.

I'd even accept a step during OS initialization, when it could ask something like: "how much do you care about various apps being able to read your clipboard?"

1. I care a lot: I want to be asked every single time whether I approve of my clipboard getting read.

2. I care a moderate amount: ask me the first time an app tries it, then stop asking me for a while.

3. I don't care: let apps do whatever they want. I'll let other people worry about my security.

(albeit phrased more diplomatically, of course)

That’s what UAC tried. Didn’t work that well in practice.

It should just work the way that every user assumes it works: apps can’t read it at all, but the user can explicitly paste from it

Right? On what planet should an app be allowed to read or write to the clipboard? The only piece of software that should access the clipboard is the keyboard, and even that I have trouble trusting with all of these predictive services. I’d like to feel more confident that my most used device isn’t loaded up with keyloggers.

Write to clipboard makes sense for "click to copy" functionality. It's a small ergonomic improvement but doesn't seem like the same security risk as reading from the clipboard.

On Android, one of the suggestions when you focus the address bar in Chrome is the URL currently on your clipboard. That's tremendously useful. (It helps that pasting isn't especially ergonomic on Android.)

To be honest I hate that they have gimped the address bar on android chrome. Its just one more button press if i need to edit the url, and i think its creepy that they read the clipboard to be frank.

I replace the address more often than I edit it, so personally I like it. But yes, reception has certainly been mixed.

"paste and go"

> On what planet should an app be allowed to read or write to the clipboard?

This will be news to pretty much every clipboard implementation that exists, considering that they all rely on programmatic access.

Copying and pasting aren't magic opaque syscalls, they're things that programs implement (or rely on a common library to implement).

Well that should have been fixed years ago, but I would be happy if it was fixed in a way that broke legacy.

Many password managers would erase your clipboard content after you pasted your copied password once. Clipboard managers that retain history of your copied text are also useful, though I don't personally use them. Those are the only acceptable use of unrestricted read/write clipboard access in my opinion.

How can this be implemented? You can go with the javascript approach of "you can only read the clipboard contents during an user interaction", but there's nothing preventing the app from reading the clipboard every time you touch the the screen. A lot of sites use a similar exploit to bypass popup blockers. You could make so the user must accept an OS modal before the clipboard contents are released. It's more secure, but it's jarring and slows down the user.

I don't think it's jarring to use an OS modal, if that modal is the one that almost every app already uses: [1].

Perhaps this could be the default way of interacting with the clipboard, and then apps that want to be able to read it a different way (e.g. Google Chrome wanting to be able to offer you a "Go To Link You Copied" button) could request an additional permission.

[1]: https://cdn4syt-solveyourtech.netdna-ssl.com/wp-content/uplo...

That's not a modal, that's just a standard widget. I'm not sure how they're implemented in iOS, but they can be subject to clickjacking attacks.

The clipboard should be on the level of virtual keyboard. The app should not see whats in the clipboard before pasting. Don't see much of an issue with implementation.

How would that work with non-text applications? eg. a photo editor. Would the application need to bring up the keyboard just so the user can paste? Screen real estate is also an issue. Mobile keyboards are cramped as it is, adding a paste button would either require it being buried behind another layer, or take up more screen real estate.

It sounds like a problem of UI, i think it can be solved, you could hold some button to paste...

And in what format should the image be copied into the clipboard?

There should be no “reading the clipboard” at all. A “paste” should result in the OS providing the contents to the app, not signalling the app to read the clipboard.

Your solution of "only let the OS initiate pasting" only really works when dealing with os provided text editing widgets. What if an app wants to implement a paste button/gesture? eg. paste and go to url that chrome/safari has, or terminal emulators that paste on control-shift-v rather than control-v, or photo editors that don't really have a text box to "paste" to begin with.

Yes, these are hard problems, but I would prefer that they either be solved - or go without some features - rather than let every app be able to read the contents of my clipboard.

Hard problems sometimes (but not always) have simple solutions.

Putting apps copying clipboard up in your face is one such solution and it seems to be highlighting the abusers, no?

Even if an app has a genuine need to copy clipboard, having it in front of user every time will be useful.

I know those are probably just a few examples of many but:

Paste and go isn’t a feature worth sacrificing the privacy of your clipboard contents

Terminal emulators, not sure to be honest. Why not stick to traditional cut and paste shortcuts?

Photo editors: nobody said you need a text box to paste to. Set your UI element as “pasteable” or whatever’s needed and let the app handle whatever clipboard contents comes it’s way. If it’s not supported it gets ignored.

Have the browser (or OS) implement a clipboard. To paste, the middle-man software (either the OS or the browser) just inserts characters one after the other from this clipboard. Similarly, to insert text into it, make a request to this middle-man software. Not kernel level of course, but built in. If its windows, call it "clippy" and bring back that paperclip character.

I think the problem is that - currently - the rendering and behaviour of the edit menu (which contains cut/copy/paste) is done within the app's runtime etc.

So there's no difference between an app directly retrieving data from the pasteboard and you hitting the paste button. The message about the app retrieving from the pasteboard still appears if you hit the paste button.

It would likely need to be moved out to an IPC call to make this possible.

It's not just passwords.

Imagine if you were writing an email to a close friend, about looking for a new job because you think your boss is incompetent. You copy and paste it for some reason (reformatting, whatever).

You do not want that to be seen by a job network site that has you connected to your boss.

How about not letting them read the clipboard at all. They don't need it.

“ According to the complaint, LinkedIn has not only been spying on its users, it has been spying on their nearby computers and other devices”

Facebook’s SDK’s which are embedded in more than 30-40% of all Android apps also scan the users internal network and also uses Bluetooth looking for devices nearby.

I was shocked to discover that more than half of the third party apps I had installed had Facebook’s software embedded in them.

Is there a list of these somewhere? What are the steps needed to verify for myself? Exfiltration of data from my phone is theft; I prefer not to be stolen from.

So far I've found: Spotify Tinder Yelp Duolingo

I am a noob, so please correct if wrong. I think you can use the fdroid app 'ClassyShark3xodus' to scan apps installed and apks on your phone for trackers etc. https://f-droid.org/en/packages/com.oF2pks.classyshark3xodus...

That got me far enough to get started, thanks!

Previous discussion of the issue: https://news.ycombinator.com/item?id=23716451

Explanation from LinkedIn and the actual (open-sourced) code in question linked in the top comment: https://news.ycombinator.com/item?id=23719995

That explanation seems plausible to me, and would imply that there is no spying going on there.

> "According to the complaint, LinkedIn has not only been spying on its users, it has been spying on their nearby computers and other devices, and it has been circumventing Apple’s Universal Clipboard timeout."

That's the last paragraph, which probably should have been stated sooner. The timeout issue could be a mistake, but if not it seems to support the spying theory.

Does the lawsuit have any merit?

I can't think of any laws that would ban applications from accessing information as provided by the operating system.

What functionality would be broken if clipboards were changed to be completely unreadable other than when the user initiates a “paste” command manually?

Password managers. Auto fill forms.

Can’t think of anything else

why do password managers need to _read_ the clipboard? It seems they would only need to _write_ to it.

I see two behaviors in 1Password

1) I go to a site and it auto fills the login. Not sure when clipboard needs to be involved there. Shouldn’t that just be the application taking data from its database, recognizing the associated form, and filling it?

2) I search for a login manually and copy to clipboard. In that case I’d only ever want it to paste when I issue a paste command manually

in my experience, to "restore" clipboard contents after a certain period of time;

- read clipboard

- write password into clipboard

- restore clipboard after X seconds

There’s no reason this couldn’t be a platform-provided function though - a clipboard “stack” would be rather useful anyway.

They read the clipboard if they autofill.

Why?

To copy what's in the clipboard (hence read access) and then paste it into the destination input

Still doesn't make sense. It sounds like this is a "hack" to implement some functionality which exposes users' private data. What SHOULD happen is that vendors should expose better APIs which allow the password managers to do what they need to do without exposing the users' data.

For example, if the implemented functionality is attempting to make a "temporarily store password in clipboard" feature and implementing it by "reading from clipboard/writing to clipboard/restore clipboard contents after N seconds", there should instead be an atomic "store data in clipboard temporarily" feature.

Chrome on Android shows any URL on the clipboard as a suggestion when focusing the address bar. It's a marginal but quite noticably improvement in user experience.

All copying and pasting relating functionality would be broken, because clipboards literally function by granting programmatic access to applications.

"The user initiates a paste command manually" is a requirement that may be trivial for a human to express but near impossible for software to implement.

> "The user initiates a paste command manually" is a requirement that may be trivial for a human to express but near impossible for software to implement.

What? No.

Sure, there would be changes required, but both Android and iOS could support this pretty easily IMO.

How do you imagine that copying and pasting works on Android and iOS at the moment?

"There would be changes required" is a very euphemistic way to phrase what would basically be banning all apps that don't use the high-level views in the OS SDK from having clipboard functionality. Funnily enough, if Apple were to come out tomorrow and say "we're removing the ability to cut, copy and paste from any and all apps that don't use UIKit" this website would have a field day tearing them to shreds and smugly posting about "walled gardens".

Convenience, freedom, security. Pick two.

Well hello all the passwords that are safely copied from the password manager.

Checking the clipboard for relevant patterns and possibly enabling user actions is not the same thing as stealing your clipboard. Consider the Apollo reddit app:

https://www.reddit.com/r/apple/comments/hejb9i/ios14_catches...

Then these should be permissioned separately, the patterns perhaps available for inspection

I’m wondering if a dependency common to these apps is the thing reading the clipboard.

Pretty evil so my guess is the Facebook sdk...

Well, it's not rare. A lot of apps have sort of feature, search while inputing, to search before user completing spelling. And some apps go further to search and show what people copy from other place, because they thought user may want that. I think its original idea is to bring convienience to user, not to inspect privacy data. But this seems to end now.

Yeah, please just use mobile websites instead of apps whereever possible.

So, do we need to redefine the term “sandbox” as it relates to secure software? Obvi, it doesn’t do what we’ve been told it was supposed to do. Apple uses the term about 600 times per keynote, but we now know it’s been lip service. They either lied or just did a shitty job securing iOS. However, “sandbox” doesn’t necessarily imply secure; that would be a “secure sandbox,” in which case we were all naive, heard “sandbox,” and assumed it was secure, which by default and definition, it isn’t.

...just imagine how many passwords must have leaked like this. Or is there some kind of 'limitation' when accessing clipboard data copied from password managers?

Some password managers have a feature to automatically clear the clipboard contents 30 seconds after copying a password. But I have only seen this on Android, Windows and macOS. Not on any iOS apps, likely due to tougher restrictions on executing in the background.

Yea, 1Password on iOS also clears the clipboard after 90 seconds.

To me the real problem is that so many people don't actually understand how clipboards work. If they did, they wouldn't have this (in my opinion) strange trust in their security in the first place.

As a developer and as a user: don't put things in the general/system clipboard if they're truly sensitive/secret. Developers especially really should be promoting the use of named and/or private clipboards (and of the share sheet in Android and iOS).

And drag and drop

We can start to address the problem that many people don't understand how much information get slurped by different programs in order to be shipped and sold to data miners and advertisers. Once their trust in the majority of the software industry is lost we can then go and address the ways that those companies deploy in order to extract data.

How am I supposed to use a password manager if I can't copy paste?

"How am I supposed to use a password manager if I can't put my plaintext password in a file that everyone can access?"

Like I have already said,

>> Developers especially really should be promoting the use of named and/or private clipboards (and of the share sheet in Android and iOS).

And for the specific case of a password manager, iOS offers Password Autofill integrations. It's not the OS's fault if developers are too lazy to use the right tools for the right job.

iOS does not offer auto fill for third party password managers and there is no unified service that Apple offers for web and desktop and works across OS and multiple browsers . So it is less to with developer laziness and more to do with lack of usability beyond iOS

> iOS does not offer auto fill for third party password managers

Yes, it does - see the section very literally titled "Integrate a Password Management App with Password AutoFill" at https://developer.apple.com/documentation/security/password_....

But again, many devs don't actually keep up with and/or look up the proper way to do things on the platform they're deploying on.

> and there is no unified service that Apple offers for web and desktop and works across OS and multiple browsers

Apple has a duty to its own software. Why exactly is the onus on Apple to offer a magical grand unified service instead of on third party software developers to actually take the time to study and use the appropriate tools on each platform they want to deploy on?

If you want things to be secure you generally have to put in the work for it. 1Password spends resources building & maintaining browser extensions to integrate directly with input fields - why doesn't your password manager of choice offer similar? As a developer one could use named and/or private clipboards to actually have control over when and how the data their users clip is accessed - why not do that over complaining that a shared, global buffer that applications can access programmatically by design is, while convenient, also not exactly the most secure way to transmit sensitive data?

My hope is that stories like this help to educate non technical users about what a clipboard is and does. That in turn might result in improved clipboard privacy.

This is very weird, I notice a lot of apps are doing this.

Even Firefox Focus, considered to be a "privacy-focused" browser, has this notification pop up every time you add a character to their address/search bar.

shitty company that uses dark patterns[0]

[0]https://twitter.com/darkpatterns

Awesome!

While LinkedIn is sketchy, this is a modern iteration of ambulance chasing lawsuits.

If it improves privacy by making the cost of acquiring a user’s information higher then that’s a very good thing .

You can also say that ambulance chasers improve public safety by making errors more costly.

This isn't about privacy. It's a money grab by lawyers.

Reply on news.ycombinator.com