Hacker News Reader

Comment by cassalian | Hacker News Reader

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.

View on HN

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.

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"

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

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.

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?

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.

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

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

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.

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.

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.

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.

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?

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.

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

Reply on news.ycombinator.com