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

121–130 of 160 posts

Re: How the clipboard works

#121

Post by aidenn0 »

UI_at_80x24 wrote: post #117

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v ctrl + INS (copy) shift + INS (paste) IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick} This might even be a…

I definitely saw some of that keybinding in old DOS programs, but when I started using a microcomputer, the WordStar shortcuts (Control-K based scheme for copy/paste) were the most common.

Re: How the clipboard works

#122

Post by pvg »

UI_at_80x24 wrote: post #117

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v ctrl + INS (copy) shift + INS (paste) IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick} This might even be a…

https://en.wikipedia.org/wiki/IBM_Common_User_Access

It doesn't pre-date the C/V/X/Z shortcuts, it's just that those conflicted with things like CTRL-C to interrupt.

I don't think hardware interrupts are involved here. It's not a particularly early DOS convention either, Wordstar-style shortcuts were popular before it.

Re: How the clipboard works

#123

Post by [deleted] »

UI_at_80x24 wrote: post #117

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v ctrl + INS (copy) shift + INS (paste) IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick} This might even be a…

[deleted]

Re: How the clipboard works

#124

Post by [deleted] »

UI_at_80x24 wrote: post #117

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v ctrl + INS (copy) shift + INS (paste) IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick} This might even be a…

[deleted]

Re: How the clipboard works

#125

Post by imiric »

323 wrote: post #84
imiric wrote: post #33

It's remarkable to me how we still don't have a security-minded clipboard implementation, seemingly on any OS. It's standard security practice now to use a password manager, but they all[1] exchange critically sensitive data with applications via the clipboard, which is accessible by any application that asks for it. The best we can do is automatically clear the clipboard after a certain time, but this still leaves a…

> which is accessible by any application that asks for it If you have malicious software running on your system, all bets are off. There are many ways it could steal your passwords, since desktop OSes don't sandbox apps like mobile OSes do. Just one example: you send the password securely to Chrome, but the malicious app just reads the login session cookie from the Chrome user profile files. Having a secure way of se…

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

> There are many ways it could steal your passwords, since desktop OSes don't sandbox apps like mobile OSes do.

Well, sure, but isn't securing this one major IMO attack vector an improvement over not doing anything about it? I don't follow this defeatist logic of "well, if you're already running malicious software, you're SoL".

Besides, this clipboard issue is also a problem on mobile OSs, since all apps share a global clipboard. Unless some app-specific workarounds are implemented, as mentioned elsewhere in the thread.

Re: How the clipboard works

#126

Post by imiric »

xerxesaa wrote: post #79
imiric wrote: post #33

It's remarkable to me how we still don't have a security-minded clipboard implementation, seemingly on any OS. It's standard security practice now to use a password manager, but they all[1] exchange critically sensitive data with applications via the clipboard, which is accessible by any application that asks for it. The best we can do is automatically clear the clipboard after a certain time, but this still leaves a…

KeypassXC takes a slightly different approach. It uses named pipes to send the password from the application to the browser extension. Though the browser is where I find myself using it 95% of the time, they also have an "auto type" feature that will go to the last window and type in your password for you (again, without passing through the clipboard).

Sure, but those are all workarounds for specific uses and operating systems, which require specific integration between the app and the browser.

What I want is a native solution provided by the OS that would work for all apps and scenarios.

Re: How the clipboard works

#127

Post by GaryPalmer »

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?

Re: How the clipboard works

#128

Post by imiric »

nirimda wrote: post #81
imiric wrote: post #53

Earlier quoted context omitted.

I think those are workarounds with questionable UX. Whereas something as security sensitive as credential access should have a native OS-provided workflow that's secure by default.

Drag-and-drop seems to have an excellent UX. The semantics are incredibly clear: Take this data from this app and put them into this container in that app. Any insecurities would be an accident of implementation rather than part of the core design like with copy-paste. Or, how is drag-and-drop insecure by default, and what alternative do you propose?

I'm not saying that drag-and-drop is insecure, but that it's not an ideal UX. I, for one, don't enjoy using it on any OS, and I guess I'm not alone.

The alternative I propose is a native solution from the OS to pass data securely between applications. Not workarounds like drag-and-drop or built-in app keyboards that force me to change my workflow.

Re: How the clipboard works

#129

Post by Tyr42 »

jeroenhd wrote: post #17

For those wondering about how Windows does this, there is, as you'd expect, a Raymond Chen article about it: https://devblogs.microsoft.com/oldnewthing/20210526-00/?p=10... (and some more, like https://devblogs.microsoft.com/oldnewthing/20220608-00/?p=10... ) Elsewhere in these comments there is also a link to an explainer for the macOS equivalent. Here's also an explainer for X11: https://www.uninformativ.de/blog/po…

Yeah, windows let's the clipboard owner decide if they want to delay rendering per format.

That might be nice, especially if you are just copying a short amount of text before closing the window.

Re: How the clipboard works

#130

Post by Dwedit »

UI_at_80x24 wrote: post #117

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v ctrl + INS (copy) shift + INS (paste) IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick} This might even be a…

It's not a hardware interrupt at all, and needs to be specifically programmed into the text editor.

It's just that that was the de-facto standard before Ctrl+C and Ctrl+V replaced it. Back then, Ctrl+C was the break key, so it wasn't usable.

Even in Windows today, you can still use Ctrl+Insert/Shift+Insert/Shift+Delete in text edit or rich edit controls. Libreoffice even supports it.

Post reply on HN