Web-Facing Change PSA: Async Clipboard API: Write well-formed HTML document.

284 views
Skip to first unread message

Anupam Snigdha

unread,
Dec 11, 2023, 6:05:33 PM12/11/23
to blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, Ana Sollano Kim

Contact emails

sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org


Specification


https://w3c.github.io/clipboard-apis/#dom-clipboard-write


Design docs


https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing


Summary

The Async clipboard writer API uses sanitizers to strip out content such as <head>, <meta>, <style>, <script> tags from the HTML and inline styles into the markup. In this proposal, writing to the clipboard for `text/html` MIME type using the navigator.clipboard.write() API will write a higher fidelity sanitized, well-formed HTML markup instead of a more strictly sanitized HTML fragment. It will also preserve the tags such as <meta>,  <style>, <head> etc  that were stripped out by the fragment parser.


Roundtripping of HTML content using the async clipboard API within the web doesn’t change as the async clipboard read() method still produces a sanitized HTML fragment.


Method used to write HTML data to the clipboard

Does it affect the DataTransfer getData() method?

Does it affect the navigator.clipboard.read() method?

Does it affect the native apps that read HTML data from the clipboard?

navigator.clipboard.write()

Yes, if web authors write via navigator.clipboard.write() and read via DataTransfer getData(). It returns well-formed HTML markup.

No. By-default read() returns a strictly sanitized fragment.

Yes. It returns a higher fidelity sanitized markup instead of a strictly sanitized fragment.


Blink component

Blink>DataTransfer


Search tags

unsanitized html, async clipboard, clipboard, copy


TAG review

None. There is no web API change. It only changes the sanitization requirement by writing a higher fidelity sanitized HTML instead of a more strictly sanitized HTML fragment to the system clipboard.


TAG reviewed the unsanitized read/write as part of a broader review of the Pickling API

https://github.com/w3ctag/design-reviews/issues/636#issuecomment-919324784

https://github.com/w3ctag/design-reviews/issues/636#issuecomment-869792053



TAG review status

Not applicable


Risks



Interoperability and Compatibility

Existing paste targets don't need to make updates to read HTML written via the async clipboard API, as they are already able to handle unsanitized HTML written via the DataTransfer API.



Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/769)


WebKit: Negative (https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974236367)


Web developers: Positive signals from Excel Online. Google Sheets also appear to be positive based on discussions in this bug, I2S and email conversations.


Other signals:


Ergonomics

No API change.



Activation

The current Clipboard Async API write method as specified in https://w3c.github.io/clipboard-apis/#dom-clipboard-write isn't affected by this change, the behavior is validated in existing web tests.



Security

Existing DataTransfer APIs already allow reading and writing unsanitized HTML content from/to the clipboard. The proposed change just makes sure that the HTML markup that gets written to the clipboard via the async clipboard API is a well-formed HTML document.

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ClipboardAPI/tag-security-privacy-clipboard-unsanitized-read.md

Here is a threat model that was presented to the Chrome security team: https://docs.google.com/document/d/1QLt50Q8UnlQksVltZ2PNkDZVdk9N58Pq7P0lzGTKh-U/edit?usp=sharing

Discussions: https://docs.google.com/document/d/1yHUC_laWTRoG65QOQTIqkpiULITDyQmznwKtVr0KMk8/edit?usp=sharing&resourcekey=0-q650DjDFdpHyVLffTwP7Yw


Since the DataTransfer API, which is more widely used,  already allows access to the unsanitized HTML content, we don’t think there are any additional security concerns with this proposal. 


Native apps have their own HTML parser to process the HTML content before it is inserted into their document model. These apps already handle unsanitized HTML because the DataTransfer API, which is much more commonly used, does not sanitize HTML either. More details here: https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/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?

None



Debuggability

No specific DevTools changes are required as it doesn’t introduce any new web API. Existing support for async clipboard APIs is sufficient.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/clipboard-apis/async-unsanitized-standard-html-formats-write-read.tentative.https.html, https://wpt.fyi/results/clipboard-apis/async-unsanitized-standard-html-read-fail.tentative.https.html



Flag name in Blink

ClipboardWellFormedHtmlSanitizationWrite


Finch feature name

ClipboardWellFormedHtmlSanitizationWrite


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1268679


Sample links


https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/unsanitized-html-demo.html


Estimated milestones

Shipping on desktop

122

Shipping on Android

122

Shipping on WebView

122



Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6236486997639168


This intent message was generated by Chrome Platform Status.



Thanks,
Anupam

Sent from Outlook

Vladimir Levin

unread,
Dec 12, 2023, 12:45:06 PM12/12/23
to Anupam Snigdha, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, Ana Sollano Kim
Reading through this discussion, WebKit raised some privacy concerns and indicated that they would not be willing to ship the proposed changes. I think this poses a sufficient risk to interop that it warrants a full Intent to Ship (instead of a Web Facing PSA). Specifically, I see that the security team has been consulted for this feature, but I'm curious to see if this has been raised with privacy teams.

Thanks,
Vlad
 
--
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/SJ0PR00MB09912FF13F0DA983D298E0E4CF8FA%40SJ0PR00MB0991.namprd00.prod.outlook.com.

Rick Byers

unread,
Dec 12, 2023, 12:54:48 PM12/12/23
to Anupam Snigdha, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, Ana Sollano Kim
Thanks for the PSA Anupam. Since this is UA-defined behavior of the clipboard APIs and not likely to have a compat impact, I'm supportive of treating it as a PSA. Still, like most behavior-impacted bugfixes in blink, there might be some possible compat risk here. Is it relatively easy to make the implementation change behind a flag so that, in the worst case and we find this behavior change triggers a user-impacting bug, we can easily flip it off while we work on a migration story?

Thanks,
   Rick 

On Mon, Dec 11, 2023 at 5:47 PM 'Anupam Snigdha' via blink-dev <blin...@chromium.org> wrote:
Fixing typos and formats.

From: Anupam Snigdha
Sent: Monday, December 11, 2023 2:42 PM
To: blin...@chromium.org <blin...@chromium.org>
Cc: Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: Web-Facing Change PSA: Async Clipboard API: Write well-formed HTML document.
 

--
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.

Anupam Snigdha

unread,
Dec 12, 2023, 1:01:16 PM12/12/23
to Rick Byers, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, Ana Sollano Kim
Hi Rick,

Thank you for taking a looking at this PSA! Yes, we do have these changes behind a flag: https://chromium-review.googlesource.com/c/chromium/src/+/4990467

Thanks,
Anupam
From: Rick Byers <rby...@chromium.org>
Sent: Tuesday, December 12, 2023 9:54 AM
To: Anupam Snigdha <sni...@microsoft.com>
Cc: blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Re: Web-Facing Change PSA: Async Clipboard API: Write well-formed HTML document.
 
You don't often get email from rby...@chromium.org. Learn why this is important

Anupam Snigdha

unread,
Dec 12, 2023, 1:09:27 PM12/12/23
to Vladimir Levin, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, Ana Sollano Kim
Reading through this discussion, WebKit raised some privacy concerns and indicated that they would not be willing to ship the proposed changes.
For Safari, the existing DataTransfer APIs don't support access to unprocessed HTML content in cross-origin, so they don't want to change this behavior for async clipboard APIs.  In Chromium and Firefox, existing DataTransfer APIs already support access to unprocessed HTML content regardless of the origin. Since Chromium shipped the async clipboard APIs with strict sanitization of HTML content when writing to the clipboard, this change only relaxes the sanitization by producing a well-formed HTML document without stripping out tags like `<head`, `<meta`, `<style` etc. There is no web API change.

Specifically, I see that the security team has been consulted for this feature, but I'm curious to see if this has been raised with privacy teams
We consulted with T&S to review any potential privacy/security risks. Note that the existing DataTransfer APIs (which is used widely for copy-paste operations) already provide access to unprocessed HTML content from the system clipboard. This change doesn't expose any new information – it just makes sure that the HTML content written to the clipboard is well-formed and the fidelity of the HTML content is preserved.

Thanks,
Anupam​
From: Vladimir Levin <vmp...@google.com>
Sent: Tuesday, December 12, 2023 9:44 AM

To: Anupam Snigdha <sni...@microsoft.com>
Cc: blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: Async Clipboard API: Write well-formed HTML document.
 
You don't often get email from vmp...@google.com. Learn why this is important

Evan Stade

unread,
Dec 12, 2023, 3:24:39 PM12/12/23
to Vladimir Levin, Anupam Snigdha, blin...@chromium.org, Sanket Joshi (EDGE), Ana Sollano Kim
To add to what Anupam has said,
  • Interop risk:
    • All browsers apply some processing to the contents of the clipboard (even plain text, where line returns are canonicalized for the platform)
    • It's already true that no browser has exactly the same sanitization routine
    • Do you have a concrete example of interop failure in mind?
  • Privacy:
    • Safari has taken the stance that clipboard contents should never be allowed to contain ANY data that is not user visible [Ctrl+F "Only visible content preserved."]. As a <script> may contain non-user-visible data, it is stripped.
    • This view is not shared by the Chrome privacy team. 
    • Personally I find this stance hard to understand as there many ways to hide information in HTML that a user can't notice and aren't stripped.
Reply all
Reply to author
Forward
0 new messages