Intent to Experiment: Align clipboard async API read/write HTML format with DataTransfer API
Ana Sollano Kim
Contact emails
sni...@microsoft.com, sa...@microsoft.com, anso...@microsoft.com, est...@chromium.org, asu...@chromium.org
Explainer
https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing
Specification
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md
Design docs
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md
Summary
This proposal aligns the sanitization requirement of the HTML format from read/write async API with the setData/getData DataTransfer APIs. By default, HTML written to the clipboard will be unsanitized and, unless sites choose to adopt the new API, reading from the clipboard will be sanitized. Currently, when we read/write text/html MIME types using the async API, the sanitizer is invoked to strip out contents from the HTML markup due to security concerns, and styles are inlined in the HTML, which leads to a bloated HTML payload and loss of fidelity of HTML content when read by web authors or native apps. Currently, 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.
Blink component
Search tags
unsanitized html, async api, 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 DataTransfer API (https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047152542).
TAG review status
Not applicable
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.
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 unsanitization of the HTML.
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
The legacy DataTransfer APIs already allow access to unsanitized HTML content, so we don't think this will create any additional security loopholes. Moreover, 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.
By default, the HTML payload that is written to the clipboard will be unsanitized. However, 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.
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.
Goals for experimentation
Gather feedback around the feature’s API shape and output before shipping.
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
No platform restrictions.
Is this feature fully tested by web-platform-tests?
Yes
DevTrial instructions
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/HOWTO.md
Flag name
ClipboardUnsanitizedContent
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1268679
Estimated milestones
We estimate we’ll start the origin trial during milestone 116 and continue until the end of milestone 121, to allow web developers to test and provide feedback.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5716132676763648
Ana Sollano Kim
Adding @Joshua Bell and @Daniel Cheng.
Mike Taylor
LGTM to experiment from 116 to 121 inclusive.
--
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/MW2PR00MB0330D032E0BF3C37F1128906FD7FA%40MW2PR00MB0330.namprd00.prod.outlook.com.
Artur Janc
Ana Sollano Kim
Hi Artur,
No, it’s the same behavior compared to the Ready for Trial stage.
Thanks,
Ana
From: Artur Janc <a...@google.com>
Sent: Tuesday, May 23, 2023 7:58 AM
To: blink-dev <blin...@chromium.org>
Cc: Mike Taylor <mike...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Ana Sollano Kim <Ana.S...@microsoft.com>; Anupam Snigdha <blin...@chromium.org>; Anupam Snigdha <sni...@microsoft.com>; Joshua Bell <dch...@chromium.org>
Subject: [EXTERNAL] Re: [blink-dev] RE: Intent to Experiment: Align clipboard async API read/write HTML format with DataTransfer API
|
You don't often get email from a...@google.com. Learn why this is important |