Intent to Ship: Async Clipboard API: Read unsanitized HTML

[snianu]

sigh​.. This I2S thread keeps getting merged into another unrelated I2S thread, so going to start a new thread again to see if it fixes the issue this time. Sorry for the inconvenience.

Thanks,

Anupam

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Friday, October 20, 2023 10:44 AM
To: Sumeet Sharma <sharma...@google.com>; blink-dev <blin...@chromium.org>
Cc: Evan Stade <est...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: Re: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

 

We decided to split the proposal into two separate changes as read involves a change in the web API, but write doesn't. 

So, we're going to ship the unsanitized read first, before we ship the changes in behavior for the write method. I'll edit the Chrome status entry to reflect this change. Thanks!

---

From: Sumeet Sharma <sharma...@google.com>
Sent: Wednesday, October 18, 2023 8:06 AM
To: blink-dev <blin...@chromium.org>
Cc: Evan Stade <est...@chromium.org>; blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>; Anupam Snigdha <sni...@microsoft.com>
Subject: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

I think there is also a copy-side change in that writing to the clipboard should never sanitize text/html going forward.

On Wednesday, October 18, 2023 at 10:52:14 AM UTC-4 Evan Stade wrote:

Hi Anupam,

I think this feature is now scoped just to the read side of the equation, is that correct? Could you update the Chrome status entry text to remove references to writing to avoid confusion?

-- Evan Stade

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Tuesday, October 10, 2023 10:54 AM
To: Thomas Steiner <to...@google.com>
Cc: blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

 

The code expects `text/html` at the first position of the array, but the explainer says "If text/html representation is present in the ClipboardItem and text/html is present in the unsanitized list", which suggests any position would be fine. Maybe make the explainer say what the code says or vice versa.

Good catch. I'll edit the explainer to match the code. Thanks!

---

From: Thomas Steiner <to...@google.com>
Sent: Tuesday, October 10, 2023 8:12 AM
To: Anupam Snigdha <sni...@microsoft.com>
Cc: Thomas Steiner <to...@google.com>; blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

 

On Mon, Oct 9, 2023 at 7:15 PM Anupam Snigdha <sni...@microsoft.com> wrote:

Any answer on the other question regarding what the expected outcome of a call like below would be?

Currently we're throwing a JS exception if the unsanitized list contains a format other than `text/html`.

The code expects `text/html` at the first position of the array, but the explainer says "If text/html representation is present in the ClipboardItem and text/html is present in the unsanitized list", which suggests any position would be fine. Maybe make the explainer say what the code says or vice versa. 

In theory we could also add other built-in formats in the future where sanitization is needed by-default on read(), but unsanitized content is returned if the author explicitly opts into it. e.g. For `image/svg+xml`, we could return sanitized content by-default where styles would be inlined and <meta> tags would be stripped out by the sanitizer, but if the authors want unsanitized content, then they can explicitly opt into it by adding this format to the unsanitized list.

This sounds like a feasible extension to the current behavior.

 

Probably you could even remove the "hello" in `<div id="logDiv">hello</div>` so the DIV is entirely empty to avoid any and all misunderstandings.

Done.

Thank you!

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Monday, October 9, 2023 10:15 AM
To: Thomas Steiner <to...@google.com>
Cc: blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

 

Any answer on the other question regarding what the expected outcome of a call like below would be?

Currently we're throwing a JS exception if the unsanitized list contains a format other than `text/html`. In theory we could also add other built-in formats in the future where sanitization is needed by-default on read(), but unsanitized content is returned if the author explicitly opts into it. e.g. For `image/svg+xml`, we could return sanitized content by-default where styles would be inlined and <meta> tags would be stripped out by the sanitizer, but if the authors want unsanitized content, then they can explicitly opt into it by adding this format to the unsanitized list.

Probably you could even remove the "hello" in `<div id="logDiv">hello</div>` so the DIV is entirely empty to avoid any and all misunderstandings.

Done.

---

From: Thomas Steiner <to...@google.com>
Sent: Monday, October 9, 2023 8:56 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>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

 

As the author of the web custom formats article, just for me to better understand: the problem is that the clipboard gets populated with `text/html` by random (web or native) apps. If the clipboard were populated from the start with `web text/html`, the contents could be read unsanitized, even without this new parameter. So this new parameter is the escape hatch that developers can use via `navigator.clipboard.read({unsanitized: ["text/html"]})`.

So, the problem is that, for sites like Excel Online, they aren't sure where the user is going to paste, so they always have to produce both 'web text/html' and 'text/html'. That way if an app doesn't have support for web custom format, then they can use the native HTML format. Same thing for native apps that produce a web custom format.

There are also legacy native apps (old Office versions that are used by Enterprises) that don't have support for the new web custom format, so the site has to produce the standard HTML format for those apps as well.

But you are right that if both source and target apps support web custom format, then it can be used to access unsanitized HTML content.

Crystal-clear now, thanks for confirming my theory.

 

An immediate question that I ask myself is whether this mechanism could be expanded to other values than just `"text/html"`.

Currently we are focusing on the standard HTML format to better align with the DataTransfer APIs. In theory you could add support for other built-in formats as well, but the main intent here is to produce similar fidelity of HTML format so sites that use DataTransfer APIs to read HTML do not experience any regression when they move over to async clipboard API for copy-paste operations.

Here is a document where I described the regressions and impact on the apps when sanitization is performed: https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing

Some native apps that I surveyed for impact of this new proposal: https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing

Well understand the need for HTML.

I'm just looking at this with the eyes of a developer new to this who might ask themselves whether they can just put something else there. It's a generic-sounding option "unsanitized", but that is hardcoded to just "text/html", as per the spec. Maybe it could be renamed to  something very specific like "unsanitizedHTML" and accept a boolean?

Any answer on the other question regarding what the expected outcome of a call like below would be?

`navigator.clipboard.read({unsanitized: ["hahaha/lol", "text/html", "application/json", "text/plain"]})` 

 

FWIW, this demo was initially a bit misleading, since I expected "some text" to be on the clipboard, or whatever I put into the `contenteditable` box, but it's hardcoded. Maybe remove the box.

Oops, sorry about that. Copy-paste error 🙂 I fixed it now.

Probably you could even remove the "hello" in `<div id="logDiv">hello</div>` so the DIV is entirely empty to avoid any and all misunderstandings.

---

From: Anupam Snigdha
Sent: Friday, October 6, 2023 10:31 AM
To: blin...@chromium.org <blin...@chromium.org>
Cc: Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

 

The I2S thread was incorrectly merged into another I2S that I sent for a completely different feature. I'm creating a new thread and merging replies. Sorry for the inconvenience.

As the author of the web custom formats article, just for me to better understand: the problem is that the clipboard gets populated with `text/html` by random (web or native) apps. If the clipboard were populated from the start with `web text/html`, the contents could be read unsanitized, even without this new parameter. So this new parameter is the escape hatch that developers can use via `navigator.clipboard.read({unsanitized: ["text/html"]})`.

So, the problem is that, for sites like Excel Online, they aren't sure where the user is going to paste, so they always have to produce both 'web text/html' and 'text/html'. That way if an app doesn't have support for web custom format, then they can use the native HTML format. Same thing for native apps that produce a web custom format.

There are also legacy native apps (old Office versions that are used by Enterprises) that don't have support for the new web custom format, so the site has to produce the standard HTML format for those apps as well.

But you are right that if both source and target apps support web custom format, then it can be used to access unsanitized HTML content.

An immediate question that I ask myself is whether this mechanism could be expanded to other values than just `"text/html"`.

Currently we are focusing on the standard HTML format to better align with the DataTransfer APIs. In theory you could add support for other built-in formats as well, but the main intent here is to produce similar fidelity of HTML format so sites that use DataTransfer APIs to read HTML do not experience any regression when they move over to async clipboard API for copy-paste operations.

Here is a document where I described the regressions and impact on the apps when sanitization is performed: https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing

Some native apps that I surveyed for impact of this new proposal: https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing

FWIW, this demo was initially a bit misleading, since I expected "some text" to be on the clipboard, or whatever I put into the `contenteditable` box, but it's hardcoded. Maybe remove the box.

Oops, sorry about that. Copy-paste error 🙂 I fixed it now.

Please let me know if you have any questions!

Thanks,

Anupam

---

From: Thomas Steiner <to...@google.com>
Sent: Friday, October 6, 2023 2: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>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

 

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.

As the author of the web custom formats article, just for me to better understand: the problem is that the clipboard gets populated with `text/html` by random (web or native) apps. If the clipboard were populated from the start with `web text/html`, the contents could be read unsanitized, even without this new parameter. So this new parameter is the escape hatch that developers can use via `navigator.clipboard.read({unsanitized: ["text/html"]})`.

An immediate question that I ask myself is whether this mechanism could be expanded to other values than just `"text/html"`. For example, could one do `navigator.clipboard.read({unsanitized: ["image/avif"]})` and expect it to work (when an AVIF image is on the clipboard)? Reading the relevant section in the explainer, it seems hardcoded to ignore any other value than `"text/html"`, so something like `navigator.clipboard.read({unsanitized: ["hahaha/lol", "text/html", "application/json", "text/plain"]})` would work. Is this correct?

 

Sample links

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

FWIW, this demo was initially a bit misleading, since I expected "some text" to be on the clipboard, or whatever I put into the `contenteditable` box, but it's hardcoded. Maybe remove the box.

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Thursday, October 5, 2023 4:22 PM
To: blin...@chromium.org <blin...@chromium.org>
Cc: Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>

Subject: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

Contact emails

sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org, jsb...@chromium.org, asu...@chromium.org, anso...@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

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

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

Thanks,

Anupam

Sent from Outlook

[Jonathan Hao]

I'm not sure whether I misunderstood.  When I read the explainer, I didn't see any example of using the "read()" API with the new unsanitized options.  The examples seem to be all about "write()".  Could you provide some examples to the read() API please?

Thanks,

Jonathan

[Jonathan Hao]

Answering myself: I found an example: https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/unsanitized-html-demo.html

[Anupam Snigdha]

Sorry, not sure why we didn't add that example in the explainer, but I added one for read(). Thanks!

---

From: Jonathan Hao <ph...@google.com>
Sent: Monday, October 23, 2023 6:38 AM
To: blink-dev <blin...@chromium.org>
Cc: Jonathan Hao <ph...@google.com>; Anupam Snigdha <sni...@microsoft.com>; Thomas Steiner <to...@google.com>; Sanket Joshi (EDGE) <sa...@microsoft.com>; est...@chromium.org <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML

 

You don't often get email from ph...@google.com. Learn why this is important

[Rick Byers]

Hi Anupam,

I've spent an hour or so trying to follow the history of this discussion, there's obviously been a lot of debate in this space over the years. I think your answer to Thomas's question is what really clarified this specific proposal to me - you're specifically interested in the case where a native application wrote some HTML to the clipboard and a web app wants to read that without the loss of information that comes from sanitization. At the same time, this unsanitized view is already available on the legacy/synchronous DataTransfer API and so there's no new security and privacy risk here. Is that all right? If so, could you perhaps update the chromestatus motivation to make that clear please? I read that several times and struggled to really understand (perhaps it has some of the old motivation around write in there too?).  Could you also update the explainer to describe the relationship with the web custom format feature and why it's insufficient here?

I see WebKit is opposed, due to them having a different (apparently entirely unspecified) model for dealing with unsanitized html in the clipboard. That's OK, we often still spec and ship things that WebKit has objections to. But is Apple's opposition the reason there's no (as far as I have found) formal spec for this? With Mozilla on board, would we need Apple's support in order to land the changes in the clipboard API spec? I don't think the explainer quite meets our bar for requiring all APIs shipped in blink to be fully specified somewhere (even if outside the normal standards track). For example, although the explainer does describe some spec changes, it looks like some of the logic is defined in terms of blink implementation details, right? 

Our goal with the blink launch process is to create "plausible interoperability" which means doing all the work needed  (including IPR commitments) such that another implementer could easily change their mind and adopt the API. When we've hit this situation before we've relied either on 1) a formal/reviewed pull request to the spec (with preview) and an explanation for why landing the PR has been blocked, or 2) a monkey-patch spec which is still a formal spec (eg. in WICG or other incubation venue) but describes only deltas to another spec but otherwise follows standard spec conventions.  I don't think we want to be in the habit of shipping APIs with only explainers and informal API definitions. Thoughts?

Rick

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

[Anupam Snigdha]

Hi Rick,

Thank you for reviewing this I2S and apologies for all the confusion.

 you're specifically interested in the case where a native application wrote some HTML to the clipboard and a web app wants to read that without the loss of information that comes from sanitization. At the same time, this unsanitized view is already available on the legacy/synchronous DataTransfer API and so there's no new security and privacy risk here. Is that all right?

That is exactly right.

could you perhaps update the chromestatus motivation to make that clear please?

For some reason I cannot edit the Motivation section in the chromestatus page (I updated the summary though). Opened an issue for this: https://github.com/GoogleChrome/chromium-dashboard/issues/3450 

 But is Apple's opposition the reason there's no (as far as I have found) formal spec for this?

At that time we didn't receive a formal approval from Mozilla devs so we were hesitant to make changes in the official Clipboard API spec.

although the explainer does describe some spec changes, it looks like some of the logic is defined in terms of blink implementation details, right? 

I tried to closely match the spec language, but you are right that some of the logic is defined in Blink implementation details. I'm planning to remove those texts and add only the things that are relevant to this I2S (PR: https://github.com/w3c/editing/pull/456).

I don't think we want to be in the habit of shipping APIs with only explainers and informal API definitions. Thoughts? 

I think we agree with you. After having discussions with the relevant stakeholders in BlinkOn, we have decided to create a PR against the official clipboard API. I'll work on this ASAP. We'll also try to get approval from Mozilla folks as their implementation of sync DataTransfer API closely matches Blink, and at that time they agreed with us that the sanitization behavior of sync and async clipboard APIs should be the same.

Thanks,

Anupam

---

From: Rick Byers <rby...@google.com>
Sent: Wednesday, October 25, 2023 1:07 PM
To: Anupam Snigdha <sni...@microsoft.com>
Cc: Jonathan Hao <ph...@google.com>; blink-dev <blin...@chromium.org>; Thomas Steiner <to...@google.com>; Sanket Joshi (EDGE) <sa...@microsoft.com>; est...@chromium.org <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: Re: [blink-dev] Re: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML

 

You don't often get email from rby...@google.com. Learn why this is important

[Anupam Snigdha]

Spec PR: https://github.com/w3c/clipboard-apis/pull/197

-Anupam

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Monday, October 30, 2023 9:44 AM
To: Rick Byers <rby...@google.com>

[Rick Byers]

Thanks Anupam!

Hopefully folks are OK landing the spec PR, so let's see how the review goes. Please ping this thread either when it lands or if you think it's stalled and doesn't have a near-term path to landing.

Rick

[Anupam Snigdha]

Saw that the TAG review says N/A in the I2S email, so wanted to clarify that TAG did review the unsanitized option as part of the Pickling proposal. The naming was a suggestion from Chrome's security team.

For spec, we've pinged the Mozilla devs in the RFP and in the PR, but haven't received any response yet. Hopefully that means they aren't objecting to the proposal, so the plan is to land the PR after addressing the comments. If someone from Mozilla objects to this change, then we will create the PR and mark it as blocked in the official clipboard API spec. Please let us know if there is any concern with this approach.

Thanks,

Anupam

---

From: Rick Byers <rby...@google.com>
Sent: Wednesday, November 1, 2023 4:47 PM

[Anupam Snigdha]

Hi,

We just landed the spec, so I want to request review of this I2S. Thanks!

-Anupam

---

From: Rick Byers <rby...@google.com>
Sent: Wednesday, November 1, 2023 4:47 PM

[Anupam Snigdha]

We created a new chromestatus entry for this feature as the previous one's feature type was web developer facing change which is incorrect. The new chromestatus entry has feature type New feature incubation: https://chromestatus.com/feature/5203909459312640

-Anupam

---

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Tuesday, November 21, 2023 9:57 AM

[Sanket Joshi (Edge)]

Since the Chrome status entry for this I2S was changed to fix the feature type, re-sharing both links below for clarity:

Old Chrome status entry: https://chromestatus.com/feature/5716132676763648

New Chrome status entry: https://chromestatus.com/feature/5203909459312640

For the old Chrome status entry, all the feature review gates were completed aside from API owner sign off. For the new Chrome status entry, privacy and security approval are still awaiting sign off; however, we hope this is just a matter of the paperwork catching up, as there have not been any changes to the feature itself since the sign offs were obtained on the old entry.

[Yoav Weiss]

I just tried to review this and it's very difficult to understand where things are..

Can you re-send this intent, perhaps with a slightly different title so that it won't get mangled? Perhaps also a summary of the discussion on this thread?

Thanks!!

[Anupam Snigdha]

Sorry for the confusion. I created a new I2S thread for this feature: https://groups.google.com/a/chromium.org/g/blink-dev/c/jepMbayI0UM/m/78kBjpEQAAAJ?utm_medium=email&utm_source=footer

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

Thanks,

Anupam

---

From: Yoav Weiss <yoav...@chromium.org>
Sent: Wednesday, November 29, 2023 8:24 AM
To: blink-dev <blin...@chromium.org>
Cc: Sanket Joshi (EDGE) <sa...@microsoft.com>; Anupam Snigdha <sni...@microsoft.com>; ph...@google.com <ph...@google.com>; blink-dev <blin...@chromium.org>; tste...@google.com <to...@google.com>; est...@chromium.org <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano Kim <Ana.S...@microsoft.com>; Rick Byers <rby...@google.com>