Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Post History

62%
+3 −1
Q&A What are the security or privacy implications of browser clipboard events?

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 t...

posted 9mo ago by matthewsnyder‭  ·  edited 9mo ago by matthewsnyder‭

Answer
#2: Post edited by user avatar matthewsnyder‭ · 2024-03-03T17:06:17Z (9 months ago)
  • 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 `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.
  • 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.
#1: Initial revision by user avatar matthewsnyder‭ · 2024-03-03T17:01:13Z (9 months ago)
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 `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.