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> 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> > *Sent:* Tuesday, July 12, 2022 9:57 PM > *To:* Ana Sollano Kim <ana.soll...@microsoft.com> > *Cc:* Anupam Snigdha <sni...@microsoft.com>; Bo Cupp <pc...@microsoft.com>; > 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> wrote: > > *Contact emails* > > ansol...@microsoft.com, sni...@microsoft.com, 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. > 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/CALgRrLmPbcHKQ%2Bpg_S14mZGNCqS6v0m%3DG%2BUJVXTdAjHNnEJigQ%40mail.gmail.com.
