12 ms·
With Firefox on X11, any page can pastejack you anytime (middle button paste)
- Zetobal 3y agoWho pastes something and executes it without a second look?
- throwaway71271 3y agothats 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
- whatwhaaaaat 3y agoHave you never pasted a new line?
- jowea 3y agoThere are terminals that have protections against that AFAIK.
- kzrdude 3y ago`set enable-bracketed-paste on` in .inputrc (at least compatible with bash, terminal also needs support)
- paulddraper 3y agoI'm sure they exist. 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.
- bilkow 3y agognome-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 [0] https://en.m.wikipedia.org/wiki/Bracketed-paste https://en.m.wikipedia.org/wiki/Bracketed-paste
- paulddraper 3y agoThanks
- jowea 3y agoPeople 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.
- ndriscoll 3y agoWhy 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.
- xigoi 3y ago> Web pages shouldn't be able to modify my selection. Why is there even an API for this? To make “copy to clipboard” buttons possible.
- dotancohen 3y agoDoes not sound like a worthwhile trade-off.
- ndriscoll 3y agoI 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.
- xigoi 3y agoWhen 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.
- teo_zero 3y agoIf 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.
- Zetobal 3y ago#
- knickersniffer 3y agoNo it does not scroll. Run bash in script(1) then check the typescript.
- c7DJTLrn 3y agoI 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.
- neilv 3y agoI 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.)
- polpo 3y agoThere 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.
- somat 3y agoNot 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.
- b112 3y agoYou should always paste into an editor first, just copying any text from a webpage is a risk. There are even examples using terminal escape codes, to hide what happened. https://www.reddit.com/r/privacy/comments/rv964x/comment/hr4z1fv/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/privacy/comments/rv964x/comment/hr4...
- LinuxBender 3y agoAdding to the demo here is one using CSS [1] [1] - https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste
- gwnywg 3y agoI 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?
- Krasnol 3y agoI paste into address bar to remove formatting etc.
- marbu 3y agoUsing terminal which can detect control characters in a pasted text will (partially) help here as well. Eg.: rxvt-unicode has confirm-paste plugin: https://wiki.archlinux.org/title/rxvt-unicode#Confirm_paste https://wiki.archlinux.org/title/rxvt-unicode#Confirm_paste
- omoikane 3y agoThe 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. [1] https://en.wikipedia.org/wiki/Bracketed-paste https://en.wikipedia.org/wiki/Bracketed-paste [2] https://news.ycombinator.com/item?id=37966924 https://news.ycombinator.com/item?id=37966924
- deleted 3y ago[deleted]
- superkuh 3y agoThis does not require javascript to be running either, that surprised me. But it's not that big of an issue.
- jwilk 3y ago> This does not require javascript to be running either What do you mean?
- superkuh 3y agoI 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.
- pkulak 3y agoWell yeah, this is one of the core issues that Wayland was built to address. X11 has zero security.
- Wowfunhappy 3y agoThis 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.
- arp242 3y agoIt'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.
- paulddraper 3y agoThis has nothing to do with X11, and everything to do with Firefox (on X11).
- dolorian 3y agoI 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.
- owl57 3y ago> 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. [1] https://en.wikipedia.org/wiki/Control_Pictures https://en.wikipedia.org/wiki/Control_Pictures
- talent_deprived 3y agoFor 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: https://unix.stackexchange.com/questions/24330/how-can-i-turn-off-middle-mouse-button-paste-functionality-in-all-programs 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.
- joveian 3y agoThat 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.
- deleted 3y ago[deleted]
- itvision 3y agoThis has been known for at least a decade or two already. 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.
- sshine 3y agoThis is another exploit that relies on ‘display: none’.
- elric 3y agoI 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.
- jklinger410 3y agoMiddle mouse paste is broken in GTK. Glad someone pointed it out, I hope it gets fixed
- demondemidi 3y agoYou guys have a middle button? Maaaan. :) Edit: did y'all miss the smiley at the end of my comment?
- syntaxing 3y agoYour scroll wheel click is a “middle button”
- somat 3y agoThe 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.
- cesarb 3y agoSome 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.
- tannhaeuser 3y agoOn 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.
- gpvos 3y agoThat is a strong recommendation for me! I really hope three-button mice (no scrollwheel) will make a comeback.
- dotancohen 3y agoYou might like the Evoluent vertical mouse. The scrollwheel and the middle mouse button are separate. And it is the absolute most comfortable mouse I've ever used.
- forward1 3y agoSince when is openwall hosted in Russia? I only know because RU IP space is blocked at my gateway. Kind of ironic.
- macNchz 3y agoThe 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.
- somat 3y agoConversely 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.
- foobarian 3y agoMeanwhile 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.
- Aardwolf 3y ago
- SubiculumCode 3y agoThe 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 --does this solve it?
- layer8 3y agoWhy do you bother writing this up without even testing it?
- SubiculumCode 3y agoidk, maybe because I'm not on my linux server on the weekend at the river, and wanted to know. go have coffee or something, you're acting grumpy
- torgard 3y agoNo, that's only for pasting specifically. It's copy that's an exploit vector. To disable it, set clipboard.autocopy to false.
- naruhodo 3y agoThat doesn't do anything.
- ajsnigrutin 3y agoGentoo is great! cd /etc/portage/patches/www-client/firefox/ nano nomiddleclickhijack.patch #paste patch, save emerge -av firefox
- dysoco 3y agoI mean sure but what happens when you have a bunch of patches and updates for the package and it becomes a mess of merge conflicts?
- ajsnigrutin 3y agoWe know if this issue now, when it's fixed, you can remove the patch. Sometimes you want some custom patches to suit your needs, then, well.. yeah, it takes some manual work.
- pritambaral 3y agoDoesn't work on my KDE setup. Turned out I'd set the option to disable copy-via-selection in Klipper.
- deleted 3y ago[deleted]
- torgard 3y agoYou 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 :)
- prima-facie 3y agoThis is very useful, thanks. With a clipboard manager like Clipman you can tick 'Ignore mouse selections'.
- torgard 3y agoI 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.
- emersion 3y ago> 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.)
- kelnos 3y ago> 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. [0] https://wayland.app/protocols/wayland#wl_data_device:request:set_selection https://wayland.app/protocols/wayland#wl_data_device:request... (regular clipboard) [1] https://wayland.app/protocols/primary-selection-unstable-v1#zwp_primary_selection_device_v1:request:set_selection https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection) [2] https://wayland.app/protocols/wayland#wl_data_offer:request:receive https://wayland.app/protocols/wayland#wl_data_offer:request:... (regular clipboard) [3] https://wayland.app/protocols/primary-selection-unstable-v1#zwp_primary_selection_offer_v1:request:receive https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection)
- emersion 3y agoBy "clipboard request", I meant "request to set the clipboard".
- mcpackieh 3y agoMy 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.
- loxias 3y agoI'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...)
- codedokode 3y agoWebsites cannot read clipboard unless you press Ctrl + V, if I remember correctly. The same should apply to any Wayland application.
- tuetuopay 3y agoFrom what I gathered in the article, it's #1. 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.
- loxias 3y agoOk, thanks. That matches my model of the world. You said "usually", are there any particular exceptions you have in mind?
- tuetuopay 3y agoI 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.
- 3y ago
- everdrive 3y agoHow is this affected by settings in Firefox to prevent sites from reading the clipboard?
- arp242 3y agoIt'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.
- cesarb 3y ago> [...] 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.
- arp242 3y agoThat 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.
- deathanatos 3y ago… 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.)
- deleted 3y ago[deleted]
- JellyBeanThief 3y agoOh 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.
- kibwen 3y ago> 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).
- idbehold 3y agoTake 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.
- jdashg 3y agoIs there no link to a Firefox bug report for this, or am I just missing it?
- motleyhatch 3y agoThere 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: curl -o- https://example.com/trust/me/install.sh | sudo bash 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://bugzilla.mozilla.org/show_bug.cgi?id=1855345 https://github.com/turistu/odds-n-ends/issues/1#issuecomment-1766941170 https://github.com/turistu/odds-n-ends/issues/1#issuecomment...
- nativeit 3y agoThis might be too controversial to say here, but I have no strong opinions on middle-click behavior one way or another.
- elric 3y agoTIL that middle-click pasting is a controversial feature. I guess people really can argue over anything.
- throwawaaarrgh 3y agoFirefox tends to have worse security by default than other browsers so this isn't a surprise to me. Most browser exploits are delivered by JavaScript, so the safest course of action is to use NoScript judiciously, run the browser in a VM, and pray.
- SpaghettiCthulu 3y agoIs there any benefit to using NoScript's JS blocking over uBlock Origin's?
- hulitu 3y ago> In firefox running on X11, any script from any page can freely write to the primary selection, and that can be easily exploited to run arbitrary code on the user's machine. This is a problem with web browsers. They shall not run untrusted code from the internet. But we are now in the stage "oh, cool, i can access my USB from internet".
- sfphoton 3y agoNo, Firefox doesn't technically run anything on your machine. It is only that some scripts can write shell code into the "middle click buffer" which the user can unintentionally execute later.
- PurpleRamen 3y agoIt's the browsers job to run untrusted code, this is why there are sandboxes and all kind of security-mechanism. This case is about a questionable intentional hole in the sandbox, which can be used for a social engineering-attack. Inject some code in a text-buffer, and hope that the user will execute it, and not see the malicious part. Not the biggest attack-vector, but an annoying one, which should be able to fixed easily.
- mlipmlopmlup 3y agoexcept that 1. it's not intentional 2. no social engineering is necessary to exploit it and 3. it's not so easy to (properly) fix it. you'll have to rewrite some shoddy '90-style c++ code with 0 test coverage code from scratch. and oh I forgot 4. there's no buffer, either.
- dllthomas 3y agoAn interesting thing about X11 pasting is that the way it's implemented (a request to the server to send a request event to the owner of the selection in question) the place you're pasting from can actually see who is requesting the info and could make decisions based on that (even prompting for verification). I always thought that would be a great security feature for a password manager, though I don't know if any actually do it.
- m463 3y agowhy can the browser work with copy/paste and intercept keys in the first place? I would like to turn all that completely off.