Hacker News Reader

Comment by gentleman11 | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com