By the way, for others trying to follow the history, the correct link to the original thread on this is https://groups.google.com/a/chromium.org/g/blink-dev/c/oiPCXHy9kRE/m/YS2sxbIQAAAJ
On Tue, Dec 5, 2023 at 1:56 PM Rick Byers <[email protected]> wrote: > Thanks for getting this cleaned up and clarified, and for getting the spec > PR landed. This now seems quite trivial to me - just extending the existing > unsanitized reading capability into an option of the async clipboard API. > LGTM2 > > On Wed, Nov 29, 2023 at 4:39 PM Alex Russell <[email protected]> > wrote: > >> Thanks for re-sending this under different cover. I understand that the >> previous entry's Security review covers this, so LGTM1 >> >> Best, >> >> Alex >> >> On Wednesday, November 29, 2023 at 1:27:31 PM UTC-8 snianu wrote: >> >>> Resending the I2S with all the updates and a summary of discussion that >>> happened in a different I2S thread >>> <https://mail.google.com/mail/u/1/?ui=2&ik=ad97730700&view=lg&permmsgid=msg-f:1783916238508658206&ser=1> >>> . >>> >>> >>> 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://w3c.github.io/clipboard-apis/#dom-clipboard-read >>> <https://w3c.github.io/clipboard-apis/#dom-clipboard-read>* >>> >>> >>> Summary >>> >>> This proposal provides an `unsanitized` option in the >>> navigation.clipboard.read() method to get the unsanitized HTML format. >>> Unless sites explicitly opt-into reading the unsanitized HTML, they will >>> get the sanitized HTML fragment by-default. Currently, when we read >>> text/html MIME type using the async clipboard 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. >>> >>> >>> The DataTransfer API in Chromium does not perform any sanitization, >>> returning only unsanitized HTML markup. Therefore, this change gives web >>> authors the ability to use the async clipboard API without regressing >>> behavior compared to the DataTransfer API. >>> >>> >>> 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 >>> >>> The TAG reviewed the unsanitized option as part of a broader review of >>> the pickling API (now called web custom formats). >>> >>> >>> https://github.com/w3ctag/design-reviews/issues/636#issuecomment-919324784 >>> >>> >>> https://github.com/w3ctag/design-reviews/issues/636#issuecomment-869792053 >>> >>> >>> TAG review status >>> >>> Issues addressed. >>> >>> >>> 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. >>> >>> >>> 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. >>> >>> >>> *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 >>> >>> With this feature, we have added a dictionary argument to the read() >>> method, where web authors will explicitly request for the unsanitized HTML >>> format. >>> >>> >>> Activation >>> >>> The current Async Clipboard API read method as specified in >>> https://w3c.github.io/clipboard-apis/#dom-clipboard-read isn't affected >>> by the introduction of this feature as the default implementation of the >>> API is unchanged, and the new `unsanitized` parameter in the read() method >>> will not impact behavior on unsupported browsers(optional formats >>> dictionary will be ignored). 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. >>> >>> >>> >>> 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. This is an opt-in feature so existing Android webview-based >>> applications can continue reading sanitized HTML unless they explicitly >>> opt-into reading unsanitized HTML via the `unsanitized` option. >>> >>> >>> 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 >>> >>> >>> https://github.com/web-platform-tests/wpt/blob/38cdcdeeac/clipboard-apis/async-unsanitized-html-formats-write-read.tentative.https.html >>> , >>> >>> >>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/clipboard-apis/async-unsanitized-html-formats-write-read.tentative.https.html >>> >>> >>> 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 to take advantage of async >>> behavior and new capabilities like web custom formats, and preventing >>> sanitization of HTML is a blocker for this migration. >>> >>> >>> Adoption plan >>> >>> Excel app plans to leverage the feature immediately. >>> >>> >>> Sample links >>> >>> https://viridian-hypnotic-cut.glitch.me/ >>> >>> >>> Estimated milestones >>> >>> Shipping on desktop >>> >>> 121 >>> >>> >>> Shipping on Android >>> >>> 121 >>> >>> >>> *Link to entry on the Chrome Platform Status* >>> >>> >>> *Old Chrome status entry: * >>> https://chromestatus.com/feature/5716132676763648*: *All feature review >>> gates were approved except API owners sign-off. Since this is a new feature >>> and not a change in behavior of an existing web API, a new chromestatus >>> entry was created: >>> >>> *New Chrome status entry: * >>> https://chromestatus.com/feature/5203909459312640 >>> >>> >>> Summary of the discussion >>> >>> >>> There was some confusion around whether web custom format already >>> provides the ability to read/write unsanitized HTML content from within a >>> site using a `web text/html` format. To clarify, this proposal allows web >>> authors to read unsanitized HTML content from the built-in HTML format that >>> many native apps (that may not have support for “web text/html” format) >>> write to the clipboard. >>> >>> >>> If an app doesn’t opt-into reading the unsanitized HTML content, then >>> the default async clipboard read() method for the built-in text/html format >>> would return a sanitized fragment. >>> >>> >>> Existing DataTransfer APIs already provide the ability to read/write >>> unsanitized HTML content to the clipboard in the built-in HTML format, so >>> this proposal aligns the read behavior between async clipboard read() >>> method and DataTransfer getData() method. >>> >>> >>> Spec changes were made to add the `unsanitized` option to the read() >>> method: https://w3c.github.io/clipboard-apis/#dom-clipboard-read >>> >>> >>> Old I2S thread discussions: >>> https://mail.google.com/mail/u/1/?ui=2&ik=ad97730700&view=lg&permmsgid=msg-f:1783916238508658206&ser=1 >>> >>> >>> 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/CAFUtAY9zgeQCo-ngVc0w2iQLaeC57OpLx8%3DShreuPS3msQ47Dw%40mail.gmail.com.
