Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
What are the security or privacy implications of browser clipboard events?
For context, I use Firefox to browse the Web. Some time ago, I followed some security- and privacy-oriented advice for configuring Firefox, which recommended (among many other things) disabling the dom.event.clipboardevents.enabled setting.
My understanding is that this prevents the browser from generating events when content is cut, copied or pasted from/to a text field on the page. I further understand that JavaScript on the page can respond to these events, but for security reasons, the browser does not otherwise allow JavaScript code to access the clipboard. But existing information I can find on this topic all seems to be at least a decade old.
In practical terms, it seems that disabling the setting prevents some web pages from blocking attempts to copy page text, or from modifying the text that is put on the clipboard e.g. to include ad links back to the site. However, it also seems to prevent or interfere with pasting text into certain web apps, including Twitch and Discord.
I'm trying to decide how to approach this setting. Do clipboard events entail any kind of security or privacy risk, generally speaking, in modern environments? For example, if I paste into an app on one browser tab, could that information leak to other tabs? If not, I think I will find it more practical to leave events enabled by default, and only temporarily disable them when they cause a problem.
1 answer
It's hard to comment definitively on this because both attack vectors and countermeasures evolve rapidly.
My guess would be that Firefox would not allow tab X to see that you copied something on tab Y. It's a DOM method so presumably it is specific to that page. This would also be the only logical design: Many pages let you copy some secret, and letting tabs see each other's clipboard events would completely break the security of that. For example, sites which generate an API token and make you copy it. It would also potentially create a vulnerability for people who use password managers.
With things like frames and other ways of embedding cross-site content, there might be an exploit depending on how exactly those are handled by that particular version of that browser. But this also seems like an obvious thing that is probably already secured by FF devs, or will be soon.
I think the biggest impact of dom.event.clipboardevents.enabled is that some idiot webmasters use it to block copy/paste to stop you from "stealing their content" or force you to type fields in sign up forms instead of pasting. Disabling this seems like a neat way to prevent some of this monkey business. I notice that when people do this, they usually hook into the clipboard copy/paste event with JS on the input.
For some reason, many webdevs have some obsession with reimplementing basic things like HTML elements. For example, instead of using <input type="text"> that is already natively supported by the browser and has correct integration with the OS, they will reimplement their own JS text box with JS events watching key presses, rendering, etc. This happens more in bloated, large companies so I theorize that the webdevs are doing make works to keep their manager from realizing they don't need to pay that many developers because there isn't that much coding to do. They probably justify it by pointing to some tiny customization that input doesn't support (often with good reason, sometimes it actually does support it but the people involved don't realize or are pretending not to), but their reimplementation does (at the cost of much greater maintenance burden and everything else being much worse). I can see how the scope of this reinvention of the wheel will sometimes encompass the clipboard as well, and it's not outside the question that their reimplemented input element won't fail gracefully without clipboard access. So I can see how over time, you will run into some websites that are developed in so exquisitely incompetent a way that their inputs become unusable when you disable the clipboard events. It is up to you if you want to boycott these sites, use a second browser for them, switch the settings on temporarily, or keep it on.
0 comment threads
0 comment threads