thats kind of unfair, when you select something and you are confident what is selected, pasting with middle button and hitting enter can be milliseconds apart
you already decided to hit enter while you are selection something, could be just a bit above your current cursor in the terminal
gnome-terminal does support bracketed paste[0], and both bash 5.1 and zsh 5.1 enable it by default, so if you paste into it it will input a newline in the prompt instead of executing the command
People on a hurry and the uninformed that still haven't heard that you can end up with malicious stuff on the clipboard if you haven't careful e.g. someone who inspects the text "systemctl restart cups" on the webpage, concludes it's what they want to run, then copies it straight to the terminal without noticing the web page was hiding malicious code in invisible text.
Why is it so easy to find people in this industry who don't care that users can't trust their own computers (or, by extension, anything they own with a computer in it, which is quickly becoming everything)?
If I select some text and press Ctrl+C, it should copy the text I selected. The user intent is obvious. There's no excuse for the ability to hijack the clipboard to exist in the first place.
Web pages shouldn't be able to modify my selection. Why is there even an API for this?
The web ecosystem (including browsers) turned straight up malicious like 15 years ago, and users became nothing more than a product for everyone involved. That cancer has even metastasized and spread to the OS or even products that people pay thousands or tens of thousands of dollars for. I don't know how people who think that way can live with themselves.
I have a copy to clipboard button that's standard across all apps and has decades of precedence: Ctrl+c. Some (older?) keyboards even label it!
On my phone, if I select text, my browser pops up a menu with "copy" as an option.
Why does a web page need to reinvent that wheel?
For the 1/10000000 case where it makes sense, how about a "X page wants to modify your clipboard" dialog? This has been a known security vulnerability for at least a decade.
Edit: actually, I just noticed that was a reply to selection, which makes even less sense. Just let the user select what they want.
When copying Unicode characters from sites like symbl.cc, it would be incredibly annoying to have to select them and press Ctrl+C instead of just pressing a single button.
Ctrl-c sends the interrupt signal. Remembering that in normal use (terminal) it sends interrupt, except for this one program (Firefox) where it copies would be pretty confusing and annoying.
Incorrect pedantry that ignores decades of established convention with GUI applications aside, the same incorrect behavior happens when you select, right click, and choose "copy". Any normal person would expect that it copies what you selected, and doesn't let the page instead place whatever it wants to into the clipboard.
The user tells their computer to do a simple thing, and the computer adversarially does not do that thing, and instead obeys someone else, intentionally. That should not happen.
A computer is a tool and also a consumer device. I think most of us are in some sense selling the output of the tool (for example a programmer sells programs, not computers). Since we are not selling computers, we’re not automatically concerned with whether people are happy with their computers.
If you went to a scissor factory and told them that their scissors were too sharp, they might at least think of doing a run of safety scissors. If you go to a tailor and suggest that, they will probably be confused and not very receptive.
But it's not about sharp tools. In fact one of the problems is that computers are all being turned into safety scissors. But they're safety scissors that sometimes randomly fire a bullet backwards into the user when you snip. And the people making these things say "well yeah you need to know about the hidden gun and be careful of where it's aiming."
Or if instead of things like the sawstop, we made power saws that sometimes just flip open the guard and swing the blade to toward the user. But there's a safety to prevent that, but it disengages whenever you start the saw, so you need to reengage it every time you cut something in-between starting the saw and actually cutting.
If I understood it correctly, the snippet in TFA injects a return as well, so by the time you give the second look, the commands had already been executed.
In a following snippet, the terminal scrolls 100 lines and prints no prompt, so a user is tempted to press Enter just to check what's going on. You can count this as a form of phishing, if you want.
I am surprised that Firefox freely allows access to the clipboard. I'm using Brave and there's an explicit permission for it that is disallowed by default.
I boggled over this particular obvious problem for years.
But I don't recall Firefox ever being hardcore security and privacy (even though some of their techies are). For Mozilla, that's a fairly recent positioning that they're growing into.
Initially, there was competition to be the most popular browser.
But most of the history is a constant movement towards having the browser facilitate what companies wanted to do towards users (moving away from the "user agent" as an agent of the user).
In parallel, Google paying Mozilla for placement, and then possibly to keep a nominal competitor alive.
In recent years, Mozilla has been positioning itself as one of the champions for Internet freedom, and I assume that some of their people were that all along (e.g., the kind who could've gone to Google, but chose to work for much less money at Mozilla). Though I don't know how genuine that sentiment is from the top, when leadership draws huge compensation, for poor performance, while laying off techies. (Techies traditionally have lead Internet freedom, from the ground, up, and leadership might be better thought of as a humble support system for that.)
There are guardrails around access to the clipboard (and the post talks about the circumstances around it) but this exploit takes advantage of the fact that simply selecting text on X11 puts it in the primary selection buffer. The code just tells Firefox to select the text.
Not that it matters, but it does not really put it into a buffer at least not in the sense that there is a place within X11 that is storing your selection. I think that when you paste the primary selection. X11 directs your application to the application that last selected something and you ask it for the selected bit in a specific (usually text) format.
More on topic, this works fine within the trusted green zone of local desktop applications. but the browser is(or should be) a high security zone. with a really tricky security policy. which to paraphrase would be "Allow passing information to the rest of the os. but only as a result of a direct user request." You don't really want to disallow the browser to script selecting anything, this is useful for editors. but you probably want to maintain a flag on that selection as to if it was done by the user or not.
Well there is my useless pedantry for the day done. My apologies and thank you for letting me get that off my chest.
There are "clipboard managers" that will internally copy the last copied thing as best it can from the clipboard owner, and then when the application exits, will mark its copy as the clipboard owner going forward. If you aren't running a clipboard manager, then yes, nothing will happen.
The same thing happens with normal ctrl c + ctrl v. One of the oddities of the Linux desktop of X and Wayland is that for some reason the display server is also in charge of letting people use the clipboard instead of it being done by a dedicated clipboard service.
Some programs (such as xterm) will also use "cut buffers" (in addition to the primary selection, which is what is usually used for the middle button paste) which are retained even if the program is terminated. (Cut buffers are properties of the root window.)
I am using Brave on Linux where I do all my work as well that might by why "copy to CB" on websites do not work for me anymore. I think they did. But there is nothing asking me for permission or anything. I recently was on a website where it just did not work and I needed to manually copy pasta.
I thought the bug is that you don't need to interact with FF to get injection into pasted payload... So am I wrong to think that as long as FF runs in the background, you can still get injection to the payload you just copied from the editor?
The bug here is that between the "copy" and "paste" operations, a script running in the background can win the race to rewrite clipboard contents before "paste" happens. Thus the defense needs to happen on the "paste" side, changing the "copy" side would result in the same race.
A solution is bracketed paste[1] as mentioned in earlier comments[2], which would allow the user to examine a pasted command before running it.
and that editor should not be running "inside" a terminal
-- or rather I don't understand why those that like interacting with their editor via a terminal interface don't create a new protocol that doesn't have the warts and vulnerabilities the current ancient protocol has.
e.g. Vim creating their own protocol is rather pointless if no terminal implements it, and some terminal creating their own protocol is also rather pointless without application support.
Plus there's tons of software out there and it'll take a long time for it all to be rewritten, if that ever happens. e.g. X11 will still be around for a long time as well. So you will need to remain compatible with the current protocol even if you invent something new and better, and in that sense it doesn't really fix anything., at least not right now. It might fix stuff 15 years down the line, maybe, but in-between now and 15 years everything will be more complex by having two protocols.
And all things considered, it's not that bad, IMHO. There's the KiTTY Keyboard protocol to solve some obvious UX issues with keyboard handling, which is a clear improvement and motivation, whereas some exploit vectors that don't really see live exploits isn't really.
There are dozens of toolkits for authoring GUIs, which are much more complicated than the protocol we are talking about and consequently much more work, so, no I don't see why the Vim project cannot take on the work of defining a new protocol and maintaining a client that speaks the protocol.
The hairiest Emacs Lisp code I know about is the code for responding to mouse actions, e.g., clicking and dragging, and most Vim users don't even want to use a pointing device to interact with Vim IIUC. (In contrast, 80% of Emacs users who responded to a survey do not interact with Emacs through a terminal interface.)
For example, the old scripting language Tcl has its own GUI toolkit named Tk that has a pretty good reputation.
>And all things considered, it's not that bad
It seems bad enough to me to be worth re-architecting.
But GUI toolkits work very different; ProgA can link against GTK, ProgB against Qt, ProgC against Tk, and that all just peacefully coexist without problems (short of perhaps some UI inconsistencies). None of these toolkits have to even be aware that the others exist for it all to work; there is no shared protocol (other than the system itself: X11, whatever Windows has, etc. – and look at how long s/X11/Wayland/ is taking, and there is considerable disagreement whether Wayland is even an improvement in the first place).
But in a terminal all code runs in that terminal, and terminal programs don't "link against" a terminal in the same way that you do with a GUI toolkit. You need to implement a shared protocol on both ends.
My Tilix/zsh combination just pastes the content as a multi-line entry to the terminal. If the clipboard contains control codes (e.g. arrow up) they are entered verbatim (as if I had used the quoting function ^V to enter them).
So I suppose we're not very far from this not being a problem in general.
Though I understand this also works via control codes. I hope Tilix is smart enough to filter them out from the clipboard before doing this..
edit: I tested that case out, and it works. I suppose the protocol uses quoting.
I just went back to try again and I was wrong. I must have unthinkingly highlighted some text from the prior explanation page and that was in my middle click paste buffer without me knowing it. I thought that text was the demo and it worked with JS off. It doesn't. Sorry.
This sounds like it's not really an X11 issue. From the article:
> For firefox running in Wayland, `writeXPrimary()` will only succeed
when the firefox window (the main window, not necessarily the tab the code
runs in) has the focus. Otherwise the selection will be cleared. At first I
assumed that this is something specific to the Wayland protocol, but that
turned out to be utterly false; it's just some quirk, bug or "feature"
specific to either firefox itself or GTK.
> But I think that's still bad enough, even if the page should take care to
only set the selection when the main window has gained focus.
It's not. Wayland has a similar primary selection mechanism, and has the same problem. Firefox tells (X11|Wayland) that the text is selected, so that's what gets pasted, because that's how the entire thing works. The article even mentions this.
I couldn't get this working in librewolf, maybe the hardening it uses prevents this. It works like a hot damn in tor browser though, which is supposed to be fairly locked down. Don't forget to turn off javascript before you leave home, kids. In chrome based browsers it rewrites the X11 paste buffer if you select anything on the page that's running the script, which is effectively the old fashioned clipboard rewrite attack. This is a nice find, I like it.
To those wondering who would paste and execute without a second look, there are ways to hide text. You can also paste control characters, so if you pasted into vim the command would get executed without any visible feedback. Same could be true for emacs, someone who knows it better could pipe in.
Any time you run potentially malicious code (like clicking on a random link when you have javascript enabled) on the same computer as data you care about, you're taking a risk. Sandboxing is a compromise, but one that's usually worthwhile.
> Same could be true for emacs, someone who knows it better could pipe in.
I believe Emacs differs in two relevant ways, both not technically inherent: command prefixes are by default non-printable, and it's relatively uncommon to run Emacs without GUI.
Just tried `echo -en '\x18\x03' | xclip`.
Emacs in the default GUI mode works as expected, just pastes ^X^C (that's two control characters, they are just rendered this way) into the buffer.
xfterm4 or gnome-terminal pastes Unicode Control Pictures [1] (TIL there's such a thing) ␘␃, the same in bash, cat or `emacs -nw`.
Finally, bash in xterm echoes the control characters raw, but Emacs once again manages to get ^X^C in the buffer.
For disabling X11 middle click paste, I found an interesting SO post but the best answer I saw and tested myself and it works, was the one by Suraj Inamdar about one third of the way down the page:
That removes your middle mouse button entirely! (Unreliably due to the use of numbers with xinput, which can change; xinput can take names to avoid that issue). The issue will remain if the primary selection is pasted into a terminal by other means (personally, I use a key combination rather than mouse button) and won't be an issue if clipboard.autocopy is set to false in about:config in Firefox (per torgard's comment).
I've also set dom.event.clipboardevents.enabled to false since I don't want websites messing with the clipboard.
I don't see how the copy issue is worse. It relies on an explicit user action: selecting text in a browser window, and then copy/pasting that into a terminal. This requires three intentional steps.
Pages stealing your current middle-mouse-paste selection, however, only requires selecting text in another place, and it seems like the only way to defend against this is by not selecting text. Which, at least for me, is not really feasible.
The trick with a laptop are Thinkpads. some models have three physical "mouse" buttons.
I was not looking for this as a feature when I bought one a few years ago but it had them and it has proved the thing I like about the machine the most.
Some Dell models too, when you choose the keyboard model with a trackpoint they come with the extra set of three physical mouse buttons above the trackpad.
On an x13 2nd gen running Ubuntu 22 LTS with Wayland + libinput, middle-finger ^H^H^H middle-button paste generated by the touchpad driver was almost always triggered instead of right-click, which turned out so annoying, in addition to having lost kinetic scroll/device-specific coefficients, that I left Linux for good and switched to Mac OS instead, which I had already been using 2003-2009.
You can set up eg. a 3-finger touchpad tap gesture for the middle button in KDE Plasma, I'm assuming the same should be possible under GNOME. No need for fancy touchpads.
When you don't have a middle button, mouse chording (left+right at the same time) is usually configured to simulate the middle button (for instance, the Emulate3Buttons option in the classic X server configuration). Once you get used to it, it's nearly as convenient as clicking a physical middle mouse button.
The X “primary selection”/middle click paste behavior this takes advantage of is one of my least favorite Linux features and I have had it disabled for years, so I didn’t even know it had been changed/removed in Wayland.
Having a single mouse button (that often has other functionality like autoscroll in Firefox) cause text highlighted in another app to paste in the focused app is super unintuitive to me, and caused a few significant annoyances unintentionally pasting secrets or private messages in the wrong place before I got rid of it.
Conversely the select/single-click-paste is one of my favorite features of X11 it turns assembling text from various sources from a deliberate action to a natural movement. Objectively it is not that much of an improvement, it only removes two steps from normal copy paste. drag paste comes close but I never use it for some reason. But it is surprising how infuriating going back to command paste is(for example if I am on windows)
I do agree that overloading the button is terrible. I like the scroll wheel but wish there was a separate middle button. And I loathe middle button auto scroll, I regard it as a useless, user hostile feature.
Meanwhile it is one of my favorite ever features that speeds up many tasks during my average workday. :-) It takes a bit of care though especially if there are prod-impacting sessions open.
I love middle click paste, in combination with ctrl+c/ctrl+v paste it's a second clipboard, which allows to do one kind of refactoring in between doing some other refactoring in code (as just one example).
I didn't know wayland doesn't support that either, one more thing to add to the list of things it doesn't support like screenshots, xclip, mouse/keyboard automation, etc...
Whether it's unexpected or not depends on the user, you could as well say ctrl+v pasting in windows is unexpected if you don't know this shortcut. Middle click paste in linux is a standard feature this OS has always had
Well, we can have a long discussion about what is "better" or not, but in the end it's just a preference, and also a long-standing paradigm.
It's fine to dislikes it; everyone dislikes some features (e.g. personally I really dislike autoscroll). The thing is that it's not "unexpected" because it's been like this for >30 years, since the 80s. Nor is there anything wrong with it: it's just something you can like or dislike.
Or to put it in another way: if I wanted my Unix system to behave like Windows or macOS then I'd be using Windows or macOS.
It also closes tabs, and can allow scrolling. These things are in different contexts and don't interfere. You'd need to be in a text box to middle-click-paste. It won't mess up opening a link in a new tab.
This doesn't cover the use-case of having unique info in both at the same time, allowing you to paste in your desired order. I have a script where I read from the primary selection, modify the text, and put it on the clipboard. I use this along with something more like a regular clipboard manager to complete a task. Combined I can highlight some text, put other info on my main clipboard to paste right away, then run my script that uses the primary selection afterward without going back to re-copy the first text.
Grim for screenshots, slurp for selection (similar to maim). wl-clipboard works like xclip with its wl-copy and wl-paste commands, I use it extensively in scripts. There is ydotool (not to be confused with xdotool) for kb/m automation. Highlight + middle click paste also works as expected and I use that many times a day. Primary selection is also available to wl-clipboard with a -p arg for both copy and paste.
t. actual daily Sway user for several years now
It's insane to me how much misinformation is spread about Wayland by people who just don't even try it. I guess people want to hate it.
> It's insane to me how much misinformation is spread about Wayland by people who just don't even try it. I guess people want to hate it.
I suspect it didn't work at one point and then people ditched it and have that as their memory. I tried to switch to sway, a bunch of stuff didn't work like I expected and I just switched back to i3, this was probably 3-4 years ago at this point.
I assume it's probably gotten better, so I don't go around commenting. But I fully believe people did try it and it didn't work for them (at some point) and they just ditched it.
It annoys me so much. I’ve tried to disable but none of the methods I’ve seen have worked for me. I use middle click to autoscroll, and to open things in new tabs or to close tabs.
Then I try to middle click autoscroll in discord or something (which works in windows!) and I’ll paste in information that I don’t intend to.
This is the first I’m hearing about Wayland fixing this. Maybe I’ll give Wayland yet another try soon.
> I've tried to disable but none of the methods I’ve seen have worked
You can fix this in the latest working firefox version with `about:config > middlemouse.paste = false` (I found this by browsing through about:config, so I'm not sure if it's decumented anywhere), but I'm not sure if that still works in the enshittified versions.
(It doesn't prevent selected text from being middle-pasted into other applications, but all my other disrupted-by-paste applications explicitly don't support middle-click-to-paste (in several cases because I deliberately wrote them that way), so I haven't gotten around to fixing that part yet.)
Yeah I’ve got it disabled in Firefox. And now that I’m looking into it more I’m seeing an option in VSCode, which is the other main place I keep pasting when trying to scroll.
But this “feature” is enabled globally across XServer and is so deeply engrained that there is no global off switch. I must find workarounds for every application in order to make my middle mouse click function as I would expect.
For an OS where everything else is so customizable this baffles me.
I so frequently encounter problems where I proofread something (or my compiler finds it for me) and I find weird words or sentence fragments that I inserted on accident while navigating a document.
Agreed, I had a hell of a time switching to Linux in part due to the difficulty in disabling this feature everywhere. I simply hate it and do not want it. It doesn't bother me if other people like it, it doesn't even bother me if it's on by default, but why is it nearly impossible to disable? It's baffling.
We're having a conversation in this thread about whether or not the feature is good, but it shouldn't matter. People who like the behavior and people who don't should be able to live side by side, without one affecting the other. The issue is that the feature should not be forced.
I cannot stand any Operating System that does not utilize left-click highlight and middle click paste. This is great secondary buffer to the clipboard Ctrl+C && Ctrl+V. I HATE the middle click scrolling feature that Windows uses, it is not user-friendly and not needed in the age of the scroll-wheel. Another reason you have to pay me to use Windows.
Not OP, but I can say that it is a mode, which is its problem. You enter into the scroll mode and while not difficult per se to exit it can cause confusion. It is also pretty superfluous in the age of the touchpad and the ubiquity of the scroll wheel. Just another example of Microsoft working really hard to make Windows 11 look simpler, but not working on making it meaningfully simpler.
I don't know when middle-click scroll was introduced, but it definitely was before Windows 11, and at least as far back as 7.
Also, "no modes" is both a question of personal preference and a sliding scale. Input-has-focus is a mode, too, but getting rid of that would be an obvious mistake.
A few years ago, after being unable to configure OS-X for highlight-copy and middle-click-paste, I turned in the brand new MacBook and requested a simple laptop to install Debian and KDE on.
I hardly ever touch the mouse, but if I am using it then I'm most likely copying and pasting. Don't make that difficult.
It’s been many years since I used Windows on a daily basis but that middle click scrolling feature was one of my favorite things about it. You could activate it and position the mouse cursor just right so that the page moved with your reading speed and then you could just focus your eyes along one “line” and read that way. Hands-free scrolling after it is setup.
I’ve used it just like that on Firefox on Mac and Linux for years. I generally prefer a mouse to a trackpad and it’s a way nicer interaction than using the scroll wheel to jump down the page.
But there are three buffers! There is a Secondary buffer as well. Emacs supports it at least, but no idea how to access it elsewhere? Top answer to this su question claims there is some old X10 cutbuffers supported in X11 as well (that I learned about just now) so maybe at least four buffers in theory?
As a counterpoint: I love the middle-click scroll feature and use it on all platforms I can.
When I'm reading a long article, my usual strategy is to middle-click and then move the mouse to a position that causes the page to move in time with my reading speed. The continuous movement is a lot easier for my eyes to track than occasional bursts of scrolling, and I can tweak the scroll speed by subtly adjusting the mouse position. It's a bit like cruise control for scrolling.
I'm not saying you ought to use it, but you're decrying it as "not user-friendly" and "not needed" when what you really mean is "I don't like it" and "I don't use it".
I don’t care about middle-click paste, but having selection auto-copy is also implemented by terminal emulators like Putty on Windows, and I wouldn’t want to miss that.
What’s problematic with the Firefox behavior is that content gets copied (pasted) that wasn’t selected by the user.
It's absolutely no different than if the actual HTML contained invisible text though.
The patch here would not help security at all. Only using control-x control-e before pasting (so that it comes into a real editor, not directly in the terminal) can help.
It’s different in that the content can change after you selected it.
Invisible text can add to what you selected, but it can’t replace it.
There’s also an argument to be made that invisible text shouldn’t be copied, though that’s harder to define precisely (you don’t want to copy “display: none”, but you want to copy scrolled-out content).
I don't think selection along is enough to copy in windows terminal or putty. You also need to right click once to trigger the copy. So the moment that triggers actual copy always requires human interaction.
It's not a Linux feature. It's an X11 feature that is super intuitive if you've been using it for 30 years. Wayland tried to remove it but it has been begrudgingly allowed because of it's incredible usefulness since it cuts out all keyboard interaction.
> I'm annoyed when I have to move my hand back to the mouse.
You can bind a keyboard shortcut to a script that copies the primary to clipboard, then can use ctrl-v. Most apps also bind shift-insert to paste the paste buffer, so I bind shift-delete to this script, then to paste the primary it's just shift-delete then shift-insert. Here's the "script":
This is in fact my most favourite feature. Having a selection and a clipboard just feels like second nature to me and lets me copy selected text around without having to destroy the clipboard contents.
I want to share a related annoyance. I installed Linux on an old laptop. When I want to scroll using a touchpad with two finger swipe, sometimes it triggers a two finger tap, which is a middle click - which then pastes the clipboard content. Mildly frustrating when editing code or browsing chat apps.
Tried a few solutions but they didn't work on Wayland (as most of them were xinput hacks).
I didn't experience such accidental pastes when I had Windows installed.
Yeah, I absolutely hate it. MacOS is the only system with sane handling of copying and pasting, because it doesn't have that obnoxious thing and it doesn't overload the ctrl key. Command+C doesn't interfere with ctrl+C in terminals.
Copying should always be deliberate, not something that blasts out your clipboard when you click in the wrong place and select something unintentionally. And middle click is for opening tabs.
> not something that blasts out your clipboard when you click in the wrong place and select something unintentionally
This isn't helped by the fact that the mainstream desktop OSes don't have proper clipboard managers bundled by default. Accidentally copying something isn't as big a deal when you have the most recent 200 items you've copied in an easily searchable widget.
FYI Window's clipbord history has better security than what desktop Linux has. For example desktop Linux currently has no way to copy an image and specify that the contents are sensitive and should not be added to the history.
Poor API design and the inability for APIs like the clipboard to evolve are part of the reason why desktop Linux's security keeps falling behind other operating systems.
How do you copy something without adding it to the clipboard history? I can't find how to do that?
Either way, I'm pretty sure it could be added if someone cared enough, e.g. by adding a new target.
It just seems to me that if someone is able to access your clipboard history you've lost already, and the entire feature seems more of a convenience thing than a security thing.
>Either way, I'm pretty sure it could be added if someone cared enough
That's the problem. Ironically, not enough people care about improving the security and privacy of desktop Linux.
>It just seems to me that if someone is able to access your clipboard history you've lost already
Do you not see how it could be problematic if sensitive things were logged and persisted to disk?
Edit: Some clipboard managers on Linux do have an undocumented way to do this by adding an additional format to what's being copied with a MIME type set to x-kde-passwordManagerHint and data set to "secret".
Most clipboard managers don't store to disk but in memory, AFAIK anyway.
And your link just shows some programmatic access? How do I access that as a user when I press Ctrl+C? I suppose it's "useful" for things like password managers, but since anything can read the clipboard anyway it's a very limited protection. If something is so sensitive that you're using that special programmatic way of storing it then you should be using the clipboard but an actually secure mechanism.
Learning that you can middle click on the back/forward/refresh buttons to open the previous/next/current page (respectively) in a new tab was a game changer for me
Conversely, the selection buffer and middle click paste are features I consider so essential to my workflow that I cannot stand any system that lacks them.
A colleague of mine once destroyed a customer's system with a middle mouse button fat finger.
He was copying a listing all of the executables in various locations on the machine he'd created using ls -l, into a text document (logged in as root). Unfortunately, he accidentally middle-clicked while moving the mouse to the text editor, and it pasted everything into the shell.
Since it was mostly symlinks in the standard /bin /sbin /usr/bin /usr/sbin etc, the shell dutifully redirected garbage into each destination binary, rendering the OS unusable.
> Since it was mostly symlinks in the standard /bin /sbin /usr/bin /usr/sbin etc, the shell dutifully redirected garbage into each destination binary, rendering the OS unusable.
One of the terminal emulators I use, possibly the one that comes with lxqt that Lubuntu installs by default, pops up an "are you sure?" window showing exactly what I am about to paste whenever I middle-click-paste anything with a new-line. It can be disabled, but I found I quite like that extra check and would not mind if other applications did that.
It's the single greatest feature of any Unix desktop. Click and drag to select a section, or double click to select a word, or triple click to select a line, then middle click to paste. All without leaving the mouse or the touchpad. I buy laptops with physical mouse keys by the touchpad to middle click easily.
Any gesture-like feature is unintuitive if you don't take the time familiarize yourself with it. It's one of my absolute best UX improvement features in linux, I just wish it was available on other operating systems.
The problem is the middle paste option in Firefox.
To turn it off do as follow:
open a new tab
type: about:config
Accept the prompt
type middlemouse.paste
change value “true” to “false” (double click or switch on the rightside)
restart firefox
You can set clipboard.autocopy to false in about:config to disable this. It breaks the example, at least.
EDIT: I thought the behavior was preserved for textareas, as the comment box here still copied on select. But it suddenly disabled it here too. Restarting the browser is probably a safe bet :)
I should say, doing this only mitigates the middle-click-paste pastejack exploit. The underlying issue - JAVASCRIPT CAN ALTER WHAT YOU HAVE SELECTED AT WILL AND WITHOUT DETECTION - remains, and I believe we'll see other exploits pop up from this.
Say you're about to copy a crypto wallet. You have it selected, and are about to press CTRL-C to copy it. It is entirely possible for malicious code to detect that. And, as it turns out, it's possible for it to change the selection to a different (invisible) string, right as you press CTRL-C.
> For firefox running in Wayland, `writeXPrimary()` will only succeed
when the firefox window (the main window, not necessarily the tab the code
runs in) has the focus. Otherwise the selection will be cleared. At first I
assumed that this is something specific to the Wayland protocol, but that
turned out to be utterly false; it's just some quirk, bug or "feature"
specific to either firefox itself or GTK.
Most Wayland compositors will refuse clipboard requests from unfocused clients.
Additionally, the Wayland protocol carries an event identifier, so that the compositor can tie the clipboard request to a pointer/keyboard/touch event and take a better decision. (This metadata is missing for X11 clients, of course.)
> Additionally, the Wayland protocol carries an event identifier, so that the compositor can tie the clipboard request to a pointer/keyboard/touch event and take a better decision.
That's actually not the case. There's a serial number that the client provides when they want to set the selection (that is, cut/copy)[0][1], but nothing when a client requests a paste[2][3].
I always thought this is weird; while yes, it's nice to prevent random applications from spuriously taking over as the source of the clipboard/primary, I think it's much more important to have a mechanism to reduce the risk of a client pasting without permission.
Heh, just noticed your username, obviously you know what you're talking about.
I also misinterpreted what this issue was about; my mental assumption of "pastejacking" is when a malicious app grabs the (possibly sensitive) clipboard contents without the user knowing about it (which the Wayland protocol doesn't protect against via a serial number in the request)... but that's the opposite of this issue. And you're right, in this case a compositor could absolutely reject Firefox's set_selection() request here since any serial passed to it would probably be out of date.
And correct me if I'm wrong, but IIRC wlroots does make an effort to check that the serial passed is current enough.
My list of reasons to block all javascript by default grows longer by the day. 90% of websites don't need javascript at all to display the content I'm looking for, about 9% only require first party javascript, and the 1% left usually just gets me to close the tab and go somewhere else.
I'm embarrassed that I'm confused enough (ignorance about how webpages and javascript modern things, etc work) to not answer this on my own, but does this mean:
1) Beware! any site you visit can, via javascript, inject whatever it wants into your clipboard (write access)
2) Beware! any site you visit can, via javascript, do whatever it wants with your clipboard (READ and write access) <-- this would freak me out and require immediate opsec change on my part
3) some combination of the above.
4) something different.
I use exclusively Firefox (as opposed to any browser) and haven't touched wayland. I also only type on keyboards with a trackpoint and a middle click button, and have for the past few decades. Hence, I'm sure I make heavy use of all the various methods of accessing clipboards..
(I'm guessing it's closer to #1 than #2, I think I once saw a crypto address in my clipboard unexpectedly on a VM...)
Usually webpages cannot read the clipboard, and instead rely on the browser/os/whatever sending them its contents when the user ctrl+v or right-click-paste. It would then be received as a javascript event.
I said "usually" as an abundance of caution, I cannot say there isn't a browser out there that lets you read the clipboard. Or some kind of flaw. Or electron.
It's #1, but it's the primary selection, not the clipboard.
On Linux, there's the clipboard, which is the Ctrl+C/Ctrl+V that most people are familiar with.
There's also the "primary selection", which is the currently highlighted text. That selection can be pasted into a different app or text box with middle click. So you can really quickly do highlight, middle-click, highlight, middle click.
The primary selection is stored separately from the clipboard too, so it won't overwrite the contents of such.
But, because setting the primary selection is just selecting text, if JS selects text, then it sets the primary selection. Compare with the clipboard: JS cannot normally set the clipboard except in certain contexts (the OP goes into these).
Ah, whew. Write only. I used to make use of the difference between clipboard and cut buffer, intentionally using them both, but for a long time now I just run autocutsel in the background which keeps them in sync -- makes it easier to copy a region in emacs and move it into firefox, or vice versa.
It's one but for your primary instead of your clipboard. The JavaScript forces your selection so it affects the output of your Shift + Insert and middle click.
It's not. I have that disabled (mostly because I hate how GitHub completely mangles and fucks up anything I paste there) and it still works.
Arguably, it's "working as intended" because middle click is supposed to paste whatever is selected, and the JS did select some text. Fixing this in a way that won't cause UX regressions and can't be by-passed relatively easily might be rather tricky.
> [...] and the JS did select some text. Fixing this in a way that won't cause UX regressions and can't be by-passed relatively easily might be rather tricky.
One possible approach could be to ignore selections made by JS (instead of directly by the user) for middle click paste. A more refined approach could also allow them when made by JS while handling a mouse click from the user.
That will cause UX regressions in cases where text is selected by JS and you want to copy it, and leads to "this text is clearly selected but if I press middle click it pastes something else, wtf?!" kind of scenarios.
You can consider that to be an acceptable trade-off, but it is a trade-off.
… that they blocked the author's extension is like icing on this WTF cake.
This is absolutely a bug, and almost certainly a security bug. If you consider pastejacking the clipboard within the threat model that you want to account for, selection-jacking like this is absolutely within it, as it's a superset in terms of bad behavior.
(… but browsers have long maligned the primary selection on Linux. Neither Firefox nor Chrome have behaved properly for a long time, so it's not really surprising that they don't wanna when it comes to this bug. The primary selection is incredibly useful, but unique to Linux and even there, poorly understood amongst its userbase due to being a bit tricky to discover.)
Oh man. All I've used Linux on was a ThinkPad, and so I quickly discovered that MMB pasted. But I assumed it was just pasting from the clipboard. This explains so many times when what I Ctrl-C'd and what I MMB'd weren't the same and I naively chalked it up to mistyping or a bug in some software or anything else.
> browsers have long maligned the primary selection
Not just browsers, users also rightfully malign the primary selection. I highlight text for all sorts of reasons (including because I already have something that I want to paste).
Take this logic one step up: it's X11 which is allowing applications to set the middle click buffer. X11 should only be allowing that to be set from direct user-interaction as any application could be nefariously setting it.
There was no link in the mailing list post or any of its replies.
As of right now, there is no link in a HN comment.
I tried hard but could not find a relevant bug on Bugzilla, but that could be because security-related issues are typically kept under wraps until the details are safe to be publically revealed. At least that was the case for the one I submitted a few years ago; as the submitter, I can see it when I'm logged in, but it doesn't show up on anonymous searches.
If Mozilla's stance on this really is as described in the mailing list, I would very much like to add a dissenting opinion. This is clearly a security issue that needs addressing. If the clipboard buffer needs special protection, so does the primary selection buffer.
Whether most people like or dislike copy/pasting this way is irrelevant. Some people use it. The other browsers on X11 are properly protected. Even Edge on Linux gets it right. Firefox is the odd one out here and they should fix it.
Especially these days, where install instructions on web pages often look like this:
194 comments
[ 3.3 ms ] story [ 221 ms ] threadyou already decided to hit enter while you are selection something, could be just a bit above your current cursor in the terminal
Gnome shell doesn't AFAIK.
It's an odd thing to protect from; any program that has access to the X11 clipboard is going to be able to run a process as the current user.
[0] https://en.m.wikipedia.org/wiki/Bracketed-paste
If I select some text and press Ctrl+C, it should copy the text I selected. The user intent is obvious. There's no excuse for the ability to hijack the clipboard to exist in the first place.
Web pages shouldn't be able to modify my selection. Why is there even an API for this?
The web ecosystem (including browsers) turned straight up malicious like 15 years ago, and users became nothing more than a product for everyone involved. That cancer has even metastasized and spread to the OS or even products that people pay thousands or tens of thousands of dollars for. I don't know how people who think that way can live with themselves.
To make “copy to clipboard” buttons possible.
On my phone, if I select text, my browser pops up a menu with "copy" as an option.
Why does a web page need to reinvent that wheel?
For the 1/10000000 case where it makes sense, how about a "X page wants to modify your clipboard" dialog? This has been a known security vulnerability for at least a decade.
Edit: actually, I just noticed that was a reply to selection, which makes even less sense. Just let the user select what they want.
The user tells their computer to do a simple thing, and the computer adversarially does not do that thing, and instead obeys someone else, intentionally. That should not happen.
If you went to a scissor factory and told them that their scissors were too sharp, they might at least think of doing a run of safety scissors. If you go to a tailor and suggest that, they will probably be confused and not very receptive.
Or if instead of things like the sawstop, we made power saws that sometimes just flip open the guard and swing the blade to toward the user. But there's a safety to prevent that, but it disengages whenever you start the saw, so you need to reengage it every time you cut something in-between starting the saw and actually cutting.
In a following snippet, the terminal scrolls 100 lines and prints no prompt, so a user is tempted to press Enter just to check what's going on. You can count this as a form of phishing, if you want.
But I don't recall Firefox ever being hardcore security and privacy (even though some of their techies are). For Mozilla, that's a fairly recent positioning that they're growing into.
Initially, there was competition to be the most popular browser.
But most of the history is a constant movement towards having the browser facilitate what companies wanted to do towards users (moving away from the "user agent" as an agent of the user).
In parallel, Google paying Mozilla for placement, and then possibly to keep a nominal competitor alive.
In recent years, Mozilla has been positioning itself as one of the champions for Internet freedom, and I assume that some of their people were that all along (e.g., the kind who could've gone to Google, but chose to work for much less money at Mozilla). Though I don't know how genuine that sentiment is from the top, when leadership draws huge compensation, for poor performance, while laying off techies. (Techies traditionally have lead Internet freedom, from the ground, up, and leadership might be better thought of as a humble support system for that.)
More on topic, this works fine within the trusted green zone of local desktop applications. but the browser is(or should be) a high security zone. with a really tricky security policy. which to paraphrase would be "Allow passing information to the rest of the os. but only as a result of a direct user request." You don't really want to disallow the browser to script selecting anything, this is useful for editors. but you probably want to maintain a flag on that selection as to if it was done by the user or not.
Well there is my useless pedantry for the day done. My apologies and thank you for letting me get that off my chest.
Lose selection === unable to copy. And it's at all times up to source app to decide what it will allow to be copied.
There are even examples using terminal escape codes, to hide what happened.
https://www.reddit.com/r/privacy/comments/rv964x/comment/hr4...
[1] - https://thejh.net/misc/website-terminal-copy-paste
A solution is bracketed paste[1] as mentioned in earlier comments[2], which would allow the user to examine a pasted command before running it.
[1] https://en.wikipedia.org/wiki/Bracketed-paste
[2] https://news.ycombinator.com/item?id=37966924
and that editor should not be running "inside" a terminal
-- or rather I don't understand why those that like interacting with their editor via a terminal interface don't create a new protocol that doesn't have the warts and vulnerabilities the current ancient protocol has.
e.g. Vim creating their own protocol is rather pointless if no terminal implements it, and some terminal creating their own protocol is also rather pointless without application support.
Plus there's tons of software out there and it'll take a long time for it all to be rewritten, if that ever happens. e.g. X11 will still be around for a long time as well. So you will need to remain compatible with the current protocol even if you invent something new and better, and in that sense it doesn't really fix anything., at least not right now. It might fix stuff 15 years down the line, maybe, but in-between now and 15 years everything will be more complex by having two protocols.
And all things considered, it's not that bad, IMHO. There's the KiTTY Keyboard protocol to solve some obvious UX issues with keyboard handling, which is a clear improvement and motivation, whereas some exploit vectors that don't really see live exploits isn't really.
The hairiest Emacs Lisp code I know about is the code for responding to mouse actions, e.g., clicking and dragging, and most Vim users don't even want to use a pointing device to interact with Vim IIUC. (In contrast, 80% of Emacs users who responded to a survey do not interact with Emacs through a terminal interface.)
For example, the old scripting language Tcl has its own GUI toolkit named Tk that has a pretty good reputation.
>And all things considered, it's not that bad
It seems bad enough to me to be worth re-architecting.
But in a terminal all code runs in that terminal, and terminal programs don't "link against" a terminal in the same way that you do with a GUI toolkit. You need to implement a shared protocol on both ends.
So I suppose we're not very far from this not being a problem in general.
Though I understand this also works via control codes. I hope Tilix is smart enough to filter them out from the clipboard before doing this..
edit: I tested that case out, and it works. I suppose the protocol uses quoting.
What do you mean?
> For firefox running in Wayland, `writeXPrimary()` will only succeed when the firefox window (the main window, not necessarily the tab the code runs in) has the focus. Otherwise the selection will be cleared. At first I assumed that this is something specific to the Wayland protocol, but that turned out to be utterly false; it's just some quirk, bug or "feature" specific to either firefox itself or GTK.
> But I think that's still bad enough, even if the page should take care to only set the selection when the main window has gained focus.
To those wondering who would paste and execute without a second look, there are ways to hide text. You can also paste control characters, so if you pasted into vim the command would get executed without any visible feedback. Same could be true for emacs, someone who knows it better could pipe in.
Any time you run potentially malicious code (like clicking on a random link when you have javascript enabled) on the same computer as data you care about, you're taking a risk. Sandboxing is a compromise, but one that's usually worthwhile.
I believe Emacs differs in two relevant ways, both not technically inherent: command prefixes are by default non-printable, and it's relatively uncommon to run Emacs without GUI.
Just tried `echo -en '\x18\x03' | xclip`.
Emacs in the default GUI mode works as expected, just pastes ^X^C (that's two control characters, they are just rendered this way) into the buffer.
xfterm4 or gnome-terminal pastes Unicode Control Pictures [1] (TIL there's such a thing) ␘␃, the same in bash, cat or `emacs -nw`.
Finally, bash in xterm echoes the control characters raw, but Emacs once again manages to get ^X^C in the buffer.
[1] https://en.wikipedia.org/wiki/Control_Pictures
https://unix.stackexchange.com/questions/24330/how-can-i-tur...
What sucks is I use middle click paste all the time so now I'll have to decide if I want to leave it disabled for potentially improving security.
I've also set dom.event.clipboardevents.enabled to false since I don't want websites messing with the clipboard.
And a much worse attack exists: you copy e.g. shell code from the page, and instead of what you see, you paste something evil in your terminal.
Pages stealing your current middle-mouse-paste selection, however, only requires selecting text in another place, and it seems like the only way to defend against this is by not selecting text. Which, at least for me, is not really feasible.
Edit: did y'all miss the smiley at the end of my comment?
I was not looking for this as a feature when I bought one a few years ago but it had them and it has proved the thing I like about the machine the most.
And it is the absolute most comfortable mouse I've ever used.
Having a single mouse button (that often has other functionality like autoscroll in Firefox) cause text highlighted in another app to paste in the focused app is super unintuitive to me, and caused a few significant annoyances unintentionally pasting secrets or private messages in the wrong place before I got rid of it.
I do agree that overloading the button is terrible. I like the scroll wheel but wish there was a separate middle button. And I loathe middle button auto scroll, I regard it as a useless, user hostile feature.
That’s why I felt it was a bad default.
"Other than that, Mrs. Lincoln, how was the play?"
I didn't know wayland doesn't support that either, one more thing to add to the list of things it doesn't support like screenshots, xclip, mouse/keyboard automation, etc...
It's fine to dislikes it; everyone dislikes some features (e.g. personally I really dislike autoscroll). The thing is that it's not "unexpected" because it's been like this for >30 years, since the 80s. Nor is there anything wrong with it: it's just something you can like or dislike.
Or to put it in another way: if I wanted my Unix system to behave like Windows or macOS then I'd be using Windows or macOS.
Can't talk about the others as I don't use them.
https://github.com/bugaevc/wl-clipboard
$ cat ~/bin/clip
Grim for screenshots, slurp for selection (similar to maim). wl-clipboard works like xclip with its wl-copy and wl-paste commands, I use it extensively in scripts. There is ydotool (not to be confused with xdotool) for kb/m automation. Highlight + middle click paste also works as expected and I use that many times a day. Primary selection is also available to wl-clipboard with a -p arg for both copy and paste.
t. actual daily Sway user for several years now
It's insane to me how much misinformation is spread about Wayland by people who just don't even try it. I guess people want to hate it.
I suspect it didn't work at one point and then people ditched it and have that as their memory. I tried to switch to sway, a bunch of stuff didn't work like I expected and I just switched back to i3, this was probably 3-4 years ago at this point.
I assume it's probably gotten better, so I don't go around commenting. But I fully believe people did try it and it didn't work for them (at some point) and they just ditched it.
Then I try to middle click autoscroll in discord or something (which works in windows!) and I’ll paste in information that I don’t intend to.
This is the first I’m hearing about Wayland fixing this. Maybe I’ll give Wayland yet another try soon.
You can fix this in the latest working firefox version with `about:config > middlemouse.paste = false` (I found this by browsing through about:config, so I'm not sure if it's decumented anywhere), but I'm not sure if that still works in the enshittified versions.
(It doesn't prevent selected text from being middle-pasted into other applications, but all my other disrupted-by-paste applications explicitly don't support middle-click-to-paste (in several cases because I deliberately wrote them that way), so I haven't gotten around to fixing that part yet.)
But this “feature” is enabled globally across XServer and is so deeply engrained that there is no global off switch. I must find workarounds for every application in order to make my middle mouse click function as I would expect.
For an OS where everything else is so customizable this baffles me.
I so frequently encounter problems where I proofread something (or my compiler finds it for me) and I find weird words or sentence fragments that I inserted on accident while navigating a document.
We're having a conversation in this thread about whether or not the feature is good, but it shouldn't matter. People who like the behavior and people who don't should be able to live side by side, without one affecting the other. The issue is that the feature should not be forced.
Also, "no modes" is both a question of personal preference and a sliding scale. Input-has-focus is a mode, too, but getting rid of that would be an obvious mistake.
I hardly ever touch the mouse, but if I am using it then I'm most likely copying and pasting. Don't make that difficult.
All trackpads I've tried support middle click via a three-finger tap.
https://www.notebookcheck.net/Review-HP-ZBook-15-Workstation...
I disabled tap to click and all gestures except two finger scrolling.
https://superuser.com/questions/90257/what-is-the-difference...
https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...
When I'm reading a long article, my usual strategy is to middle-click and then move the mouse to a position that causes the page to move in time with my reading speed. The continuous movement is a lot easier for my eyes to track than occasional bursts of scrolling, and I can tweak the scroll speed by subtly adjusting the mouse position. It's a bit like cruise control for scrolling.
I'm not saying you ought to use it, but you're decrying it as "not user-friendly" and "not needed" when what you really mean is "I don't like it" and "I don't use it".
Windows now has clipboard history by pasting with Win+V, having the best of both worlds.
I'm sorry you can't adapt, but honesty no one cares =)
What’s problematic with the Firefox behavior is that content gets copied (pasted) that wasn’t selected by the user.
The patch here would not help security at all. Only using control-x control-e before pasting (so that it comes into a real editor, not directly in the terminal) can help.
Invisible text can add to what you selected, but it can’t replace it.
There’s also an argument to be made that invisible text shouldn’t be copied, though that’s harder to define precisely (you don’t want to copy “display: none”, but you want to copy scrolled-out content).
Also in Mintty: https://mintty.github.io/mintty.1.html#%03Text%20selection,%...
Of course that means I also don't have a horse in the "What should middle click do race".
You can bind a keyboard shortcut to a script that copies the primary to clipboard, then can use ctrl-v. Most apps also bind shift-insert to paste the paste buffer, so I bind shift-delete to this script, then to paste the primary it's just shift-delete then shift-insert. Here's the "script":
Tried a few solutions but they didn't work on Wayland (as most of them were xinput hacks).
I didn't experience such accidental pastes when I had Windows installed.
In places where this doesn't work, clipboard history is an okay replacement (if you need multiple things "transported").
Copying should always be deliberate, not something that blasts out your clipboard when you click in the wrong place and select something unintentionally. And middle click is for opening tabs.
This isn't helped by the fact that the mainstream desktop OSes don't have proper clipboard managers bundled by default. Accidentally copying something isn't as big a deal when you have the most recent 200 items you've copied in an easily searchable widget.
Poor API design and the inability for APIs like the clipboard to evolve are part of the reason why desktop Linux's security keeps falling behind other operating systems.
Either way, I'm pretty sure it could be added if someone cared enough, e.g. by adding a new target.
It just seems to me that if someone is able to access your clipboard history you've lost already, and the entire feature seems more of a convenience thing than a security thing.
Win32: https://learn.microsoft.com/en-us/windows/win32/dataxchg/cli...
WinRT: https://learn.microsoft.com/en-us/uwp/api/windows.applicatio...
>Either way, I'm pretty sure it could be added if someone cared enough
That's the problem. Ironically, not enough people care about improving the security and privacy of desktop Linux.
>It just seems to me that if someone is able to access your clipboard history you've lost already
Do you not see how it could be problematic if sensitive things were logged and persisted to disk?
Edit: Some clipboard managers on Linux do have an undocumented way to do this by adding an additional format to what's being copied with a MIME type set to x-kde-passwordManagerHint and data set to "secret".
And your link just shows some programmatic access? How do I access that as a user when I press Ctrl+C? I suppose it's "useful" for things like password managers, but since anything can read the clipboard anyway it's a very limited protection. If something is so sensitive that you're using that special programmatic way of storing it then you should be using the clipboard but an actually secure mechanism.
Learning that you can middle click on the back/forward/refresh buttons to open the previous/next/current page (respectively) in a new tab was a game changer for me
However it's a nightmare when you use a mix of OSes every day as I do :(
He was copying a listing all of the executables in various locations on the machine he'd created using ls -l, into a text document (logged in as root). Unfortunately, he accidentally middle-clicked while moving the mouse to the text editor, and it pasted everything into the shell.
Since it was mostly symlinks in the standard /bin /sbin /usr/bin /usr/sbin etc, the shell dutifully redirected garbage into each destination binary, rendering the OS unusable.
One must be root to be able to do that.
It's copy that's an exploit vector.
To disable it, set clipboard.autocopy to false.
Sometimes you want some custom patches to suit your needs, then, well.. yeah, it takes some manual work.
EDIT: I thought the behavior was preserved for textareas, as the comment box here still copied on select. But it suddenly disabled it here too. Restarting the browser is probably a safe bet :)
Say you're about to copy a crypto wallet. You have it selected, and are about to press CTRL-C to copy it. It is entirely possible for malicious code to detect that. And, as it turns out, it's possible for it to change the selection to a different (invisible) string, right as you press CTRL-C.
Most Wayland compositors will refuse clipboard requests from unfocused clients.
Additionally, the Wayland protocol carries an event identifier, so that the compositor can tie the clipboard request to a pointer/keyboard/touch event and take a better decision. (This metadata is missing for X11 clients, of course.)
That's actually not the case. There's a serial number that the client provides when they want to set the selection (that is, cut/copy)[0][1], but nothing when a client requests a paste[2][3].
I always thought this is weird; while yes, it's nice to prevent random applications from spuriously taking over as the source of the clipboard/primary, I think it's much more important to have a mechanism to reduce the risk of a client pasting without permission.
[0] https://wayland.app/protocols/wayland#wl_data_device:request... (regular clipboard)
[1] https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection)
[2] https://wayland.app/protocols/wayland#wl_data_offer:request:... (regular clipboard)
[3] https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection)
I also misinterpreted what this issue was about; my mental assumption of "pastejacking" is when a malicious app grabs the (possibly sensitive) clipboard contents without the user knowing about it (which the Wayland protocol doesn't protect against via a serial number in the request)... but that's the opposite of this issue. And you're right, in this case a compositor could absolutely reject Firefox's set_selection() request here since any serial passed to it would probably be out of date.
And correct me if I'm wrong, but IIRC wlroots does make an effort to check that the serial passed is current enough.
1) Beware! any site you visit can, via javascript, inject whatever it wants into your clipboard (write access)
2) Beware! any site you visit can, via javascript, do whatever it wants with your clipboard (READ and write access) <-- this would freak me out and require immediate opsec change on my part
3) some combination of the above.
4) something different.
I use exclusively Firefox (as opposed to any browser) and haven't touched wayland. I also only type on keyboards with a trackpoint and a middle click button, and have for the past few decades. Hence, I'm sure I make heavy use of all the various methods of accessing clipboards..
(I'm guessing it's closer to #1 than #2, I think I once saw a crypto address in my clipboard unexpectedly on a VM...)
Usually webpages cannot read the clipboard, and instead rely on the browser/os/whatever sending them its contents when the user ctrl+v or right-click-paste. It would then be received as a javascript event.
On Linux, there's the clipboard, which is the Ctrl+C/Ctrl+V that most people are familiar with.
There's also the "primary selection", which is the currently highlighted text. That selection can be pasted into a different app or text box with middle click. So you can really quickly do highlight, middle-click, highlight, middle click.
The primary selection is stored separately from the clipboard too, so it won't overwrite the contents of such.
But, because setting the primary selection is just selecting text, if JS selects text, then it sets the primary selection. Compare with the clipboard: JS cannot normally set the clipboard except in certain contexts (the OP goes into these).
(Well, technically, it doesn't actually "inject" anything, it just changes the selection, and arguably it's "working as intended").
Arguably, it's "working as intended" because middle click is supposed to paste whatever is selected, and the JS did select some text. Fixing this in a way that won't cause UX regressions and can't be by-passed relatively easily might be rather tricky.
One possible approach could be to ignore selections made by JS (instead of directly by the user) for middle click paste. A more refined approach could also allow them when made by JS while handling a mouse click from the user.
You can consider that to be an acceptable trade-off, but it is a trade-off.
This is absolutely a bug, and almost certainly a security bug. If you consider pastejacking the clipboard within the threat model that you want to account for, selection-jacking like this is absolutely within it, as it's a superset in terms of bad behavior.
(… but browsers have long maligned the primary selection on Linux. Neither Firefox nor Chrome have behaved properly for a long time, so it's not really surprising that they don't wanna when it comes to this bug. The primary selection is incredibly useful, but unique to Linux and even there, poorly understood amongst its userbase due to being a bit tricky to discover.)
Not just browsers, users also rightfully malign the primary selection. I highlight text for all sorts of reasons (including because I already have something that I want to paste).
I tried hard but could not find a relevant bug on Bugzilla, but that could be because security-related issues are typically kept under wraps until the details are safe to be publically revealed. At least that was the case for the one I submitted a few years ago; as the submitter, I can see it when I'm logged in, but it doesn't show up on anonymous searches.
If Mozilla's stance on this really is as described in the mailing list, I would very much like to add a dissenting opinion. This is clearly a security issue that needs addressing. If the clipboard buffer needs special protection, so does the primary selection buffer.
Whether most people like or dislike copy/pasting this way is irrelevant. Some people use it. The other browsers on X11 are properly protected. Even Edge on Linux gets it right. Firefox is the odd one out here and they should fix it.
Especially these days, where install instructions on web pages often look like this:
EDIT: As per the author's GitHub issues, the bug report is indeed still hidden:https://bugzilla.mozilla.org/show_bug.cgi?id=1855345
https://github.com/turistu/odds-n-ends/issues/1#issuecomment...