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 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/PH0PR00MB0981EB119CF529F48685E459CF83A%40PH0PR00MB0981.namprd00.prod.outlook.com.
