You can disable it on Firefox by setting dom.event.clipboardevents.enabled to false. I haven't had any issues with it.
Someone shared the code in the comments, it uses 'copy' and 'cut' event listeners, so disabling this setting would have prevented the exploit regardless of an adblock.
dom.event.clipboardevents.enabled=false removes the non-consensual clipboard read access, which is an enhancement but not a strict requisite for attacks of this type. The utility of the other events boils down to mostly convenience: The website can still indirectly observe how you use the clipboard, even when not explicitly notified. The website also remains in control of the CSS properties that can be used to create a meaningful difference between user selection and resulting clipboard content after copying.
And, crucially, (blindly) overwriting the clipboard is still permitted.
It prevents event dispatch, upon which this exploit relied. The same could be achieved without listening to clipboard events, in which case the setting would be insufficient. I'm not sure there is a way to fully prevent clipboard manipulation in the browser.
Nor USB devices, nor the screen size, nor ... They can access way too many parts of the OS. But almost nobody cares, as long as they have their shiny feeds and videos.
If copy and paste is disabled in my default browser that would be something like 80% of my total of my total use cases for the clipboard in the first place.
They're not saying your manual copy/pasting from a browser window onto your clipboard shouldn't be possible; they're saying the browser itself shouldn't allow this functionality to be scriptable internally.
The former is a system event, not a browser one.
This is similar to how on google docs if you try to copy via the edit menu, it pops up to say use Ctrl-C instead.
Honestly, I too am surprised a JavaScript plugin was able to access and alter the system clipboard in the first place too.
You can disable it on Firefox by setting dom.event.clipboardevents.enabled to false. I haven't had any issues with it.
Someone shared the code in the comments, it uses 'copy' and 'cut' event listeners, so disabling this setting would have prevented the exploit regardless of an adblock.
dom.event.clipboardevents.enabled=false removes the non-consensual clipboard read access, which is an enhancement but not a strict requisite for attacks of this type. The utility of the other events boils down to mostly convenience: The website can still indirectly observe how you use the clipboard, even when not explicitly notified. The website also remains in control of the CSS properties that can be used to create a meaningful difference between user selection and resulting clipboard content after copying. And, crucially, (blindly) overwriting the clipboard is still permitted.
It prevents event dispatch, upon which this exploit relied. The same could be achieved without listening to clipboard events, in which case the setting would be insufficient. I'm not sure there is a way to fully prevent clipboard manipulation in the browser.
It's you versus Google on that one. Who will win?
Well, it's not just him.
It's Google versus Mankind.
Mankind will eventually prevail against Evil. Google pissed off too many people now, you only need to look at reddit's degoogle subreddit.
> you only need to look at reddit's degoogle subreddit
A drop in the ocean…
Google is constantly rushing from growth record to growth record in the last years.
Never in history has good prevailed over evil for more than a short time.
12 replies →
Nor USB devices, nor the screen size, nor ... They can access way too many parts of the OS. But almost nobody cares, as long as they have their shiny feeds and videos.
That depends. For my local use I want to access everything.
For external situations I agree. No clue why browsers started to sniff after people. I blame Google for that.
What?
If copy and paste is disabled in my default browser that would be something like 80% of my total of my total use cases for the clipboard in the first place.
They're not saying your manual copy/pasting from a browser window onto your clipboard shouldn't be possible; they're saying the browser itself shouldn't allow this functionality to be scriptable internally.
The former is a system event, not a browser one.
This is similar to how on google docs if you try to copy via the edit menu, it pops up to say use Ctrl-C instead.
Honestly, I too am surprised a JavaScript plugin was able to access and alter the system clipboard in the first place too.