Re: [w3ctag/design-reviews] ClipboardChange event API (Issue #1017)

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 https://github.com/w3c/clipboard-apis/issues/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 https://github.com/w3c/clipboard-apis/issues/52#issuecomment-875709431.

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](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ClipboardAPI/clipboard-change-event-explainer.md#2-user-scenarios):

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 https://github.com/w3c/editing/issues/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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1017#issuecomment-2578124896
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1017/2578124896@github.com>