Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the clipboard works

whynothugo.nl

Post reply on HN
Print view View original

141–150 of 160 posts

Re: How the clipboard works

#141

Post by zzo38computer »

enriquto wrote: post #18

No word about unix-style clipboard? Select to copy, middle-click to paste. If I had to highlight an immediate usability advantage of linux with respect to windows and macos, it would be clearly this thing. It feels "at home" when you can do this. Also, I have a viscerally strong disagreement with the following sentence: > The majority of the implementations out there are broken and only handle text. For me, one of th…

> Select to copy, middle-click to paste.

I also think that this is useful. Furthermore you can have separate selections: primary, secondary, and clipboard.

I use xterm, and shift+insert can also be used to paste from the primary selection. Firefox can copy to primary selection automatically and can paste by middle button, but shift+insert pastes from the clipboard instead; I think that it would be better for shift+insert to paste from primary selection and control+V (or command+V would be better; having that a separate key like Mac OS does is better, I think) for paste from clipboard.

Another thing that is helpful, but many modern programs do not do (some older programs do, such as Heirloom-mailx, and vi) that you can enter shell commands to be used by pipes to transfer data between programs (by use of popen function in C). (Some of my own programs have this capability)

Re: How the clipboard works

#142

Post by sam-s »

Why can't the server inherit the clipboard from the program being shut down?

(unless the program crashes, it should go through the "official motions" and one of them should be notifying the server which then can request the clipboard. this should be done early in the shutdown process, of course)

Re: How the clipboard works

#143

Post by masklinn »

GaryPalmer wrote: post #127
the_mitsuhiko wrote: post #14

This design has the really annoying situation that applications closing down can't leave stuff in the clipboard. This results in a quite a frustrating behavior for users and also makes command line tools tricky. wl-clipboard lets you pipe text into the command to copy. The way it works is that it daemonizes in the background to fulfill the copy request. It either cancels on the first paste (command) or until some oth…

I don't get it (Windows user). If I copy some text in the browser and then close the browser the clipboard is gone under linux? How is that good design, wouldn't it be preferable if the OS is holding the clipboard data as a middle man?

> I don't get it (Windows user). If I copy some text in the browser and then close the browser the clipboard is gone under linux? How is that good design, wouldn't it be preferable if the OS is holding the clipboard data as a middle man?

The essay covers this: it was picked because it means only the pasted data (of the right mimetype) gets copied, so it avoids unnecessary copies. This is especially useful if the source can generate large amounts of data e.g. an image program is able to copy in multiple image formats, in which case said program would have to export everything to the OS on copy.

But yes that also means all the data is lost unless the source program takes extra non-trivial measures to keep the data alive.

This made some sick kind of sense in X11, because all that data might have to transit over the network too if you were using remote X.

Re: How the clipboard works

#144

Post by imiric »

323 wrote: post #137
imiric wrote: post #125

Earlier quoted context omitted.

> If you have malicious software running on your system, all bets are off. I think that's a common and lazy response to many security issues. There are _many_ ways in which a nefarious script or program can run in a "secure" environment and wreak havoc. Think NodeJS or Python scripts, which are typically downloaded from untrusted sources and ran blindly by most people as their own (hopefully) unpriviliged user. > The…

> isn't securing this one major IMO attack vector an improvement over not doing anything about it Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants. This is why even on mobile as you noticed, only browsers require user confirmation before allowing webpages access to the clipboard. You could maybe do something in between, like not allowing clipboard…

> Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants.

You're making assumptions about what the implementation would be. There are many ways the UX could be unobtrusive. Besides, I'm not even proposing that the solution should be to restrict access to the clipboard. I'm just saying that there should be a secure channel between apps provided by the OS that can be used for these purposes. Designing and implementing that would be costly, sure, but I'm not an OS designer, and merely speaking what I would like to see as a user.

> But in practice, this attack vector is not exploited.

Of course it is[1]. It's not even an exploit, but an abuse of a glaringly insecure OS feature.

> If you are targeted, it's much more likely that a specific attack against the password manager is used

Again, why are you minimizing this clearly easy to abuse OS feature by comparing it to much more sophisticated exploits? Yes, there are other attack vectors. This thread is specifically about how the clipboard is trivially abused.

[1]: https://news.ycombinator.com/item?id=33330035

Re: How the clipboard works

#145

Post by enriquto »

anentropic wrote: post #116
enriquto wrote: post #39

Earlier quoted context omitted.

> Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary" This never happens if you only use the unix clipboard. I agree that both methods should point to the same clipboard, but this is an implementation detail. The important thing is the interface: selecting text copies it to the clipboard, middle-clicking pastes it.

So... selecting some text by accident clears what you previously had in the clipboard?

Well, of course; why would you want to keep the initial clipboard forever? This is exactly the same behavior as for ^C/^V. I don't understand the purpose of your question.

Re: How the clipboard works

#146

Post by imiric »

ziml77 wrote: post #77
alkonaut wrote: post #70

Earlier quoted context omitted.

Applications also have access to global desktop screen recording, which has similar security issues. Basically: the desktop including all user input, frame buffers etc. was created as a free-for-all with security as an afterthought. It's as if all processes run in the same memory space. I should be able to control which apps can read the screen outside of its own top level window, and be notified when it happens (jus…

macOS actually has these kinds of permissions. The clipboard is still a free-for-all though. I guess that's harder to lock down because it's more than just a simple option of fully allowing or denying access to the clipboard. You would want to be able to paste to any application even if that application can't read the clipboard whenever it wants, but you'd be adding an extra confirmation on every paste if a user does…

I think the solution can be quite simple: allow the user to configure secure channels between apps, sidestepping the main clipboard altogether. So that if e.g. a password manager is configured as source, and the browser as destination, have an option in the password manager to send a password directly to the browser. There would be no intermediary storage like the traditional clipboard, and no typing with a virtual keyboard, just apps communicating directly via a secure mechanism provided by the OS, and configured by the user.

This is already possible by using named pipes on Linux[1], but it has to be built specifically for each app, and anything can go wrong with the implementation. It seems like it would be relatively simple to have this functionality built into the OS.

[1]: https://news.ycombinator.com/item?id=33329561

Re: How the clipboard works

#147

Post by johannes1234321 »

Arrath wrote: post #119
johannes1234321 wrote: post #91

Earlier quoted context omitted.

You snapshot the data in your application's native data format, then you can convert it later to the best match for the consumer. Taking the Excel example form above: You got to store the cell layout and values. If it's pasted into a different excel sheet you pass that structure over. If it is pasted in a richt text editor it is converted to some richt text table format. If it is pasted to a plain text editor it is m…

And at any time during this process you can easily and readily lose the copy from Excel. God its so annoying to tab back to the sheet to hit Ctrl-C again.

True, but doing it "right" (especially considering 1990ies hardware) isn't easy. And Windows has the option, to just pass it to the system, if you don't have complex needs (only copying plain text etc.)

Re: How the clipboard works

#148

Post by db48x »

account42 wrote: post #102
db48x wrote: post #73

Earlier quoted context omitted.

This design dates back to X Windows (and probably before). It does indeed allow for various optimizations of that sort. A clipboard manager is simply a program that initiates a paste into it’s own window as soon as any other window announces that it has the selection. It then advertises itself as having the selection, so that the the user can ultimately paste the data wherever it should go. The clipboard manager can…

You'd expect the Wayland design to improve on that to allow clipboard managers to work 100% reliably and efficiently by only being able to take over the clipboard just before the previous owner closes - just like how Windows does it. Better yet would be to integrate that behavior into the server.

You don’t want to integrate it into the server, because that limits choice. There are a lot of features that you could put into a clipboard manager that not everyone would want, and you don’t want to force everyone to just have the least common denominator of those features.

For example, one commenter pointed out that he uses one that keeps a permanent database of everything he has ever copied. Maybe you want to sync your clipboard between computers, while I just want mine to keep the last 10 clipboards and throw away the rest. (Actually I use Emacs which has it’s own internal kill-ring, so I don’t use a clipboard manager.)

Re: How the clipboard works

#149

Post by 323 »

imiric wrote: post #144
323 wrote: post #137

Earlier quoted context omitted.

> isn't securing this one major IMO attack vector an improvement over not doing anything about it Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants. This is why even on mobile as you noticed, only browsers require user confirmation before allowing webpages access to the clipboard. You could maybe do something in between, like not allowing clipboard…

> Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants. You're making assumptions about what the implementation would be. There are many ways the UX could be unobtrusive. Besides, I'm not even proposing that the solution should be to restrict access to the clipboard. I'm just saying that there should be a secure channel between apps provided by the OS…

> Again, why are you minimizing this clearly easy to abuse OS feature by comparing it to much more sophisticated exploits

You need to think like an attacker. If you gained a foothold on a machine, maybe for a limited time, do you wait until the user happens to login to their banking site by copy pasting the password, or do you comb the machine for everything valuable - files, cookies, password manager databases, ...

If you are sniffing the clipboard you are actively malicious, but then you limit yourself to low gains?

Note that most of the trojans listed in your link are fully featured, sniffing the clipboard is one of the many attacks in their menu.

You are right that it is an attack vector, but it's not a particularly bad one. Microsoft did implement various restrictions which annoy the user, and did implement some protections against common attacks - ransomware file protection, but did nothing regarding the clipboard. Which means that in their cost/benefit analysis it did not stick out as a priority.

Re: How the clipboard works

#150

Post by occamrazor »

johannes1234321 wrote: post #91
alkonaut wrote: post #78

Earlier quoted context omitted.

I’m a windows desktop dev since the last millennium and tbh never knew that there was an announce api. It seems really difficult to use as a tiered solution where you only return the more complex data when asked. After all, you must then still snapshot that data from the moment the copy occurred to be able to provide a snapshot from the time of the copy later?

You snapshot the data in your application's native data format, then you can convert it later to the best match for the consumer. Taking the Excel example form above: You got to store the cell layout and values. If it's pasted into a different excel sheet you pass that structure over. If it is pasted in a richt text editor it is converted to some richt text table format. If it is pasted to a plain text editor it is m…

The Excel clipboard has a more complex model:

- If the copied data is pasted in the same Excel instance, then the system clipboard isn’t used at all and native Excel objects are pasted.

- If data is pasted in an OLE-enabled application (e.g. Word or PowerPoint), then an OLE-specific method is used.

- If the data is pasted into another Excel instance or into another application, then the system clipboard is used, but without the possibility to transfer native Excel objects, only csv, RTF, html, text, image, or an ancient spreadsheet-like format called SYLK.

Post reply on HN