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 <sni...@microsoft.com> 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 <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, sa...@microsoft.com, est...@chromium.org, > jsb...@chromium.org, asu...@chromium.org, *ansol...@microsoft.com > <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/CAO4XGS-CWL1m7wJmWiWs9UtbrioLptRhe0r8PiCE%3DeROtGPELg%40mail.gmail.com.
