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
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...
Answer
#2: Post edited
- 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
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.