Intent to Implement: Asynchronous Clipboard API

[Gary Kacmarcik (Кошмарчик)]

Contact emails

Eng: gar...@chromium.org

Spec

Editor's Draft Clipboard Spec: https://w3c.github.io/clipboard-apis/

Explainer: https://github.com/garykac/clipboard/blob/master/clipboard.md

WICG Discourse: https://discourse.wicg.io/t/proposal-modern-asynchronous-clipboard-api/1513

Summary

A modern, asynchronous Clipboard API based on Promises.

Motivation

The primary motivation for this proposal is to address the following issues present in the current synchronous Clipboard API:

• For security reasons, user agents may need to sanitize images before putting them on the clipboard. This can be time-consuming for large images so it is not reasonable to do it on the main thread. Thus, the current synchronous-nature of the current API prevents images from being supported in Chrome.
• Synchronous APIs restrict the options for getting user permission before performing an action. Some permission models (like the Permissions API) require an async API.

Interoperability and Compatibility Risk

Low.

This intent is to add a new async API without changing the current sync API, so existing content will not break.

Response from other browser vendors (Apple, Mozilla, Microsoft) has been positive.

This feature was discussed at TPAC during the Web Platform meeting (present: Microsoft, Apple, Mozilla, Yandex), and it was agreed that this should move forward. See discussion at https://www.w3.org/2016/09/22-webapps-minutes.html#item17

Note that proper web platform support for clipboard cut/copy/paste has been a longstanding request from users and web developers. See related bugs: 150835, 390583, 424968, 443355, 593475.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/677564

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5861289330999296

Requesting approval to ship?

Not at this time.

[e...@google.com]

Nice to see changes to the clipboard API. A few questions.

1. https://w3c.github.io/clipboard-apis/#selection-mod says If the event listener modifies the selection or focus, the clipboard action must be completed on the modified selection. Do you know if this somewhat is meant to cover cross-origin selection/focus changes (eg, to an iframe)?
2. https://w3c.github.io/clipboard-apis/#h-clipboard-read and https://w3c.github.io/clipboard-apis/#h-clipboard-write-data say TODO: Handle access permissions. Reject promise if not allowed. Do you know already how would that be implemented? The synchronous API has some hints about it, but I don't know if they also can apply to the asynchronous API. For example, would this be allowed?
   window.addEventListener('copy', e=>{
       e.preventDefault();
       convertSvgToPng().then(png=>{
           var data = new DataTransfer();
           data.items.add("image/png", png);
           navigator.clipboard.write(png);
       });
   });
   
3. https://github.com/garykac/clipboard/blob/master/clipboard.md#navigatorclipboard mentions that this API is meant to be accessible from Workers. This is interesting because it also implies background access to the clipboard is an intended use case (I'm thinking about service workers, for example). Furthermore, https://github.com/garykac/clipboard/blob/master/clipboard.md#mitigating-abuse also says that permission dialogs might be skipped with the right set of permissions. Do you envision there to be a permission where background access to the clipboard is available to a service worker, for example? This question is mostly to try to understand whether this API would be exposing a permission that gives background access to the clipboard.

[Gary Kacmarcik (Кошмарчик)]

On Fri, Dec 30, 2016 at 11:52 AM, evn via blink-dev <blin...@chromium.org> wrote:

Nice to see changes to the clipboard API. A few questions.

1. https://w3c.github.io/clipboard-apis/#selection-mod says If the event listener modifies the selection or focus, the clipboard action must be completed on the modified selection. Do you know if this somewhat is meant to cover cross-origin selection/focus changes (eg, to an iframe)?

That was added to the spec before I was involved, so I'm not sure what motivated that. Because I can't give you a real answer, I've added a tracking bug: https://github.com/w3c/clipboard-apis/issues/38

1. https://w3c.github.io/clipboard-apis/#h-clipboard-read and https://w3c.github.io/clipboard-apis/#h-clipboard-write-data say TODO: Handle access permissions. Reject promise if not allowed. Do you know already how would that be implemented? The synchronous API has some hints about it, but I don't know if they also can apply to the asynchronous API. For example, would this be allowed?
   window.addEventListener('copy', e=>{
       e.preventDefault();
       convertSvgToPng().then(png=>{
           var data = new DataTransfer();
           data.items.add("image/png", png);
           navigator.clipboard.write(png);
       });
   });

Yes, that should be allowed.

The sync and async APIs would have 2 separate permission models: sync would still rely on user gestures et al., while async would have a proper Permission (that the user agent would grant as appropriate). The user gesture "hack" to guess user intent is not present in the async API because it is not reliable.

Note that, in the above example, if preventDefault() was missing, there would be a potential race with the regular update and the async clipboard.write() update. We'll need to note that as undefined in the spec.

1. https://github.com/garykac/clipboard/blob/master/clipboard.md#navigatorclipboard mentions that this API is meant to be accessible from Workers. This is interesting because it also implies background access to the clipboard is an intended use case (I'm thinking about service workers, for example). Furthermore, https://github.com/garykac/clipboard/blob/master/clipboard.md#mitigating-abuse also says that permission dialogs might be skipped with the right set of permissions. Do you envision there to be a permission where background access to the clipboard is available to a service worker, for example? This question is mostly to try to understand whether this API would be exposing a permission that gives background access to the clipboard.

We haven't thought through all the possible scenarios with background access, but we believe that background/service worker access is useful to have.

WRT permissions, we envision user agents possibly having different UX for granting access to the clipboard, and we want the spec to be flexible to allow these differences. We imagine that the following are reasonable scenarios that might be considered (for script in foreground tab accessing clipboard):

• UA requires pop-up dialog before clipboard access is granted (perhaps with box to always grant for this site)
• UA shows a brief post-facto notification that clipboard was accessed
• UA gives no indication for clipboard access (perhaps for trusted sites?)

For background/service workers, UAs would probably be more conservative when granting permission. A UA that doesn't normally have a pop-up dialog might choose to show one in this case because of the increased possibility for abuse.

Given that, I think it makes sense to have a separate Permission for foreground and background access, with the permission for bg access being more restricted.

And having said all that, the primary use case for the async clipboard API is for foreground access. If background/worker access becomes too messy/complex/unsecure, then we can punt that part for now.