Open Bug 1688865 Opened 9 months ago Updated 18 days ago

Consider exposing clipboard.write to web content

Categories

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

task

Tracking

()

People

(Reporter: evilpie, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

Attachments

(1 file)

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.

Depends on: 1646270, 1688279

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

Severity: -- → S3
Priority: -- → P3

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.

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.

Depends on: 1689835
Depends on: 1689836
Depends on: 1701512
Component: DOM: Core & HTML → DOM: Copy & Paste and Drag & Drop
Depends on: 1712122

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.

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

You need to log in before you can comment on or make changes to this bug.