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?