The unsanitized option being proposed here is only for the well-known HTML format. It could be extended to other well-known formats, but for now we are focusing on the HTML format. Web custom format is unsanitized by design, so this option doesn’t affect the existing web custom formats.
From: Thomas Steiner <to...@google.com> Sent: Wednesday, July 13, 2022 9:56 AM To: Anupam Snigdha <sni...@microsoft.com> Cc: Ana Sollano Kim <ana.soll...@microsoft.com>; Bo Cupp <pc...@microsoft.com>; Thomas Steiner <to...@google.com>; blink-dev@chromium.org Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API read/write HTML format with DataTransfer API Just to clarify on my end, I was referring to the “Web Custom formats for Async Clipboard API” explainer (https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md). I was under the impression that this would replace the previous `unsanitized: true` flag ( https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#alternative-considered-unsanitizedtrue). On Wed 13. Jul 2022 at 18:41 Anupam Snigdha <sni...@microsoft.com<mailto:sni...@microsoft.com>> wrote: Just to clarify some of the points in the explainer. This proposal introduces an `unsanitized` option only in the navigator.clipboard.read() method. For write() we will always write unsanitized HTML content to the clipboard. This will align the behavior of async APIs with the DataTransfer APIs and also be backward compatible with the native apps on certain platforms like Windows that rely on this behavior. With the current sanitization in async API, copy pasting HTML content in Office native apps is broken because we remove custom styles from the HTML markup, inline styles into the fragment that increases the size of the copy payload etc when we write the HTML format to the system clipboard. This proposal is a Chromium specific change because Firefox and Safari opposed to having an unsanitized option in the read() method, but they agreed to align the behavior of async APIs with DataTransfer APIs<https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1033465241>. We shipped the sanitization behavior first, so changing that would be a breaking change for us. Safari has the sanitization behavior for cross-origin copy-paste, but for same origin, they allow access to unsanitized HTML content. Safari’s async APIs behavior is aligned with the DataTransfer APIs so they don’t want to add an unsanitized option to read() method and cause backward compatibility issues. Firefox behaves the same as Chromium, but we didn’t see any support from them for adding an unsanitized option in read() method to allow web authors to access unsanitized HTML content. Even though the usage of async read<https://chromestatus.com/metrics/feature/popularity#AsyncClipboardAPIRead>/write<https://chromestatus.com/metrics/feature/popularity#AsyncClipboardAPIWrite> is low, we got feedback from security<https://chromium-review.googlesource.com/c/chromium/src/+/3271065/comments/6012173d_1579d13e> and other stakeholders<https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing> that changing the behavior of the API would break the existing sites that rely on the sanitization behavior and also make the API “less secure”. Adding an option to switch between sanitized and unsanitized HTML content during read, and always writing unsanitized HTML content to the system clipboard would address both backward compatibility and security concerns. Please let us know if you have any questions/concerns. -Anupam From: Thomas Steiner <to...@google.com<mailto:to...@google.com>> Sent: Tuesday, July 12, 2022 9:57 PM To: Ana Sollano Kim <ana.soll...@microsoft.com<mailto:ana.soll...@microsoft.com>> Cc: Anupam Snigdha <sni...@microsoft.com<mailto:sni...@microsoft.com>>; Bo Cupp <pc...@microsoft.com<mailto:pc...@microsoft.com>>; blink-dev@chromium.org<mailto:blink-dev@chromium.org> Subject: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API read/write HTML format with DataTransfer API With the Pickling API<https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md> proposal, we will be introducing a new `unsanitized` parameter in the read method so the content is round trippable i.e. read would return the content without any sanitization. This last part is no longer true as far as I know: the `unsanitized` parameter was replaced with prepending `'web '` to the MIME type. It doesn’t change the described round-trip behavior, just needs updating in the Explainer. On Wed 13. Jul 2022 at 06:24 'Ana Sollano Kim' via blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>> wrote: Contact emails ansol...@microsoft.com<mailto:ansol...@microsoft.com>, sni...@microsoft.com<mailto:sni...@microsoft.com>, pc...@microsoft.com<mailto:pc...@microsoft.com> Explainer https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing Specification None Summary This proposal aligns the HTML format read/write async API with the setData/getData DataTransfer APIs. Currently, when we read/write text/html MIME types using the async API, the sanitizer is invoked to strip out contents from the HTML markup due to security concerns, and styles are inlined in the HTML. This leads to loss of fidelity of HTML content when read by web authors or native apps. Motivation Using DataTransfer object’s setData and async clipboard write method, we are seeing interop differences in how the HTML content is sanitized and written to the clipboard. In Chromium, async clipboard write method clears the clipboard content first and then writes the payload which results in overwriting the previous HTML content that was inserted by authors using DataTransfer object’s setData API. It’d be beneficial for web authors if async clipboard and setData APIs provide the same HTML content during copy operation, so that round tripping is possible without any interop differences. Moreover, creating a fragment and inlining the styles bloats the payload and strips out the custom styles inserted by sites like Excel Online that are used to preserve excel specific semantics. Comments Discussion between stakeholders: https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing Firefox's support: https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598 Blink component Blink>DataTransfer<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDataTransfer> TAG review TAG review status As this is a Chromium specific change, we don’t believe this merits TAG review. But we’re happy to file a request if API_OWNERS feel this change should have one. Risks Interoperability and Compatibility Gecko: Positive https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598 WebKit: No signal Web developers: Positive Debuggability The async clipboard APIs have basic tooling support as described in https://docs.google.com/document/d/1eJn5QIX4JFGackDYmdLxWXEmTDkSGj_ZGz5XY4uCKbY/edit Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? No Flag name TBD Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1268679 Estimated milestones No milestones specified. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5716132676763648<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeature%2F6037871692611584&data=05%7C01%7CAna.Sollano%40microsoft.com%7Cb0a2fbe347734699403a08da3815ec92%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637883964057764552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Un0P6tjq0ARKUWsn51chYU10v6Ev57Tb%2BJzNUFDDHJc%3D&reserved=0> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR00MB046492DBF7ABFE976B948BE8FD899%40MN2PR00MB0464.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR00MB046492DBF7ABFE976B948BE8FD899%40MN2PR00MB0464.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer>. -- Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany<https://www.google.com/maps/search/ABC-Str.+19,+20354+Hamburg,+Germany?entry=gmail&source=g> Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 ----- BEGIN PGP SIGNATURE ----- Version: GnuPG v2.3.4 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/ ----- END PGP SIGNATURE ----- -- Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 ----- BEGIN PGP SIGNATURE ----- Version: GnuPG v2.3.4 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/ ----- END PGP SIGNATURE ----- -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB03501B06AA1C2663746D36D7CF899%40SN6PR00MB0350.namprd00.prod.outlook.com.
