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

As a follow-up to [this action item](https://www.w3.org/2021/09/24-editing-minutes.html#a02) from the Web Editing WG meeting from 9/24/2021, members from Apple, Google and Microsoft met last Friday (10/1/2021) to discuss two topics:

1. The contents of the native clipboard for pickled data exchange
2. The ability for a web site to read unsanitized HTML via the async clipboard API

For point 1, we concluded that we are going to include [the proposed format for the Web Custom Format Map and clipboard format naming conventions as outlined in the current explainer](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#os-interaction-format-naming) as non-normative notes in the Clipboard API spec.  Additional details... we debated for a while whether what will surely become a de facto standard should be included as part of the actual standard using normative text but decided that alternative implementations are possible and that we would leave room for those by using non-normative text.  One hypothetical example is that Apple could introduce new platform APIs for the pasteboard that could read and write the proposed pickled format in addition to some legacy pickled formats that vary across browsers today to hide the implementation details from native app authors including browser implementors.  As a counterpoint it was argued that to facilitate interchange between native and web apps, the shape of the platform-specific format written to the clipboard must be documented somewhere, and it was better to have it as part of the standard than to require that it be reverse engineered from the apps that happen to implement it first.  Our compromise was to include it in the spec using non-normative language.

For point 2, Microsoft pointed out that the ClipboardEvent's getData method already provides unsanitized access to the HTML on the clipboard (in Firefox, IE, Edgehtml-based Edge, Chromium-based Edge and Chrome), but that navigator.clipboard.read only returns a sanitized fragment of the HTML on the clipboard.  This loss of fidelity creates feature gaps for Microsoft Office apps (and likely many others) and prevents them from adopting the async clipboard API.  [The proposal](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickling-read) is to provide unsanitized access to HTML on the clipboard by using the navigator.clipboard.read method with a new unsanitized option.  As a counterpoint, Apple suggested that native apps can't be trusted to write data to the clipboard without revealing document metadata and that the browser should sanitize it to prevent exposure before allowing it to be read by a website.  Microsoft expressed skepticism as to whether it was the browser's responsibility to restrict what native apps could place in their HTML data.  We agreed to continue discussing point 2 in our Web Editing WG meeting this Friday (10/8/2021).


-- 
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-933939592