Re: [w3ctag/design-reviews] Pickling for Async Clipboard API (#636)

> Is this being restricted to a domain name? 

We don't want to restrict to a domain because we want native apps to be able to consume contents from sites that opted-in to be using pickling formats, and vice versa.
We expect, sites like Figma, GoogleDocs, Office and Libre will need to have access to it, to provide better user experience. Browsers run with the assumption that clipboard contents are untrusted, hence the sanitization of web-exposed formats.
As far as pickling formats go, web apps should not assume the content is trusted either and do the due diligence themselves. And this is by design since we want to preserve as much of the original content as possible.

> On naming

Pickling formats is not exposed as an API name anywhere. Are you referring to the usage in the explainer and the spec? We could also refer to it as `Custom unsanitized mime types` with a common naming pattern across browsers"? In the API `direct ` option in the `ClipboardItemOptions` refers to the custom formats that shouldn't be sanitized. Are we OK with this naming?

> On privacy

In Chromium, we do have user activation requirement for `execCommand("copy")` but I don't think we have one for async clipboard APIs `read/write.` We only have permission prompts for async clipboard `read`, but not `write`. For Pickling APIs we do want to add both user activation and permission prompt for `read` & `write`. However there were feedbacks from web developers that if it's gated behind user gesture requirement, then it would be too restrictive and fetching payload (which might be huge) from the server and writing into the clipboard might cause performance issues during copying/pasting. This is sort of implying that the operation is synchronous which defeats the purpose of async clipboard apis.

Adding @dway123 @whsieh @gked @BoCupp-Microsoft to comment more on this.

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

Received on Thursday, 27 May 2021 00:01:54 UTC