ClipboardChange event API

[roraja]

こんにちは TAG-さん!

I'm requesting an early TAG design review of ClipboardChange event API.

The clipboardchange event is fired whenever the system clipboard contents are changed. This allows web-apps like remote desktop clients to be notified and respond to changes to the system clipboard. It provides an efficient alternative to polling the clipboard for changes.

• Explainer¹: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ClipboardAPI/clipboard-change-event-explainer.md
• Specification: https://www.w3.org/TR/clipboard-apis/#clipboard-event-clipboardchange
• User research: Web based spreadsheet apps like Excel Online and web based remote desktop client apps have shown interest in this API. Please refer to the explainer document for further details about their use cases.
• Security and Privacy self-review²: https://docs.google.com/document/d/1CjIORGpRK776O0YNF7Ah2FtQpA0ziNz20sFy-wWAzPE/edit?tab=t.0#heading=h.xzptrog8pyxf
• Primary contacts:
  • Rohan Raja (@roraja), Microsoft
  • Rakesh Goulikar (@ragoulik), Microsoft
• Organization/project driving the specification: Microsoft
• Multi-stakeholder support³:
  • Chromium comments: https://issues.chromium.org/issues/41442253
  • Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN
  • WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN
  • Clipboardchange event API WICG/proposals#186

Further details:

• I have reviewed the TAG's Web Platform Design Principles ✅ 2024-11-21
• Relevant time constraints or deadlines: Jan, 2025
• The group where the work on this specification is currently being done: Microsoft
• The group where standardization of this work is intended to be done (if different from the current group): Microsoft
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Microsoft

You should also know that...

The design doc of this feature for Chromium might be useful for review. Code changes for a prototype implementation can be found here.

---

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Use links to content rather than pasting text into this issue. Issues are ephemeral and most of the material we are asking for has long term value.

Please preview the issue and check that the links work before submitting. Please make sure anyone with the link can access the document. We may refuse to review anything that is not public.

¹ An explainer must address user needs and contain examples of use. See our explanation of how to write a good explainer.

² Even for early-stage ideas, a Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

³ For your own organization, you can simply state the organization's position instead of linking to it. This includes items on Mozilla standards-positions, and WebKit standards-positions. Chromium doesn't have a standards-positions repository and prefers to use comments from the teams that maintain the relevant area of their codebase.

[jyasskin]

The TAG is concerned about revealing the clipboard to sites without the browser knowing that its user meant to do so. The gesture requirement described in w3c/clipboard-apis#225 seems like the minimum bar, but it would be ideal to find a way for the browser to know that the user actually saw a "paste" button or used their native paste keyboard shortcut, as the TAG previously requested in w3c/clipboard-apis#52 (comment).

However, it doesn't seem like your use cases actually need to reveal the clipboard's contents to the website in real time. We see 2 use cases in your explainer:

1. In a remote desktop client, the user asks the remote side to paste, and it reads from its own clipboard instead of the user's local clipboard. This seems like a bug in the remote desktop software, that it's not forwarding clipboard requests to the client. We're not experts in the APIs needed to implement this, but there's a proposal at Seeking feedback on delayed clipboard rendering proposal w3c/editing#417 and https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DelayedClipboard/DelayedClipboardRenderingExplainer.md to allow web pages to only generate clipboard data when it's requested by the paster, and it seems like the remote desktop host could use the same native mechanisms to forward clipboard requests to the web browser.

2. The user wants to be able to pick which of several clipboard formats to paste, and the website needs to know what formats are available in order to give the user those choices, and this UI needs to be ready as soon as the user looks for it, not after the user clicks it. Notably, this only requires the list of formats that are on the clipboard, not the data in any of those formats. This is still a privacy risk, especially if the user copies data from a specialized application that provides an unusual kind of clipboard data. But it's not the same level of risk as exposing every password the user copies. Could you explore providing just the list of available clipboard types in the clipboardchange event, and not the full clipboard contents?

Are there any other use cases that actually need the clipboard contents in real time? The TAG is likely to remain skeptical that the tradeoff is worth it, but we should know what the tradeoff is.

[ragoulik]

Wanted to provide my initial thoughts/clarifications after reading the above mentioned two points especially this concern:

Could you explore providing just the list of available clipboard types in the clipboardchange event, and not the full clipboard contents?

I think there is misunderstanding that clipboardchange event would provide full clipboard contents when it is fired.

As mentioned in the explainer in 5.3):

Therefore, the only way to read clipboard contents within a clipboardchange event handler would be using the Async Clipboard APIs. Note that the clipboardchange event would still be a ClipboardEvent but the clipboardData attribute would be set to a null object.

So, when there is a change to clipboard, the clipboardchange event would be fired without any clipboard contents.

The web developers/apps will continue to use the already existing ways of reading clipboard which are subjected to the existing clipboard permissions that are needed to read the clipboard.

The clipboardchange event itself will need the "clipboard-read" permission to be granted on the page for it to be fired(but clipboard contents are not available when this event is fired).

@jyasskin does this help in clarifying the concerns?

[jyasskin]

We'd missed that statement in the explainer, but your example code does read the full clipboard contents in the event handler. Could you show how this event helps to achieve the use cases you're pursuing without doing that?

[garykac]

The TAG is concerned about revealing the clipboard to sites without the browser knowing that its user meant to do so. The gesture requirement described in w3c/clipboard-apis#225 seems like the minimum bar, [...]

User intent is why this can be protected by an actual permission, which requires explicit user consent. A permission + gesture can be useful if (a) you don't believe the user intended to grant permission and (b) it doesn't interfere with valid use scenarios. However, with clipboard it does prevent scenarios related to background clipboard synchronization (e.g., with remote access applications).

1. In a remote desktop client, the user asks the remote side to paste, and it reads from its own clipboard instead of the user's local clipboard. This seems like a bug in the remote desktop software, that it's not forwarding clipboard requests to the client.

Forwarding the clipboard requests from the remote host to the client would add a network round-trip to each clipboard operation. And when the local client received the request, what would it do? It would need to read the clipboard (without a gesture) to satisfy the request and send the data to the remote host.

A better user experience is to read the local clipboard when it changes and send it to the remote host. Which requires a way to know when the clipboard has changed (we currently rely on heuristics like checking the clipboard when focus is regained), and a way to access the clipboard (read and write) outside of user gestures.

In both cases, for this scenario there needs to be a way to read from the clipboard without a gesture. This is why we have a permission for this implemented in Chrome.

But, because of platform and UX differences, it's fair for different user agents to choose different ways to control access to these APIs. In Chrome, there is a permission so that access can be granted without requiring a gesture. Firefox and Safari don't use the permission and rely on gestures (plus, IIUC, heuristics to identify the correct kind of gestures). We tried to write the async clipboard spec in a way that gave implementations flexibility in this regard.

We're not experts in the APIs needed to implement this, but there's a proposal at Seeking feedback on delayed clipboard rendering proposal w3c/editing#417 and https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DelayedClipboard/DelayedClipboardRenderingExplainer.md to allow web pages to only generate clipboard data when it's requested by the paster, and it seems like the remote desktop host could use the same native mechanisms to forward clipboard requests to the web browser.

The delayed clipboard rendering discussion is unrelated. It's merely a performance optimization so that expensive clipboard content is not generated unless it is going to be immediately used. Even if the remote (native) host made use of whatever native mechanisms exist for this, that doesn't help the local (browser) client access the clipboard when a request is triggered by the remote host.

[torgo]

Hi @garykac –

First a bit of context: The TAG feels the whole clipboard API is more permissive regarding permission than it should be. Also to be clear, we understand that your position is that this is required for the remote desktop scenario in order to allow for seamless clipboard access. The concern we have is about abuse of this API in other scenarios. Remember that web users will also be using other web applications, visiting other web sites, and will be subject to the same risks and attacks as any other web users.

For example: user receives a text message from a scammer purporting to be from a trustworthy site; user clicks on the URL in the text message; now they are interacting with a web page that looks benign but it's really a scam web site; The web site convinces the user to paste something into the page; the web site shows the permission prompt, which of course the user accepts, and thereafter it's able to scrape any info off the user's clipboard any time it gets focus.

We also think the remote desktop use cases would work fine if it only works on paste, and without the clipboardchange event, websites don't know when a copy happens and so are incentivized to only read the clipboard on paste. With clipboardchange, they get a new incentive to be incompatible with Firefox and Safari, which isn't good for the Web. Before endorsing clipboardchange, we'd like to see an explanation for why that won't happen.