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
>
> [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 
> <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/7caa568a-1d53-4218-b99e-df068e376527n%40chromium.org.

Reply via email to