The I2S thread was incorrectly merged into another I2S that I sent for a completely different feature. I'm creating a new thread and merging replies. Sorry for the inconvenience.
As the author of the web custom formats article<https://developer.chrome.com/blog/web-custom-formats-for-the-async-clipboard-api/>, just for me to better understand: the problem is that the clipboard gets populated with `text/html` by random (web or native) apps. If the clipboard were populated from the start with `web text/html`, the contents could be read unsanitized, even without this new parameter. So this new parameter is the escape hatch that developers can use via `navigator.clipboard.read({unsanitized: ["text/html"]})`. So, the problem is that, for sites like Excel Online, they aren't sure where the user is going to paste, so they always have to produce both 'web text/html' and 'text/html'. That way if an app doesn't have support for web custom format, then they can use the native HTML format. Same thing for native apps that produce a web custom format. There are also legacy native apps (old Office versions that are used by Enterprises) that don't have support for the new web custom format, so the site has to produce the standard HTML format for those apps as well. But you are right that if both source and target apps support web custom format, then it can be used to access unsanitized HTML content. An immediate question that I ask myself is whether this mechanism could be expanded to other values than just `"text/html"`. Currently we are focusing on the standard HTML format to better align with the DataTransfer APIs. In theory you could add support for other built-in formats as well, but the main intent here is to produce similar fidelity of HTML format so sites that use DataTransfer APIs to read HTML do not experience any regression when they move over to async clipboard API for copy-paste operations. Here is a document where I described the regressions and impact on the apps when sanitization is performed: https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing Some native apps that I surveyed for impact of this new proposal: https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing FWIW, this demo was initially a bit misleading, since I expected "some text" to be on the clipboard, or whatever I put into the `contenteditable` box, but it's hardcoded. Maybe remove the box. Oops, sorry about that. Copy-paste error 🙂 I fixed it now. Please let me know if you have any questions! Thanks, Anupam ________________________________ From: Thomas Steiner <to...@google.com> Sent: Friday, October 6, 2023 2:54 AM To: Anupam Snigdha <sni...@microsoft.com> Cc: blink-dev@chromium.org <blink-dev@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <ana.soll...@microsoft.com> Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format. Adoption expectation Excel online is ready to use this API. They are trying to move away from DataTransfer APIs and use Async clipboard APIs where web custom format is supported along with other benefits from async usage. Adoption plan Support for async clipboard API and web custom format is already in inner rings, so once this gets added to the clipboard API, Excel would be ready to use it right away. As the author of the web custom formats article<https://developer.chrome.com/blog/web-custom-formats-for-the-async-clipboard-api/>, just for me to better understand: the problem is that the clipboard gets populated with `text/html` by random (web or native) apps. If the clipboard were populated from the start with `web text/html`, the contents could be read unsanitized, even without this new parameter. So this new parameter is the escape hatch that developers can use via `navigator.clipboard.read({unsanitized: ["text/html"]})`. An immediate question that I ask myself is whether this mechanism could be expanded to other values than just `"text/html"`. For example, could one do `navigator.clipboard.read({unsanitized: ["image/avif"]})` and expect it to work (when an AVIF image is on the clipboard)? Reading the relevant section in the explainer<https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md#read>, it seems hardcoded to ignore any other value than `"text/html"`, so something like `navigator.clipboard.read({unsanitized: ["hahaha/lol", "text/html", "application/json", "text/plain"]})` would work. Is this correct? Sample links https://viridian-hypnotic-cut.glitch.me/ FWIW, this demo was initially a bit misleading, since I expected "some text" to be on the clipboard, or whatever I put into the `contenteditable` box, but it's hardcoded. Maybe remove the box. ________________________________ From: Anupam Snigdha <sni...@microsoft.com> Sent: Thursday, October 5, 2023 4:22 PM To: blink-dev@chromium.org <blink-dev@chromium.org> Cc: Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <ana.soll...@microsoft.com> Subject: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format. Contact emails sni...@microsoft.com<mailto:sni...@microsoft.com>, sa...@microsoft.com<mailto:sa...@microsoft.com>, est...@chromium.org<mailto:est...@chromium.org>, jsb...@chromium.org<mailto:jsb...@chromium.org>, asu...@chromium.org<mailto:asu...@chromium.org>, ansol...@microsoft.com<mailto:ansol...@microsoft.com> Explainer https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md Specification https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md Summary This proposal provides an `unsanitized` option in read() method to get the unsanitized HTML format. Unless sites explicitly opt-into reading the unsanitized HTML, they will get the sanitized HTML content by-default. Currently, when we read text/html MIME type using the async API, the sanitizer is invoked to strip out contents from the HTML markup due to security concerns, and styles are inlined into the HTML markup, which leads to a bloated HTML payload and loss of fidelity of HTML content when read by web authors or native apps. Firefox provides access to unsanitized HTML via DataTransfer APIs, which matches Chromium's behavior, and Safari only allows access to unsanitized HTML if it's being read within the same origin. Comments For more context on this change, here is a discussion between stakeholders: https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing 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 api<https://chromestatus.com/features#tags:async%20api>, clipboard<https://chromestatus.com/features#tags:clipboard> TAG review There is no desire to standardize this behavior as discussed in https://github.com/w3c/clipboard-apis/issues/150#issuecomment-917273986. Also, Webkit was opposed to any change in behavior since their implementation of Async API interops with the DataTransfer API (https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047152542). TAG review status Not applicable WebFeature UseCounter name AsyncClipboardAPIUnsanitizedRead Risks Interoperability and Compatibility This is a Chromium-only feature (see discussion in https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing), so adding a dictionary as an argument in read will be ignored in non-Chromium browsers and the HTML read might be sanitized. As this change aligns the sanitization behavior of the DataTransfer API and the Clipboard Async API, existing paste targets that support DataTransfer APIs unsanitized HTML don't need to make updates on how they handle HTML if they decide to transition to the Clipboard Async API. Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/769) https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598 WebKit: Negative (https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974236367) Web developers: Positive. Positive signals from Excel Online, https://groups.google.com/a/chromium.org/g/blink-dev/c/j9fDbU9E2Ds/m/IPocqIfEAwAJ?utm_medium=email&utm_source=footer Ergonomics The spec'd read method doesn't accept any arguments. With this feature, we have overloaded the read method in order to add a dictionary argument, where web authors will explicitly request for the unsanitized HTML format. Activation The current Clipboard Async API read method as specified in https://w3c.github.io/clipboard-apis/ isn't affected by the introduction of this feature, the behavior is validated through existing web tests. Security Sites have to explicitly opt into reading unsanitized HTML content via the "unsanitized" option, so any sites that don't have that option, would get the default, sanitized HTML content. The legacy DataTransfer APIs already allow access to unsanitized HTML content, so we don't think this will create any additional security loopholes. Threat Model document: https://docs.google.com/document/d/1QLt50Q8UnlQksVltZ2PNkDZVdk9N58Pq7P0lzGTKh-U/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? No. Ergonomics N/A Activation N/A Security N/A 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? N/A Debuggability No specific DevTools changes are required. This feature is treated like any other JS method. 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/+/main/docs/testing/web_platform_tests.md>? Yes Flag name on chrome://flags ClipboardUnsanitizedContent Finch feature name None Non-finch justification None Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1268679 Measurement Added usage metrics: ClipboardUnsanitizedContent Adoption expectation Excel online is ready to use this API. They are trying to move away from DataTransfer APIs and use Async clipboard APIs where web custom format is supported along with other benefits from async usage. Adoption plan Support for async clipboard API and web custom format is already in inner rings, so once this gets added to the clipboard API, Excel would be ready to use it right away. Sample links https://viridian-hypnotic-cut.glitch.me/ Estimated milestones Shipping on desktop 120 Shipping on Android 120 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5716132676763648 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY5PR00MB08404BFFE057DB0C8A055DD9CFC9A%40BY5PR00MB0840.namprd00.prod.outlook.com.
