Intent to Ship: Async Clipboard API: Read unsanitized HTML format
Anupam Snigdha
Contact emails
sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org, jsb...@chromium.org, asu...@chromium.org, anso...@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
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
Search tags
unsanitized html, async api, 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?
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 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
Alex Russell
Rick Byers
Rick Byers
Mike Taylor
LGTM3
--
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+...@chromium.org.
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.