I think there is also a copy-side change in that writing to the clipboard should never sanitize text/html going forward. On Wednesday, October 18, 2023 at 10:52:14 AM UTC-4 Evan Stade wrote:
> Hi Anupam, > > I think this feature is now scoped just to the read side of the equation, > is that correct? Could you update the Chrome status entry > <https://chromestatus.com/feature/5716132676763648?context=myfeatures> text > to remove references to writing to avoid confusion? > > -- Evan Stade > > > On Fri, Oct 6, 2023 at 10:31 AM Anupam Snigdha <[email protected]> > wrote: > >> 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 <[email protected]> >> *Sent:* Friday, October 6, 2023 2:54 AM >> *To:* Anupam Snigdha <[email protected]> >> *Cc:* [email protected] <[email protected]>; Sanket Joshi (EDGE) < >> [email protected]>; Evan Stade <[email protected]>; [email protected] >> <[email protected]>; Ana Sollano Kim <[email protected]> >> *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 <[email protected]> >> *Sent:* Thursday, October 5, 2023 4:22 PM >> *To:* [email protected] <[email protected]> >> *Cc:* Sanket Joshi (EDGE) <[email protected]>; Evan Stade < >> [email protected]>; [email protected] <[email protected]>; Ana Sollano >> Kim <[email protected]> >> *Subject:* Intent to Ship: Async Clipboard API: Read unsanitized HTML >> and write well-formed HTML format. >> >> >> Contact emails >> [email protected], [email protected], [email protected], >> [email protected], [email protected], *[email protected]* >> >> >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db24d2c7-c9f8-4bc6-a0c4-04ff2b153f5en%40chromium.org.
