Thanks for the PSA Anupam. Since this is UA-defined behavior of the clipboard APIs and not likely to have a compat impact, I'm supportive of treating it as a PSA. Still, like most behavior-impacted bugfixes in blink, there might be some possible compat risk here. Is it relatively easy to make the implementation change behind a flag <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md> so that, in the worst case and we find this behavior change triggers a user-impacting bug, we can easily flip it off while we work on a migration story?
Thanks, Rick On Mon, Dec 11, 2023 at 5:47 PM 'Anupam Snigdha' via blink-dev < blink-dev@chromium.org> wrote: > Fixing typos and formats. > > ------------------------------ > *From:* Anupam Snigdha > *Sent:* Monday, December 11, 2023 2:42 PM > *To:* blink-dev@chromium.org <blink-dev@chromium.org> > *Cc:* Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade < > est...@chromium.org>; Ana Sollano Kim <ana.soll...@microsoft.com> > *Subject:* Web-Facing Change PSA: Async Clipboard API: Write well-formed > HTML document. > > Contact emails > > sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org > > Specification > > > https://w3c.github.io/clipboard-apis/#dom-clipboard-write > > Design docs > > > https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing > > Summary > > The Async clipboard writer API uses sanitizers to strip out content such > as <head>, <meta>, <style>, <script> tags from the HTML and inline > styles into the markup. > > In this proposal, writing to the clipboard for text/html MIME type using > the navigator.clipboard.write() API will write a higher fidelity > sanitized, well-formed HTML markup instead of a more strictly sanitized > HTML fragment. It will also preserve the tags such as <meta>, <style>, > <head> etc that were stripped out by the fragment parser. > > Roundtripping of HTML content using the async clipboard API within the web > doesn’t change as the async clipboard read() method still produces a > sanitized HTML fragment. > > Method used to write HTML data to the clipboard > > Does it affect the DataTransfer getData() method? > > Does it affect the navigator.clipboard.read() method? > > Does it affect the native apps that read HTML data from the clipboard? > > navigator.clipboard.write() > > Yes, if web authors write via navigator.clipboard.write() and read via > DataTransfer getData(). It returns well-formed HTML markup. > > No. By-default read() returns a strictly sanitized fragment. > > Yes. It returns a higher fidelity sanitized markup instead of a strictly > sanitized fragment. > > > Blink component > > Blink>DataTransfer > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDataTransfer> > > Search tags > > unsanitized html > <https://chromestatus.com/features#tags:unsanitized%20html>, async > clipboard <https://chromestatus.com/features#tags:async%20clipboard>, > clipboard <https://chromestatus.com/features#tags:clipboard>, copy > <https://chromestatus.com/features#tags:copy> > > TAG review > > None. There is no web API change. It only changes the sanitization > requirement by writing a higher fidelity sanitized HTML instead of a more > strictly sanitized HTML fragment to the system clipboard. > > TAG reviewed the unsanitized read/write as part of a broader review of the > Pickling API > > https://github.com/w3ctag/design-reviews/issues/636#issuecomment-919324784 > > https://github.com/w3ctag/design-reviews/issues/636#issuecomment-869792053 > > > TAG review status > > Not applicable > > Risks > > > Interoperability and Compatibility > > Existing paste targets don't need to make updates to read HTML written via > the async clipboard API, as they are already able to handle unsanitized > HTML written via the DataTransfer API. > > > *Gecko*: Neutral ( > https://github.com/mozilla/standards-positions/issues/769) > > *WebKit*: Negative ( > https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974236367) > > *Web developers*: Positive signals from Excel Online. Google Sheets also > appear to be positive based on discussions in this bug > <https://bugs.chromium.org/p/chromium/issues/detail?id=1493388&q=Google%20sheets&can=2>, > I2S > <https://groups.google.com/a/chromium.org/g/blink-dev/c/pjpN9Lwv5Tk/m/DEALX5QdBwAJ?utm_medium=email&utm_source=footer> > and > email conversations. > > *Other signals*: > > Ergonomics > > No API change. > > > Activation > > The current Clipboard Async API write method as specified in > <https://w3c.github.io/clipboard-apis/#dom-clipboard-write> > https://w3c.github.io/clipboard-apis/#dom-clipboard-write isn't affected > by this change, the behavior is validated in existing web tests. > > > Security > > Existing DataTransfer APIs already allow reading and writing unsanitized > HTML content from/to the clipboard. The proposed change just makes sure > that the HTML markup that gets written to the clipboard via the async > clipboard API is a well-formed HTML document. > > > https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ClipboardAPI/tag-security-privacy-clipboard-unsanitized-read.md > > Here is a threat model that was presented to the Chrome security team: > https://docs.google.com/document/d/1QLt50Q8UnlQksVltZ2PNkDZVdk9N58Pq7P0lzGTKh-U/edit?usp=sharing > > Discussions: > https://docs.google.com/document/d/1yHUC_laWTRoG65QOQTIqkpiULITDyQmznwKtVr0KMk8/edit?usp=sharing&resourcekey=0-q650DjDFdpHyVLffTwP7Yw > > Since the DataTransfer API, which is more widely used, already allows > access to the unsanitized HTML content, we don’t think there are any > additional security concerns with this proposal. > > Native apps have their own HTML parser to process the HTML content before > it is inserted into their document model. These apps already handle > unsanitized HTML because the DataTransfer API, which is much more commonly > used, does not sanitize HTML either. More details here: > https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing > . > > > WebView application risks > > *Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications?* > > None > > > Debuggability > > No specific DevTools changes are required as it doesn’t introduce any new > web API. Existing support for async clipboard APIs is sufficient. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > > Yes > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > Yes > > > https://wpt.fyi/results/clipboard-apis/async-unsanitized-standard-html-formats-write-read.tentative.https.html > , > <https://wpt.fyi/results/clipboard-apis/async-unsanitized-standard-html-read-fail.tentative.https.html> > https://wpt.fyi/results/clipboard-apis/async-unsanitized-standard-html-read-fail.tentative.https.html > > > Flag name in Blink > > ClipboardWellFormedHtmlSanitizationWrite > > Finch feature name > > ClipboardWellFormedHtmlSanitizationWrite > > Requires code in //chrome? > > False > > Tracking bug > > https://bugs.chromium.org/p/chromium/issues/detail?id=1268679 > > Sample links > > > https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/unsanitized-html-demo.html > > Estimated milestones > > Shipping on desktop > > 122 > > Shipping on Android > > 122 > > Shipping on WebView > > 122 > > > > Anticipated spec changes > > None > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/6236486997639168 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > > > -- > 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/SJ0PR00MB0991226DDC0F8A44190F3DAFCF8FA%40SJ0PR00MB0991.namprd00.prod.outlook.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR00MB0991226DDC0F8A44190F3DAFCF8FA%40SJ0PR00MB0991.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY9xXkWvUpr%3DBNL6EC1x9KnF3BcFjTzpH8HE2GGHs%3DNyMw%40mail.gmail.com.
