Reading through this discussion, WebKit raised some privacy concerns and indicated that they would not be willing to ship the proposed changes. For Safari, the existing DataTransfer APIs don't support access to unprocessed HTML content in cross-origin, so they don't want to change this behavior for async clipboard APIs. In Chromium and Firefox, existing DataTransfer APIs already support access to unprocessed HTML content regardless of the origin. Since Chromium shipped the async clipboard APIs with strict sanitization of HTML content when writing to the clipboard, this change only relaxes the sanitization by producing a well-formed HTML document without stripping out tags like `<head`, `<meta`, `<style` etc. There is no web API change.
Specifically, I see that the security team has been consulted for this feature, but I'm curious to see if this has been raised with privacy teams We consulted with T&S to review any potential privacy/security risks. Note that the existing DataTransfer APIs (which is used widely for copy-paste operations) already provide access to unprocessed HTML content from the system clipboard. This change doesn't expose any new information – it just makes sure that the HTML content written to the clipboard is well-formed and the fidelity of the HTML content is preserved. Thanks, Anupam ________________________________ From: Vladimir Levin <[email protected]> Sent: Tuesday, December 12, 2023 9:44 AM To: Anupam Snigdha <[email protected]> Cc: [email protected] <[email protected]>; Sanket Joshi (EDGE) <[email protected]>; Evan Stade <[email protected]>; Ana Sollano Kim <[email protected]> Subject: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: Async Clipboard API: Write well-formed HTML document. You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> On Mon, Dec 11, 2023 at 6:05 PM 'Anupam Snigdha' via blink-dev <[email protected]<mailto:[email protected]>> wrote: Contact emails [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> 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) Reading through this discussion, WebKit raised some privacy concerns and indicated that they would not be willing to ship the proposed changes. I think this poses a sufficient risk to interop that it warrants a full Intent to Ship (instead of a Web Facing PSA). Specifically, I see that the security team has been consulted for this feature, but I'm curious to see if this has been raised with privacy teams. Thanks, Vlad 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/>. Thanks, Anupam Sent from Outlook<http://aka.ms/weboutlook> -- 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 [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR00MB09912FF13F0DA983D298E0E4CF8FA%40SJ0PR00MB0991.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR00MB09912FF13F0DA983D298E0E4CF8FA%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA2PR00MB0985D8553DE5E6A063E59020CF8EA%40SA2PR00MB0985.namprd00.prod.outlook.com.
