1688865 - Consider exposing clipboard.write to web content

Status: RESOLVED DUPLICATE of bug 1887845

(Core :: DOM: Copy & Paste and Drag & Drop, task, P3)

Description

[Tom S [:evilpie]]

We already expose clipboard.writeText so this might be doable. So it's already possible to overwrite an user's clipboard and make them potentially lose data. I assume one of the reasons we haven't been excited about doing this is potential exploits in other apps when handling rich data like text/html or image/png?

I guess we also need to implement the clipboard-write feature policy. In Chrome this permission seems to be granted by default.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If this causes serious web-compat issue on some web apps, feel free to set higher priority.

Comment 2

[Anne (:annevk)]

I don't know if permissions policy makes sense for clipboard support. While I suppose it's something that the user can disable support for, it's not something that makes sense for websites to control for themselves or explicitly enable for third parties. That would only make sense if there was a permission dialog, but that does not seem like a good idea for clipboard access. Safari's "Paste contextmenu" seems much more reasonable.

As for write(), yeah, the problem is that the specification doesn't define the sanitization process for these types. If we already support these for drag & drop it might be reasonable though. Depends a bit on the specifics.

Comment 3

[Tom S [:evilpie]]

Safari's "Paste contextmenu" seems much more reasonable.

What does that look like? Is that only used for pasting, and what about copying? In my mind clipboard.write is like copy and clipboard.read is like paste.

Comment 4

[Anne (:annevk)]

Attachment: Safari's paste UI (if you click on a document that attempts to paste programmatically)

Comment 5

[Daniel Veditz [:dveditz]]

I assume one of the reasons we haven't been excited about doing this is potential exploits in other apps when handling rich data like text/html or image/png?

Yeah. Random other apps on your machine assume paste data comes from you or at least a well-behaved application you trusted enough to install, and that you aren't trying to exploit yourself. We can't ensure that every app's clipboard api is robust enough to handle "exposed to the web" levels of malicious content. I'm less worried about well-known formats like text/html and image/png where apps hopefully use OS functions or well-known libraries that will handle bad input and more concerned about arbitrary data that could target custom formats that haven't gotten as much scrutiny.

Honestly, I'm still not keen even on plain text (see Jesse's concerns in bug 192355 comment 0), but the web has spoken on that. In practice the world hasn't fallen apart.

Comment 6

[Sean Voisen (:svoisen)]

FWIW, we (at Adobe) would really love to see this ship in Firefox soon using a context menu approach similar to Safari's. Is this work still held up by this standards issue? https://github.com/w3c/clipboard-apis/issues/135

Comment 7

[Dennis Schubert [:denschub]]

Sean, are y'all already using this in production? If so, can you provide us with STR so we can see the difference between Safari and Firefox here? We'd like to estimate the WebCompat impact of this, and the WebCompat priority by extension.

Comment 8

[Ksenia Berezina [:ksenia]]

Setting webcompat priority as P2 as this feature likely will be used by Adobe.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:peterv, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 12

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Clearing the NI as no extra action we can take to response comment 11.