Re: [w3c/editing] Seeking feedback on Clipboard Pickling APIs. (#334)

> I really don't follow. When we say developers, are we talking about web developers, or native app developers?

In that response I was mainly referring to native app developers, but it applies equally to web devs as well. Web developers could use the [Sanitizer APIs](https://wicg.github.io/sanitizer-api/#sanitizer-api) to decide what elements/attributes to drop and would have control over what content gets pasted.

> Surely, browsers should have to write both versions to the system pasteboard because we don't know when or if the user pastes the content to another browser instance of the same origin or to some other native applications.

I'm guessing you are referring to standard formats here as custom formats are always written by sites/apps if they opt-in to reading/writing custom formats. For standard formats, we want sites and native apps to explicitly opt-in to read the unsanitized version so they are aware of the security implications. Some legacy sites and native apps don't receive frequent updates and are not really designed to properly process unsanitized HTML content from the web. This is why we want to always write sanitized version of standard formats so we don't regress the paste behavior in these sites/apps. 

> I'm really confused here. Why would a website want to read the sanitized version of content from the system pasteboard if a version of the content that's unsanitized is available to them?

There are sites and legacy apps that don't receive updates often. These sites/apps depend on the standard formats(which is predefined by the OS) being available on the pasteboard. Currently we sanitize the standard formats by-default so we don't want to regress that behavior. 
Unsanitized version of the standard formats wouldn't be available by-default. It will be written to the pasteboard as custom formats. It is described in [this ](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#os-interaction-format-naming)section. The sites/apps have to make changes explicitly to read the unsanitized version of standard formats, and if they don't, then they receive the sanitized version of standard formats.

> I don't see the need for reading the sanitized version.

Sanitized version is always needed to support sites/apps that don't want to make any changes to their copy/paste code. Legacy native apps (at least on Windows) don't receive frequent updates so we don't want to regress copy/paste behavior in those apps.

> What is the scenario in which a website wants to read unsanitized version of the content?

Excel Online would want to read and process unsanitized version of the HTML format to preserve rich formats like table cells color. [Here ](https://drive.google.com/file/d/1Nsyp1rUKc_NF4l0n-O05snAKabHAKeiG/view)is a GIF that shows the difference between unsanitized & sanitized version of the HTML formats. Note how the sanitized version loses styles when pasted into Excel online compared to the unsanitized one.

> But websites shouldn't be in control of, say, exposing a PSD file unsanitized

I don't think the site needs to specify any particular format. They can just serialize the payload and write it under a custom format that only be interpreted by either the site or the native apps that are aware of this custom format's content. That way both the site and native app have complete control over the content of the payload. This also addresses some security concerns regarding unsanitized custom formats where only the site and the native app know how to parse the content of the custom format and are also able to trust the content by adding some security tokens or something to uniquely identify the payload present in the custom format.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/334#issuecomment-909620736