How should we handle Navigator.Clipboard?
Moderators: trava90, athenian200
-
- Pale Moon guru
- Posts: 35650
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
How should we handle Navigator.Clipboard?
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.
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.
Last edited by Moonchild on 2023-11-15, 22:16, edited 1 time in total.
Reason: Poll removed
Reason: Poll removed
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- Fanatic
- Posts: 132
- Joined: 2018-08-03, 17:00
Re: How should we handle Navigator.Clipboard?
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).
-
- Knows the dark side
- Posts: 4984
- Joined: 2015-12-09, 15:45
Re: How should we handle Navigator.Clipboard?
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.
Speaking from the extensions POV, there's no need for this.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
-
- Contributing developer
- Posts: 1537
- Joined: 2018-10-28, 19:56
- Location: Georgia
Re: How should we handle Navigator.Clipboard?
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.
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.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind
-
- Pale Moon guru
- Posts: 35650
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: How should we handle Navigator.Clipboard?
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.
Thanks for reminding me of the obvious!
Removing the poll, it's pointless.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- Pale Moon guru
- Posts: 35650
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: How should we handle Navigator.Clipboard?
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.athenian200 wrote: ↑2023-11-15, 22:09That 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.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- Knows the dark side
- Posts: 4984
- Joined: 2015-12-09, 15:45
Re: How should we handle Navigator.Clipboard?
It could be addressed by an extension,if one can intercept calls to Navigator.clipboard and then decide what to show, perhaps.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
-
- Astronaut
- Posts: 666
- Joined: 2018-05-17, 02:34
- Location: Los Berros Canyon, California
Re: How should we handle Navigator.Clipboard?
Whatever the outcome, please allow an advanced pref to turn it off, with writing doing nothing and reading always returning a blank string.
-
- Pale Moon guru
- Posts: 35650
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: How should we handle Navigator.Clipboard?
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.RealityRipple wrote: ↑2023-11-16, 00:59Whatever the outcome, please allow an advanced pref to turn it off, with writing doing nothing and reading always returning a blank string.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- Moonbather
- Posts: 50
- Joined: 2021-05-30, 03:48
Re: How should we handle Navigator.Clipboard?
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.
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.
-
- Pale Moon guru
- Posts: 35650
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: How should we handle Navigator.Clipboard?
exactly what it says: navigator.clipboard would be "undefined" when the interface is disabled.
Those will fail if the user disables the interface.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- Moonbather
- Posts: 50
- Joined: 2021-05-30, 03:48
Re: How should we handle Navigator.Clipboard?
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.
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.
-
- Lunatic
- Posts: 286
- Joined: 2018-05-26, 18:13
Re: How should we handle Navigator.Clipboard?
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.
Win10home(1709), PM33.1.0-portable as of Apr 23, '24