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 [w3c/clipboard-apis#225](https://github.com/w3c/clipboard-apis/issues/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](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.

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.


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

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