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 <slightly...@chromium.org> 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 >> >> sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org, >> jsb...@chromium.org, asu...@chromium.org, ansol...@microsoft.com >> >> >> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-0qzysLaUrD9OUbDkq5dzeBA948F9ZxcD%3Djkh58ssk4w%40mail.gmail.com.
