Is there any way to configure my user agent (Firefox) not to do this? A hack is ok.
Text is highlighted on the page based on the code order, not as it appears on-screen (at least in Firefox and Chrome). If you throw elements off-screen with some CSS, you can create a big disparity between what the user thinks they are selecting and what they get when they copy/paste.
e.g: https://jsfiddle.net/Lbc5gsjm/
Not quite as neat as you can't put it dynamically around exactly what you select, but my favourite example of where you could get pretty malicious with it is a “plain text” link that injects a suffix to the hostname when you copy it.
It’s awkward how easily one can break a basic functionality like select & copy.
Combine a few of those techniques with a fancy-looking text box that you are supposed to "click to copy" to get a command, and it becomes pretty easy to even write css-only "exploits" to put stuff in the clipboard!
I already mentioned this in another comment, but everyone should enable bracket paste mode in their shell to defend against this.
echo "hello"
echo "lol" ; sudo sl -rf /
Pray for no escape, bang, or control sequences.
(Alternatively: "r! cat <paste> <ctrl>-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, that key sequence is locked into my muscle memory. It's a convenient way to invoke an editor immediately and run code from it.
Alternatively, call a utility that can read the clipboard directly. For Xorg:
:r! xsel -b
:r! wl-pasteI do this frequently on Android via Termux, ssh'ing to remote hosts.
What is infuriating is CSS that prevents text selection in the first place. That insult to usability should have never been adopted by browsers.
As a web developer, it's kind of funny seeing people exclaim "this feature should not exist" after seeing a few abuses of it, even though they probably benefit from it every day without realizing it. Overriding copying is needed for wysiwyg editors and selection blocking is needed for many kinds of drag&drop interfaces and also editors.
Instead of complaining that useful features exist because they can be misused, maybe complain about the misuse itself - maybe even to the people actually misusing them. Shoot them an email and they might actually do something about it. Most of these misuses hurt accessibility (screen readers, etc.), so if nothing else, they'll see it as a way to reach more customers.
I think it is needed for some complex web app to handle copying non-text content. Such as images in wysiwyg editor, Google Sheets/Slides...
I'd be 110% fine with that trade and nothing of value to me would be lost.
Is it possible in Firefox? Anyone know?
The browser is no longer just a document viewer... That ship has sailed, and overall it is a good thing.
We can mitigate the risk of clipboard hijacking without burning down the house. By the way, I would guess that this is a minor risk in the grand scheme of things, as it seems that the worst risks are for technical individuals people copying programmatic commands (e.g. software engineers). For others, it is a real yet minor annoyance.
Perhaps there could be an opt-in setting for allowing a site to modify the default content that is copied from a selection?
X11/Xorg has the primary and secondary selections.
MacOS has ... whatever it's got.
A key problem with this is that the feature is covert, latent, poorly discoverable, and causes unexpected behaviours. Even presumably advanced users (myself, you, other HN readers) are poorly aware of this. Imagine trying to explain to your nontechnical Aunt Tilly or Uncle Kamlesh about these "different clipboards which treat what you've copied differently and access through this funky interface"?
The Javascript interface isn't aware of these distinctions, though I'm not sure I want it to. Web apps like this that abuse one plain text clipboard will abuse multiple richly typed clipboards, too.
No, it really isn't. Web apps and documents using the same underlying technologies doesn't mean they have to be accessed through a single frontend that provides the worst of both worlds.
I don't think that is remotely the case.
I don't know whether that's planned to stick around or whether it was added when the clipboard event support was still experimental and will be removed at some point. But I suspect the former, for precisely the reasons in this thread.
Note that disabling these events will likely break "smart" copy/paste in things like Google Sheets, which is one reason it's not disabled by default....
You can't do it through a user agent, though
I've only ever seen that setting fix sites that try to prevent you from copying.
But I wouldn’t be surprised if stuff like this is the exception rather than the rule. I feel like most news sites and blogs are improved with JavaScript disabled.
Do you actually need clipboard events, or just dom.event.contextmenu.enabled for that?
The entire ask (stopping the copyright, and allow clipboard integration) be achieved by allowing pages to augment the clipboard data, which can already be done, but not replace it. Pages would still need to be able to hook paste.
So many lost rants ... ;o)
It ... ultimately doesn't scale. The black-hat namespaces are too large, and treating as TOFU eventually proves untenable.
Advanced features -- anything beyond rendering basic HTML, and I'd be quite prepared to argue for a very limited subset of that -- should be expressly prohibited unless enabled.
The trick is to make enabling reasonably painless and consequence-free (e.g., enable into a sandbox). There are still the problems of users gratuitously enabling anything and everything (especially when prompted through website notifications, pop-ups, phishing and vishing social engineering attacks, etc.), as well as the problem of largely invisible second and higher-order effects.
But the key is to cut down on the effectiveness of such methods, to impose costs on websites for employing them, and to make black-hat attacks through these too expensive by reducing the herd susceptibility to the attacks (the unbocking would have to occur on a one-at-a-time case-by-case basis, e.g., it's expensive and has limited scalability).
I don't think we'll actually see this for another 5-10 years (my usual sane-suggestion take-up lead time, it seems), but It Would Certainly Be Nice To See.
I had experimented with NoScript long ago, but found it a bit more cumbersome at that point because (then, before the uBlock days) I couldn’t really judge which scripts were necessary and which weren’t. I’m going to try it again.
One big plus with disabling JS is that all those ad blocker blockers and other annoying popups just don’t even appear, and that adds to a better experience.
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.
For mobile devices, easiest way is to use two different browsers (one with JS disabled).
A per tab setting that remembers the JS enabled state would be very useful, with the default being JS disabled.
It's useful for things like rich-text editors (e.g. google docs), where the text is never on screen as text that you are able to copy in the first place.
Perhaps in a rich text editor I want to copy as plain text; or perhaps I want to make a Markdown editor that you can select+copy the Markdown but then paste HTML. Just brainstorming.
document.addEventListener('copy',
function(e){ e.stopImmediatePropagation() }
);Any time you're not interacting with HTML text is a time it could be useful.