LGTM3
On 12/5/23 1:57 PM, 'Rick Byers' via blink-dev wrote:
By the way, for others trying to follow the history, the correct link
to the original thread on this is
https://groups.google.com/a/chromium.org/g/blink-dev/c/oiPCXHy9kRE/m/YS2sxbIQAAAJ
On Tue, Dec 5, 2023 at 1:56 PM Rick Byers <rby...@google.com> wrote:
Thanks for getting this cleaned up and clarified, and for getting
the spec PR landed. This now seems quite trivial to me - just
extending the existing unsanitized reading capability into an
option of the async clipboard API. LGTM2
On Wed, Nov 29, 2023 at 4:39 PM Alex Russell
<slightly...@chromium.org> wrote:
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
sni...@microsoft.com, sa...@microsoft.com,
est...@chromium.org, jsb...@chromium.org,
asu...@chromium.org, ansol...@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
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
<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
<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 blink-dev+unsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9zgeQCo-ngVc0w2iQLaeC57OpLx8%3DShreuPS3msQ47Dw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/12c96de0-1514-47ef-886a-6241cf43c6a6%40chromium.org.
