Contact emails
sni...@microsoft.com<mailto:sni...@microsoft.com>, 
sa...@microsoft.com<mailto:sa...@microsoft.com>, 
est...@chromium.org<mailto:est...@chromium.org>, 
jsb...@chromium.org<mailto:jsb...@chromium.org>, 
asu...@chromium.org<mailto:asu...@chromium.org>, 
ansol...@microsoft.com<mailto:ansol...@microsoft.com>


Explainer
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md


Specification
https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md

Summary

This proposal provides an `unsanitized` option in read() method to get the 
unsanitized HTML format. Unless sites explicitly opt-into reading the 
unsanitized HTML, they will get the sanitized HTML content by-default. 
Currently, when we read text/html MIME type using the async 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. 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.


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
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 the DataTransfer API 
(https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047152542).

TAG review status
Not applicable


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.

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
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 unsanitized HTML format.

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
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.
Threat Model document:
https://docs.google.com/document/d/1QLt50Q8UnlQksVltZ2PNkDZVdk9N58Pq7P0lzGTKh-U/edit?usp=sharing

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.

Ergonomics

N/A

Activation

N/A


Security

N/A


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?

N/A

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

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 where web custom format is 
supported along with other benefits from async usage.

Adoption plan
Support for async clipboard API and web custom format is already in inner 
rings, so once this gets added to the clipboard API, Excel would be ready to 
use it right away.

Sample links

https://viridian-hypnotic-cut.glitch.me/

Estimated milestones
Shipping on desktop
120
Shipping on Android

120


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5716132676763648

This intent message was generated by Chrome Platform 
Status<https://chromestatus.com/>.

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

Reply via email to