Delayed clipboard rendering

[anaskim]

Request for position on an emerging web specification

• WebKittens who can provide input: @annevk @whsieh

Information about the specification

• Title: Delayed clipboard rendering for Async Clipboard API
• GitHub repository: Seeking feedback on delayed clipboard rendering proposal w3c/editing#417
• Explainer (if not README.md in the repository): https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DelayedClipboard/DelayedClipboardRenderingExplainer.md

Design reviews and vendor positions

No TAG review needed as no Web API changes are needed at the moment.

• Mozilla standards-positions issue: Delayed clipboard rendering mozilla/standards-positions#758

Anything else we need to know

Delayed clipboard rendering is the ability to delay the generation of a particular payload until it is needed by the target applications. It is useful when source applications support several clipboard formats, some or all of which are time-consuming to render. The goal with this proposal is to leverage the existing Async Clipboard API to allow websites exchange large data payloads and improve performance by only producing clipboard payload when target applications request it.

[annevk]

Since copying is not mediated by the user agent (other than requiring user activation) we have these concerns:

• Websites could use this to figure out what apps or websites the user is copying data towards.
• Websites could use this to figure out user habits. This is a lesser concern.

The first of these could perhaps be remedied by restricting the feature to the "builtin" clipboard types. That would not satisfy w3c/editing#417 (comment). We're not sure about a solution that does.

It also seems likely that the website the user copied from is not available for one reason or another. Websites can get OOM'd without notice. This relates to the user habits concern, but is also a practical concern as the feature might not be that useful on certain devices.

[snianu]

Discussed this issue with privacy folks internally. Removing the support for web custom formats in delay rendering makes the API less useful, but we also want to limit the privacy impact. The proposal is to restrict the number of web custom formats that can be delay rendered. That way a random site can't advertise a large number of web custom formats with delay rendering and cast a wide net to track the user's paste activity. e.g. if we allow only 5 (arbitrary number) web custom formats that can be delay rendered, then it limits the options for sites to track the user paste activity.

It also seems likely that the website the user copied from is not available for one reason or another. Websites can get OOM'd without notice. This relates to the user habits concern, but is also a practical concern as the feature might not be that useful on certain devices.

Discussed the issue and the solution here: w3c/editing#424 (comment)