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

51–60 of 160 posts

Re: How the clipboard works

#51

Post by chrismorgan »

evilpie wrote: post #40

> Type starting with x- are non-standard. x-moz- means it’s a mozilla-defined one. There seems to be no standard mime type for a URL The standard web MIME for url(s) is text/uri-list: https://www.rfc-editor.org/rfc/rfc2483#section-5

For those curious about how you’d find things like this: look in the media type registry at https://www.iana.org/assignments/media-types/media-types.xht...>; the likely search terms for something like this would be “URI” and “URL”.

Still, I would agree with the original statemnt “There seems to be no standard mime type for a URL.” as text/uri-list is for a list of URLs with ␍␊ line separator and #-prefied comments. It would have been nice to have a MIME type for an individual URL with none of that, but it’s a bit late now, for best results anyway.

Re: How the clipboard works

#52

Post by Rutrus »

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…

I used to copy and select, so I copy a URL and select the title of the page, keeping two different memories for pasting.

Re: How the clipboard works

#53

Post by imiric »

HPsquared wrote: post #36
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…

Drag-and-drop works pretty nicely with most password managers, avoiding the clipboard (in Windows at least). In Android, it's a case of using a password manager with a built-in keyboard, and having a button available to switch keyboards quickly.

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.

Re: How the clipboard works

#54

Post by ygra »

Khoth wrote: post #13
CobrastanJorji wrote: post #9

The "closing the app after copying and before pasting" case is very interesting. Shows how even things that sound simple turn out to have very tricky edge cases as soon as you start optimizing and really thinking about how to implement them. The clipboard manager solution seems okay, but copying everything immediately seems like it defeats a lot of the elegance of the design. Perhaps it'd be preferable if the origina…

On Windows, when you Copy the program supplying the data decides whether to send the data to the clipboard manager straight away, or whether to defer. If it defers, then yes it does a "last call" on closing. If it crashes you lose the clipboard. Some programs will ask you when you quit them if you want to keep the clipboard contents, if you'd copied a large amount of data.

Annoyingy, in Excel's case that question "Do you really want to quit? You have copied large amounts of data to the clipboard." even occurs when you have a single cell's worth in the clipboard. But that's also a confirmation question that no one really understands unless they understand how the clipboard works (or can work).

Re: How the clipboard works

#55

Post by hoseja »

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…

Look into the implementation in KeePass, it at least does some mitigations.

Re: How the clipboard works

#56

Post by imiric »

Beltalowda wrote: post #47
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…

Are there "clipboard snoopers" out there? Or more specifically, are there clipboard snoopers that access sensitive data they couldn't also access in any other way? It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.

> Are there "clipboard snoopers" out there?

I haven't run into any (that I know of), but it's trivial to write such a program.

> are there clipboard snoopers that access sensitive data they couldn't also access in any other way?

There's no such thing as a 100% secure system, but removing one of the most vulnerable attack vectors is a huge improvement in and of itself.

> It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.

Not quite. Currently all applications have unrestricted access to the clipboard. Accessing decrypted credentials in a password manager is only possible by the authorized user, and this can be restricted in a number of ways. Maybe we need a stricter permission system for clipboard access, but I would argue we need to stop using the clipboard for exchanging sensitive data between applications.

Re: How the clipboard works

#57

Post by enriquto »

Beltalowda wrote: post #49
nicoburns wrote: post #44

Earlier quoted context omitted.

I absolutely hate select to copy. It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about. I quite like ctrl-c/ctrl-V (or cmd on a mac). Very easy to use while controlling the mouse with the other hand.

> It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about. I mostly find it really useful for "quick copies", like the quote from your post here. I don't really care if it gets overwritten because it's only relevant for a few seconds. For anything else you can still use ^C/^V on Linux.

> you can still use ^C/^V on Linux

How do people stand these particular keybindings? They get so much in the way inside a terminal! They are possibly the worst choice of keys for something as important as copy/paste (if the keyboard is needed at all, but I digress).

^C = forcefully stop the current program

^V = escape to enter the next character verbatim

I use these two all the time, and I find it very confusing that they have a different meaning in other contexts.

Re: How the clipboard works

#58

Post by Beltalowda »

imiric wrote: post #56
Beltalowda wrote: post #47

Earlier quoted context omitted.

Are there "clipboard snoopers" out there? Or more specifically, are there clipboard snoopers that access sensitive data they couldn't also access in any other way? It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.

> Are there "clipboard snoopers" out there? I haven't run into any (that I know of), but it's trivial to write such a program. > are there clipboard snoopers that access sensitive data they couldn't also access in any other way? There's no such thing as a 100% secure system, but removing one of the most vulnerable attack vectors is a huge improvement in and of itself. > It seems to me that if you can access the syste…

It's indeed trivial to write such a thing, and given that none seem to exist it doesn't seem like it's really a practical security issue IMHO.

I think a permission system for the clipboard would be pretty awkward UX, and not really worth the effort for the (hypothetical) problem it's solving.

Re: How the clipboard works

#59

Post by dfox »

the_mitsuhiko wrote: post #22
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…

> It's interesting to look at these clipboard APIs together to see what may have led to the Wayland design If that lead to Wayland then I think people took away the wrong lessons. Wayland's current protocol / API for clipboards is incredibly annoying. It's hard to deal with for applications, it's even harder to deal with for clipboard managers which were not really considered in that design and usually break the clip…

X11/ICCCM clipboard semantics (which is arguably the same design, but with the server being part of the data transfer) was also source of many bugs and the applications/toolkits did not get it right until 00's and linux-centric desktop environments. IIRC disagreement about how to integrate Emacs' concept of kill rings with X11 selections was one of the major reasons for Emacs/XEmacs split.

Re: How the clipboard works

#60

Post by Beltalowda »

enriquto wrote: post #57
Beltalowda wrote: post #49

Earlier quoted context omitted.

> It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about. I mostly find it really useful for "quick copies", like the quote from your post here. I don't really care if it gets overwritten because it's only relevant for a few seconds. For anything else you can still use ^C/^V on Linux.

> you can still use ^C/^V on Linux How do people stand these particular keybindings? They get so much in the way inside a terminal! They are possibly the worst choice of keys for something as important as copy/paste (if the keyboard is needed at all, but I digress). ^C = forcefully stop the current program ^V = escape to enter the next character verbatim I use these two all the time, and I find it very confusing that…

I don't use it from my terminal; I just use the select mechanism there. In Vim I have some mappings to copy from and to the + and * registers though.

^V is probably rare enough that it's not a big deal, but ^C is indeed an unfortunate conflict.

Post reply on HN