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

Don't touch my clipboard

alexanderell.is

Post reply on HN
Print view View original

231–240 of 322 posts

Re: Don't touch my clipboard

#231

Post by alkonaut »

userbinator wrote: post #63

IE (but not Edge, not surprisingly...) actually has a built-in feature which was probably specifically designed to target such things: https://i.stack.imgur.com/855az.png Selecting "prompt" will result in this: https://i.stack.imgur.com/jvDUh.png I set it to Prompt for trusted sites, and Disabled for all others.

Reading the clipboard is a security risk. Reading the clipboard without having a user initiated paste seems like it shouldn't ever be possible (not suere whether that is what the option does).

In this case, what I'd like as a user option is to be able to say "Don't copy via app-specific code", i.e. "don't run the js event to let the page populate the clipboard, instead inspect the selection and if there is a text selection then copy that as plaintext, else copy nothing".

An alternative "prompt when the app tries to subscribe to the copy event" could also work. If I select a shape in an online diagram editor and the app says "can I please put my app-specific markup on the clipboard" then I say yes, because I understand there is now way copy paste works otherwise. And on a page when I have text selected, I can say no, and I get the default plaintext copy.

Some apps have this as 2 different functions for a formatted copy/paste vs. raw text copy paste. If browsers had a "copy text" context menu item that copied the raw selection without invoking the js 'copy' event, that would work too.

Re: Don't touch my clipboard

#232

Post by majewsky »

dredmorbius wrote: post #152
umvi wrote: post #88

Earlier quoted context omitted.

I always just type "#" first before pasting... That way it is just a comment I can inspect before running

If you're using Readline (most Bash or similar shells do), then C-x C-e will invoke the editor, and you can paste the output into that. Pray for no escape, bang, or control sequences. (Alternatively: "r! cat -D" will read into a vim session.) Examine the output, trim the unwanted / dangerous bits, and run (or save to a file/script). Since I run what are ... generously ... considered "bash one-liners" all the time, th…

> :r! cat -D

Alternatively, call a utility that can read the clipboard directly. For Xorg:

  :r! xsel -b
For Wayland:

  :r! wl-paste

Re: Don't touch my clipboard

#234

Post by brnt »

diffeomorphism wrote: post #195
brnt wrote: post #172

Earlier quoted context omitted.

Its easy (solved) to map Unicode to control characters such as quotes (and when you think about it, quotes are often there to deal with ambiguities stemming from the limited number of allowed characters in ASCII). So to could have a terminal accepting such input, and a few helper function that normalize it into ASCII and so on. After all, users of non-ascii languages (which is nearly everyone) already know how to dea…

> and a few helper function that normalize it into ASCII and so on If you are going to get rid of it anyways, why bother with it in the first place? Also, you then have the ambiguity/problem whether some symbols are mapped to the same ones or not. > already know how to deal with it without ambiguity I wish. Just dealing with ü vs ue vs \"u and ascii, win something, utf8 and utf16 is still annoying in practice. Or lat…

The argument to do it is it democratizes users with their scripts around the world (and solve the issue of having 'the wrong' quote). Normalization solves the latter. It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate.

Re: Don't touch my clipboard

#235

Post by greggman3 »

C4stor wrote: post #148
chrisseaton wrote: post #91

Earlier quoted context omitted.

> aren't even the ASCII quote character; you get horrid unicode quotes Why should they be ASCII, and what’s wrong with Unicode?

Because the next step when you face this problem is doing a search-replace of the quotes to remove them. ASCII quotes are on your keyboard, so you can actually type the command to remove them. Unicode quotes probably aren't, so it's extra annoying to remove them, and they're not even the same character for start and end so you have to do it twice. The time spent for removal is then vastly higher than with ASCII quote…

isn't that an input problem not an output problem? Is it giving you the quotes directly from the ebook or is it converting them on copy-paste? I'd assume there was a bug on the input side, that some tool wrongly converted `printf("Hello World")` to `printf(“Hello World”)` so what's in the ebook is wrong already. If so the issue is further up the chain.

Re: Don't touch my clipboard

#237

Post by dredmorbius »

alkonaut wrote: post #224
dredmorbius wrote: post #163

Earlier quoted context omitted.

Here's a stab at defining a function: The clipboard should act at an only at user direction to copy content from one application or context to another. The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content. Applications, other than when clearly and unambiguously directed by the user be able to access or read clipboard contents. I'd suggest additionall…

> The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content. This might feel intuitively right, but it severly limits the usefulness of the clipboard. It then becomes a basic plain text clipboard Try opening an rich text editor (e.g. https://quilljs.com/playground/ ) and selecting two words of which one is bold. Hit Ctrl+C. What is now on the clipboard? W…

If you want to pass rich text or spreadsheet cell formulae, display those before selecting. Which puts the onus on the application to provide that functionality.

That preserves the functionality, respects the "copy visibly-selected content" directive, and makes clear just what is being saved to the clipboard, making sneak attacks more difficult.

Argument that the clipboard behaves in a way that is demonstrably prone to malicious attack is simply argument from tradition. Yes, that's how things have been done. We're discovering that how things have been done leads to strongly negative consequences.

Re: Don't touch my clipboard

#238

Post by dredmorbius »

mattkrause wrote: post #225
dredmorbius wrote: post #163

Earlier quoted context omitted.

Here's a stab at defining a function: The clipboard should act at an only at user direction to copy content from one application or context to another. The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content. Applications, other than when clearly and unambiguously directed by the user be able to access or read clipboard contents. I'd suggest additionall…

That’s a good start, but it’s tricky. How are you going to distinguish between user and programmatically-initated actions? Adding something like a “Secure Copy Key”, akin to control-alt-delete in Windows might work, but it’ll need kernel-level support. Determining whether the clipboard contents faithfully represent the “visibly-selected” content is also very hard, possibly AI-hard. Suppose I copy an image while zoome…

How are you going to distinguish between user and programmatically-initated actions?

That is a deep and fundamental problem within any mediate technology. It's not trivial.

The simple answer is "look for indications from standard user inputs". But those inputs (keyboard, mouse, touchscreen) are themselves sufficiently complex that they can be mimicked, intercepted, or spoofed. There is the problem of distinguishing legitimate from counterfeit confirmation dialogues (already a persistent attack vector for desktop and mobile device users). There is the problem of rogue devices communicating over USB or Bluetooth connections (an argument for a principle of minimum necessary capability for interface ports -- serial and PS/2 connectors have their justifications), though that usually entails other devices being silently added to a system. Though a USB device spoofing an additional keyboard or mouse is also a demonstrated attack.

All of which starts drifting focus away from the key point: what is an unambiguous expression of user intent, and how would you go about ensuring that this is determinable?

The determination of contents question gets to a somewhat different matter: what kind of data are being copied?

I'll admit that I was thinking of the case of text, though there is also image, and conceivably audio and video data.

For text, zoom is irrelevant as that's a display artefact and (at least as I envision it) the goal is to copy the text as displayed, independent of typographical formatting, rather than "glyphs of some size and presentation".

Multi-user clipboard access is dependent on the graphical environment. For X11/Xorg, applications regardless of effective userID, have access to the clipboard.

(X11 also had some early attempts at securing the clipboard, with varying degrees of success. Issues such as grabbing keyboard input, potentially silently, were also an early concern.)

Re: Don't touch my clipboard

#239

Post by tjpnz »

Polylactic_acid wrote: post #125
ori_b wrote: post #42

Earlier quoted context omitted.

You can turn off JavaScript. This has the added benefit of disabling most tracking and advertising.

As well as disabling most of the internet. It makes more sense to turn off the bad apis individually and block known tracking domains.

>disabling most of the internet

I have JS blocked on some domains because of popups/other annoyances which make getting to the content a hassle. In those cases it's the exact opposite.

Re: Don't touch my clipboard

#240

Post by ErotemeObelus »

0zymandiass wrote: post #19
smichel17 wrote: post #14

The wrongest thing about this, from my perspective, is that my browser fires off a js 'copy' event when I press control-c. There are times when I've found it helpful that a browser can copy text to my clipboard when I click a button, but I can't think of a single time when I want a site to react to my attempt to copy text off if it. Is there any way to configure my user agent (Firefox) not to do this? A hack is ok.

about:config -> dom.event.clipboardevents.enabled = false You can't do it through a user agent, though

Yeah you're a friend.
Post reply on HN