How should we handle Navigator.Clipboard?

[Moonchild]

There's many ways in which I can implement clipboard API access through Navigator.Clipboard, but the spec is very much focused on a mobile-style app permissions system which we don't use.

I want to implement a more limited version of this as I don't want to ever allow web content to read the system clipboard (that's just a massive privacy and security footgun), but I'm on the fence about how to handle access from Chrome scripts (i.e. extensions), so I'd rather ask the user base

There's plenty of potential utility value for allowing extensions to read the clipboard, but it also poses a risk in case of malware extensions that might monitor and steal/exfiltrate clipboard contents.

[Potkeny]

Would it be possible/feasible to have the pref work on a per-extension base? Giving read access to just a select few (more trusted) extension sounds better, though I would probably accept it with just a global pref (and voted that way).

[moonbat]

Extensions already have the ability to access system functions via XPCOM, including the clipboard. There's no need for additional access via javascript, nsIClipboard as it is can only be called from extension code and not from web code (where again in the present day an attacker would have to specifically target Pale Moon even if it was possible for a webpage to cross the chrome-content separation since Firefox no longer offers this). I'd say there's no more risk to this as with other XPCOM interfaces for accessing the file system, sockets and everything else.

Speaking from the extensions POV, there's no need for this.

[athenian200]

Well, the only real use for this seems to be for web content having access to the clipboard, honestly. If we don't want to allow that, then having this just for extensions seems a bit redundant, if what moonbat said about us already having a way for extensions to access the clipboard is correct.

I'm thinking you were right in the first place to just make the new API write-only, since it seems to be primarily targeted at web content.

The only alternative solution I can think of is, to allow it to read from a user-controlled buffer that isn't the system clipboard, but which pretends to be the system clipboard.

That is, they wouldn't be able to paste directly from the system clipboard, but they could paste something from the system clipboard into this buffer that acts like a fake system clipboard, and then websites could only read what users explicitly wanted websites to be able to read.

Essentially, I'm talking about adding an extra step in the process so that we don't have to worry about web content reading a random value that the user wasn't expecting... making it so that if the user wants something from the system clipboard to be readable by web content, they have to go out of their way to paste it into the fake system clipboard so it can be read.

Maybe this could even be an extension? Not sure what would be within the realm of possibility here. But in general, I'm leaning more towards the idea that making it write-only was the right call, with a possible compromise like I mentioned being the only other thing I would consider.

[Moonchild]

Yeah, moonbat makes a good point that I didn't even think of - we already have a native XPCOM interface so it really doesn't matter. this eluded me because all Mozilla does is approach this from a WebExtension PoV which doesn't have XPCOM interfaces and we really don't need to give access another way and just confuse the extension dev space with it.

Thanks for reminding me of the obvious!
Removing the poll, it's pointless.

[Moonchild]

That is, they wouldn't be able to paste directly from the system clipboard, but they could paste something from the system clipboard into this buffer that acts like a fake system clipboard, and then websites could only read what users explicitly wanted websites to be able to read.

That's very convoluted, both to implement and for the user to use. I'm thinking that since permission systems can refuse access by design, web scripts will have to be able to deal with it in practice and not break on a rejection, so we really don't have to fake anything. There simply is no good reason for scripted access through Navigator.Clipboard to read the clipboard.

[moonbat]

It could be addressed by an extension,if one can intercept calls to Navigator.clipboard and then decide what to show, perhaps.

[RealityRipple]

Whatever the outcome, please allow an advanced pref to turn it off, with writing doing nothing and reading always returning a blank string.

[Moonchild]

Whatever the outcome, please allow an advanced pref to turn it off, with writing doing nothing and reading always returning a blank string.

No, I won't be doing that. There will be a pref to disable the interface and a pref to restrict it to text only, but reading will (as per spec) return a rejected promise, and writing, if enabled, will not "fake" the result as success because that's just wrong. of note, writing will be restricted to the same rules as the prior copy to clipboard commands, (and the spec requires this too) it must have user interaction/initiation.

[SemiKebab]

What would be the behavior of the pref to disable the interface?

I'm thinking of websites that would access "navigator.clipboard" without checking if it is defined, now that on all major browsers, at least "navigator.clipboard.writeText" is defined.

[Moonchild]

What would be the behavior of the pref to disable the interface?

exactly what it says: navigator.clipboard would be "undefined" when the interface is disabled.

I'm thinking of websites that would access "navigator.clipboard" without checking if it is defined

Those will fail if the user disables the interface.

[SemiKebab]

Indeed, I don't think there is a "reliable" way to disable the functionnality, while having a coherent behavior at the same time.

But if the functionnality is enabled by default, we should be fine. If really they don't want it, users would have the option to disable it, at the cost of potentially failing websites.

[Michaell]

There is a button for Custom Buttons that shows the Clipboard contents. And I use a custom Prefbar button to toggle Clipboard events as needed since it can't be site-specific. Works good enough for me.