dom.event.clipboardevents.enabled is required to get copy/paste working on Google Docs

[fmarier]

For copy/paste to work on Google Docs using the keyboard (Ctrl+C, Ctrl+X, Ctrl+V), it needs dom.event.clipboardevents.enabled to be enabled.

We could however disable dom.allow_cut_copy (introduced in https://bugzilla.mozilla.org/show_bug.cgi?id=1170911) since that appears to only be required for using the clipboard using the mouse UI.

I'm not sure what the best path forward is here, but here are ideas:

• adding a comment to mention keyboard clipboard operations next to the dom.event.clipboardevents.enabled pref
• commenting it out the pref by default to prevent breakage
• adding dom.allow_cut_copy = false by default to prevent sites from tampering with the clipboard contents

[Thorin-Oakenpants]

here is what ghacks user.js has had for ages

/* 2402: disable website access to clipboard events/content
 * [WARNING] This will break some sites functionality such as pasting into facebook, wordpress
 * this applies to onCut, onCopy, onPaste events - i.e you have to interact with
 * the website for it to look at the clipboard
 * [1] http://www.ghacks.net/2014/01/08/block-websites-reading-modifying-clipboard-contents-firefox/ ***/
user_pref("dom.event.clipboardevents.enabled", false);
/* 2403: disable clipboard commands (cut/copy) from "non-privileged" content (FF41+)
 * this disables document.execCommand("cut"/"copy") to protect your clipboard
 * [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1170911 ***/
user_pref("dom.allow_cut_copy", false); // (hidden pref)

IMO, a "hardened" user.js (guess it depends on what is meant by hardened) should note breakage, not bend to it re dom.event.clipboardevents.enabled . I know google docs requires it, so does Facebook (you can't paste into FB otherwise). Sure, these sites (google docs?) require you to be logged in, so it's not about your ID. On FB, the reason they do this is to monitor everything you type/paste, even if you don't post it, or then edit it before posting. Wordpress, as mentioned is another one.

[nodiscc]

dom.allow_cut_copy was added in https://github.com/pyllyukko/user.js/pull/277, set to false, as @Thorin-Oakenpants noted we should keep enforcing false for both, but is definitely something to consider for a relaxed variant/branch #231 (set both prefs to true)

[Thorin-Oakenpants]

==Slightly OT== If you are afraid of breakage, then you should revisit your svg.disabled=>true (even we disabled enforcing this), as it breaks youtube player controls. SVG is just too big a part of the internet. It's a FF53+ pref FYI. It must be sitting in a PR, but I can't find it @nodiscc

[nodiscc]

SVG

https://github.com/pyllyukko/user.js/pull/276

If you are afraid of breakage, then you should revisit

#231 :)

[gcb]

Does disabling this actually prevents clipboard reading without user initiating a paste action?

[pyllyukko]

Does disabling this actually prevents clipboard reading without user initiating a paste action?

I sure as hell hope so! Otherwise random sites could read everything you put in there and that would be a security disaster.

[gcb]

I was probably too tired when i wrote that earlier comment :)

I meant, having this (as in the change to user.js being discussed) disabled (as in, having the firefox setting enabled) does prevent clipboard reading at random times?

I guess, a better question, what are the attack vectors we are trying to fix by disabling this?

One case I know that is actively exploited in the wild is clipboard pollution, which is still a problem on most browsers. Thanks to github and others wanting to add to your clipboard when you click the "copy" button because all users are too dumb to copy text, sites can add whatever they want to your clipboard if you visit them. This would fix it, but it is pretty low severity.

I am not aware of any way to get data from clipboard unless user initiate a paste event into the site.

So, having a way to prevent writing to clipboard while allowing paste would be the best of both world. Top security. Top usability.

[pyllyukko]

One case I know that is actively exploited in the wild is clipboard pollution, which is still a problem on most browsers.

I guess this is the main case with this/these setting(s).

So, having a way to prevent writing to clipboard while allowing paste would be the best of both world.

BTW. I was wondering whether there are other apps than Google Docs where Ctrl+V breaks 🤔 Because it seems to work in most places.

[gcb]

BTW. I was wondering whether there are other apps than Google Docs where Ctrl+V breaks 🤔 Because it seems to work in most places.

Everywhere you have rich-paste (i.e. you can paste images, etc)

To accomplish this, they use some badly coded react component that uses DIV instead of proper INPUT html element. So if you initiate a paste event without the java-script hacks, you just pasted nowhere on the page and it will be ignored.

bug examples i can think of:

• reddit and most other forums (easily worked around by switching to markdown/source edit mode. which gives you a textarea)
• element.io, no workaround.

examples that do it right:

• whats app web (you can still paste text because they use a hidden textarea to capture input and only replace it on display)