Make async clipboard APIs (read/write) to sanitize interoperably with setData/getData for text/html

[gked]

Hi All,
Excel online team reached out to us on several issues they found with clipboard formats. Sanitization across legacy and async clipboard APIs is not consistent for some mime types. For example, while text/html when set with setData/getData, keeps meta tags in Chrome, async clipboard APIs strip them down.
This creates an issue for online text editing applications. Target apps, processing paste, rely on meta tags to infer information about the clipboard payload source. @snianu has wrote a detailed analysis which can be found here.
A matrix view of formats can be found here.
We propose that we make async clipboard read/write serialization behaviors consistent with legacy clipboard API such as setData/getData.
The reason being browsers already expose this information through setData/getData and making async clipboard read/write to behave in a compatible way which will ease its adoption over time.

If we can all agree on this, we will follow up with a PR clarifying the behavior in the Clipboard Spec which will also take care of #140

CC: @rniwa @whsieh @dway123 @garykac @BoCupp-Microsoft @megangardner @johanneswilm

[dway123]

I'm supportive of having datatransfer and navigator.clipboard (async clipboard) APIs be consistent in their sanitization behavior of text/html (and other formats). Thank you for the detailed analysis, and for offering to help update the spec to clarify this!

[annevk]

How did the discrepancy arise in Chrome? Part of the plan with https://wicg.github.io/sanitizer-api/ is to get this all standardized. Does that meet the requirements you have?

cc @mozfreddyb @otherdaniel

[otherdaniel]

Part of the plan with https://wicg.github.io/sanitizer-api/ is to get this all standardized. Does that meet the requirements you have?

I don't know much about the specific question here, but on clipboard vs Sanitizer API: This is a v2 item. One major block of functionality missing is that the clipboard sanitizers do some form of style normalization, while the Sanitizer is presently HTML only.

If you want to help this along: I haven't found any documentation from any browser about how the style normalization actually works. It seems all browser engines have implemented something along those lines, and somehow they all forgot to document what they actually do. Describing the existing functionality would help a lot in getting this into Sanitizer API.

[snianu]

How did the discrepancy arise in Chrome? Part of the plan with https://wicg.github.io/sanitizer-api/ is to get this all standardized. Does that meet the requirements you have?

The DataTransfer APIs are legacy APIs that probably have this behavior due to IE and backward compatibility. This is the reason why Firefox & Chromium browsers return the HTML markup string as is when queried via getData method i.e. they don't strip out style and meta tags from the HTML markup string.

I think the issue here is that due to strict sanitization performed by async clipboard APIs (that don't mutate the DOM directly) websites lose style information, meta tags etc when content is copied from Chromium and pasted into native apps. Office online & Office native apps use proprietary style formats in the HTML and the browser's in-built sanitizer removes this content from the HTML markup when it's read/written via async clipboard APIs.

The sanitizer API can certainly be used by web authors to sanitize the HTML content if they want to, but we should give them the flexibility to decide whether to use the Browser sanitizer API or their own proprietary sanitizer service.

[rniwa]

How did the discrepancy arise in Chrome? Part of the plan with https://wicg.github.io/sanitizer-api/ is to get this all standardized. Does that meet the requirements you have?

No. One of the reasons we sanitize the markup content is to strip way any content that's invisible to the user so we strip away any invisible content as determined by the style & layout information. We're not gonna change that.

[snianu]

@rniwa I don't think that is the issue here. Although Safari doesn't remove any meta, style etc tags from the custom pasteboard format which it creates during setData, and reads from the custom pasteboard format during getData. The standard HTML format has the sanitized version, but if a site is writing and reading via DataTransfer APIs then they get the unsanitized HTML content.

[rniwa]

@rniwa I don't think that is the issue here. Although Safari doesn't remove any meta, style etc tags from the custom pasteboard format which it creates during setData, and reads from the custom pasteboard format during getData. The standard HTML format has the sanitized version, but if a site is writing and reading via DataTransfer APIs then they get the unsanitized HTML content.

We only apply sanitization when the content is read or written across cross origin or cross applications, not when read or written within a single origin.

[dway123]

How did this discrepancy arise in Chrome?

If you want to help this along: I haven't found any documentation from any browser about how the style normalization actually works.

@snianu's understanding seems correct (this was recently documented in lots of misc CL comments).

fwiw I've drafted some documentation for my understanding of Chrome's clipboard, including a brief history/summary of how/what we sanitize.

[snianu]

@rniwa

We only apply sanitization when the content is read or written across cross origin or cross applications, not when read or written within a single origin.

This means you trust the clipboard content during read? I think clipboard content should always be treated as untrusted. It doesn't matter if Safari wrote the html payload to the clipboard or some malicious or trusted native apps did.

[snianu]

We want to standardize the clipboard sanitization procedure as it has caused issues for many popular apps while using async clipboard HTML read/write. The spec says that during write, we should only write the sanitized payload of the item, but doesn't say anything about what the process of sanitization looks like and what kind of data is expected in the clipboard item. e.g. when writing HTML payload using the async clibpoard write, what should be the format of the HTML markup string? Should it be a document fragment or complete HTML document?
The read operation doesn't specify anything about sanitization and I found that Chromium is performing strict sanitization for both HTML read & write operation which breaks sites like Excel online as mentioned in this bug. I agree that we should at least strip out tags such as script & elements that have javascript: protocols associated with them as they are harmful, but we should mention explicitly what tags are stripped out in this process so it sets an expectation for the web developers & native apps who are reading these formats.

Also FWIW currently at least in Chromium & Firefox, we write unsanitized HTML content to the clipboard when web developers use setData method, and AFAIK there are no known security threats as we still use the strict sanitization when user pastes the data into an editable region of the website. Web developers have proper sanitization process when they query the HTML markup using getData[4].
Currently websites like Office online use setData & getData methods to read/write html content that don't do any sanitization to support high fidelity copy/paste content. Native apps(including Office) are already exposed to these types of HTML content from the clipboard. In the browser, we can perhaps do some level of sanitization during read (as it might affect the DOM when sites insert the fragment) if that is a concern, but we shouldn't be aggressively sanitizing content during write (to be in parity with DataTransfer APIs).

To better describe the sanitization & clipboard write process for HTML payload we propose the following:

1. Currently we process the HTML string as a document fragment that basically ignores the content inside the <head> element. This leads to loss of styles[1], meta tag etc. while parsing the document fragment. Instead we are proposing to parse the string provided to the async write API as an HTML document. Insert the start & end fragment comment tags within the body element, and then create a well formed HTML document.
2. Use the sanitizer APIs default configuration[2] to sanitize the HTML document. This makes the sanitization process consistent with what is being proposed in the sanitizer API[3].
3. Create the HTML header info (corresponding to each platform) and then write the HTML format to the clipboard.

[1] Here is a GIF that shows the style loss when user copies and paste from Excel online to win32 Excel app: https://drive.google.com/file/d/1Nsyp1rUKc_NF4l0n-O05snAKabHAKeiG/view
[2] https://wicg.github.io/sanitizer-api/#default-configuration
[3] https://wicg.github.io/sanitizer-api/#sanitizer-algorithms
[4] https://github.com/ckeditor/ckeditor5/blob/9ad13ec94d77e10e4ddf678e86577acb107db3fb/packages/ckeditor5-clipboard/docs/framework/guides/deep-dive/clipboard.md

[a-sully]

Not entirely related, but I'll chime in about the state of image (PNG) sanitization to provide a +1 for updating the spec to make the sanitization process more explicit. The spec mentions that images should be "safe", but (as you noted) is silent on the specifics of this sanitization, leading to inconsistencies across browsers.

Currently in Chrome, images are sanitized on both read and write. Skia is used to strip almost all metadata, retaining only what fits in an SkBitmap. This behavior is inconsistent with other major non-Chromium browsers, which do not sanitize images on read (see https://crbug.com/1177229).

We've proposed to change Chrome to only sanitize images on write to align with other browsers. Note that this allows a site to read an unsanitized PNG directly from the system clipboard, so the "only sanitize on write" approach there is not acceptable for HTML data (and seems to be the opposite direction of what's being proposed above for HTML). In updating the spec to be more explicit about sanitization procedures (which I agree we should do) we'll have to spell out the process for each type we care about, since there is no prescriptive sanitization process that works for all types.

[annevk]

@snianu thanks for tackling this! Could you detail step 1 a bit more? If I do something like document.body.innerHTML = "<meta><style>test</style>" it shows that the fragment parser is also capable of preserving certain elements so I'd like to see more detail on the exact problem and also the proposed solution (e.g., what's a fragment comment tag?).

[mozfreddyb]

Early on during our work on the sanitizer, we've been eying the issue of incoherent, implicit sanitizer usage during copy&paste. I'm very much in favor of specifying things more explicitly.

[mbrodesser]

We want to standardize the clipboard sanitization procedure as it has caused issues for many popular apps while using async clipboard HTML read/write. The spec says that during write, we should only write the sanitized payload of the item, but doesn't say anything about what the process of sanitization looks like and what kind of data is expected in the clipboard item. e.g. when writing HTML payload using the async clibpoard write, what should be the format of the HTML markup string? Should it be a document fragment or complete HTML document?
The read operation doesn't specify anything about sanitization and I found that Chromium is performing strict sanitization for both HTML read & write operation which breaks sites like Excel online as mentioned in this bug. I agree that we should at least strip out tags such as script & elements that have javascript: protocols associated with them as they are harmful, but we should mention explicitly what tags are stripped out in this process so it sets an expectation for the web developers & native apps who are reading these formats.

Also FWIW currently at least in Chromium & Firefox, we write unsanitized HTML content to the clipboard when web developers use setData method, and AFAIK there are no known security threats as we still use the strict sanitization when user pastes the data into an editable region of the website. Web developers have proper sanitization process when they query the HTML markup using getData[4].
Currently websites like Office online use setData & getData methods to read/write html content that don't do any sanitization to support high fidelity copy/paste content. Native apps(including Office) are already exposed to these types of HTML content from the clipboard. In the browser, we can perhaps do some level of sanitization during read (as it might affect the DOM when sites insert the fragment) if that is a concern, but we shouldn't be aggressively sanitizing content during write (to be in parity with DataTransfer APIs).

To better describe the sanitization & clipboard write process for HTML payload we propose the following:

1. Currently we process the HTML string as a document fragment that basically ignores the content inside the `<head>` element. This leads to loss of styles[1], meta tag etc. while parsing the document fragment. Instead we are proposing to parse the string provided to the async write API as an HTML document. Insert the start & end fragment comment tags within the `body` element, and then create a well formed HTML document.

Be aware that start and end fragment comment tags are Windows-specific. On other operating systems (e.g. Ubuntu), that will have to be handled differently.

2. Use the sanitizer APIs default configuration[2] to sanitize the HTML document. This makes the sanitization process consistent with what is being proposed in the sanitizer API[3].

3. Create the HTML header info (corresponding to each platform) and then write the HTML format to the clipboard.

How is the HTML header info platform-specific?

[1] Here is a GIF that shows the style loss when user copies and paste from Excel online to win32 Excel app: https://drive.google.com/file/d/1Nsyp1rUKc_NF4l0n-O05snAKabHAKeiG/view
[2] https://wicg.github.io/sanitizer-api/#default-configuration
[3] https://wicg.github.io/sanitizer-api/#sanitizer-algorithms
[4] https://github.com/ckeditor/ckeditor5/blob/9ad13ec94d77e10e4ddf678e86577acb107db3fb/packages/ckeditor5-clipboard/docs/framework/guides/deep-dive/clipboard.md

[mbrodesser]

@snianu thanks for tackling this! Could you detail step 1 a bit more? If I do something like document.body.innerHTML = "<meta><style>test</style>" it shows that the fragment parser is also capable of preserving certain elements so I'd like to see more detail on the exact problem and also the proposed solution (e.g., what's a fragment comment tag?).

Presumably <!--StartFragment--> and <!--EndFragment--> were meant, see https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767917(v=vs.85).

[snianu]

@snianu thanks for tackling this! Could you detail step 1 a bit more?

Sure. Step 1 basically creates the document object from the HTML string provided by the web authors. It could just be a document fragment or a full HTML document . We use the DOMParser to create a well formed HTML document from the input, and then use the sanitizer API to strip out harmful contents from the markup. After this step, we insert platform specific header info into the serialized document and then write it to the clipboard.

Here is a more detailed proposal for the HTML sanitization:

1. First we create a DOMParser object that can be used to parse the string provided by the web authors and get a document object. We use the algorithm defined in parseFromString for text/html type to parse the html string.
2. Then, we want to use the Sanitizer API to strip out harmful contents such as script tags. Currently we don't have a way to parse and get a full HTML document using the sanitize method, but we want to do something like how sanitizeFor would parse an HTML document element using the html as element & doc.documentElement.innerHTML (where doc is the document from step 1) as the input
3. In the last step, we want to create HTML platform specific header and add it to the markup string which is the HTML document from step 2 serialized into string. Examples of platform specific headers are given below:
   On Windows, we have:

Version:0.9
StartHTML:<start offset of the start html tag>
EndHTML:<start offset of the end html tag>
StartFragment:<start offset of the start fragment comment tag>
EndFragment:<start offset of the end fragment comment tag>
<html>
<body>
<!--StartFragment-->
<body content goes here>
<!--EndFragment-->
</body>
</html>

On Linux we have:

<meta http-equiv="content-type" content="text/html; charset=utf-8">

etc...
Tagging @mkruisselbrink @a-sully if this proposal looks good to them.

[annevk]

@snianu I would also like to understand why the fragment parser does not suffice, as it seems to preserve the elements you indicated were dropped.

[snianu]

@annevk

@snianu I would also like to understand why the fragment parser does not suffice, as it seems to preserve the elements you indicated were dropped.

If we parse the HTML markup string in the context of body element, then it wouldn't parse the contents of the html & head elements properly. We want to process the string as a complete HTML document using the DOMParser so it parses the contents of html & head in the context that the authors intended.
Also, if we inline each and every style that are applicable to the content of the body, then it would bloat the HTML markup on the clipboard. e.g. If you copy a grid from Excel Online where the cells have different formats, inlining the styles would produce a huge markup where each td & tr elements would have a different style. Having just a style element in the head not only preserves the styles applicable to all the cells, but also produces a small HTML markup on the clipboard.

[annevk]

But as I showed elements such as style and meta are preserved by the fragment parser. And if you put everything as a child of the body element in the end anyway I fail to see the point.

[travisleithead]

Sept. WG Meeting: discussed @snianu's proposal above. Good learnings. No immediate actions/resolutions.

[BoCupp-Microsoft]

@annevk maybe I can clarify...

@snianu's goal is process markup like this: some text into: <html><head></head><body>some text</body></html> and also markup like this:

<!DOCTYPE html>
<html dir="ltr" lang="en">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<style>
table
	{mso-displayed-decimal-separator:"\.";
	mso-displayed-thousand-separator:"\,";}
tr
	{mso-height-source:auto;}
col
	{mso-width-source:auto;}
td
	{padding-top:1px;
	padding-right:1px;
	padding-left:1px;
	mso-ignore:padding;
	color:black;
	font-size:11.0pt;
	font-weight:400;
	font-style:normal;
	text-decoration:none;
	font-family:Calibri, sans-serif;
	mso-font-charset:0;
	text-align:general;
	vertical-align:bottom;
	border:none;
	white-space:nowrap;
	mso-rotate:0;}
.xl16
	{color:black;
	font-family:Calibri;
	mso-generic-font-family:auto;
	mso-font-charset:0;
	background:#E7E6E6;
	mso-pattern:black none;}
.xl17
	{color:black;
	font-family:Calibri;
	mso-generic-font-family:auto;
	mso-font-charset:0;
	background:#D9E2F3;
	mso-pattern:black none;}
.xl18
	{color:black;
	font-family:Calibri;
	mso-generic-font-family:auto;
	mso-font-charset:0;
	background:#E2EFD9;
	mso-pattern:black none;}
</style>
</head>

<body link="#0563C1" vlink="#954F72">

<table width=192 style='border-collapse:collapse;width:144pt'>
<!--StartFragment-->
 <col width=64 style='width:48pt' span=3>
 <tr height=20 style='height:15.0pt'>
  <td width=64 height=20 class=xl16 style='width:48pt;height:15.0pt'>One</td>
  <td width=64 class=xl17 style='width:48pt'>Two</td>
  <td width=64 class=xl18 style='width:48pt'>Three</td>
 </tr>
 <tr height=20 style='height:15.0pt'>
  <td height=20 align=right style='height:15.0pt'>1</td>
  <td align=right>2</td>
  <td align=right>3</td>
 </tr>
<!--EndFragment-->
</table>
</body>
</html>

Into a DOM that represents all the content basically as written above including the attributes of the HTML element.

If we use the fragment parser we need to provide a context element. Let me know if I'm mistaken but I don't see anything in the spec about how we could we can initialize the fragment parser so that it sets up the HTML parser in the initial insertion mode. So the best we could do with the fragment parser given the second markup example I provided is to use an html element as our context and then have the parser throw away the DOCTYPE and original html node along with its attributes.

[rniwa]

I must point out that those start fragment & end fragment marker is Windows specific construct that doesn't apply to Apple's platforms. In Apple's platforms, it is pasteboard data provider's responsibility to serialize HTML in such a way as to preserve all its styles (typically with inline style content attributes).

[BoCupp-Microsoft]

I must point out that those start fragment & end fragment marker is Windows specific...

@rniwa I agree... I wasn't trying to make any particular point by including those, I was just grabbing some real markup as supplied by Excel Online to setData.

[rniwa]

I must point out that those start fragment & end fragment marker is Windows specific...

@rniwa I agree... I wasn't trying to make any particular point by including those, I was just grabbing some real markup as supplied by Excel Online to setData.

I get that. But your primary point is that we need some special way of initializing the fragment parser. I'm saying that this is not the case in Apple's platforms so this issue is at best applicable to some platforms; put it differently, the issue presents itself in different ways in different platforms. I don't think there is a way to create an interoperable behavior here given what gets put into the system's pasteboard / clipboard is dependent on that specific platform.

[BoCupp-Microsoft]

But your primary point is that we need some special way of initializing the fragment parser...

I'm glad you brought that up. Actually, the discussion on the fragment parser is a bit of a tangent and a means to an end. The primary point is captured in Anupam's first sentence in this comment:

We want to standardize the clipboard sanitization procedure...

I do think it's possible to standardize what authors should expect to be sanitized away from the data that they supply to navigator.clipboard.write for our well-known mime-types. So the key point in Anupam's post is really this:

...we want to use the Sanitizer API to strip out harmful contents...

I believe his initial thinking is to sanitize clipboard using the Sanitizer's default configuration, which leaves things like style and meta tags but removes harmful script tags and javascript: URLs etc. (more detail available in the Sanitizer spec).

@whsieh covered today in the Web Editing WG meeting that Safari prefers to also remove content that would be invisible like comments, display:none, opacity: 0, etc. So maybe we could define a configuration and/or upgrades to the sanitization algorithm that does that too if we decide that's important aspect to keep.

Any objection to standardizing what a "sanitized copy" means to remove ambiguity from the clipboard API's write algorithm?

[rniwa]

Any objection to standardizing what a "sanitized copy" means to remove ambiguity from the clipboard API's write algorithm?

This is an area of the browser engine (and the operating system) that we'd like to continue to make improvements on so I don't think we want to prematurely shoehorned into a very specific algorithm. Furthermore, even if someone were to make a concrete proposal and we were to agree with the generic algorithm in principle, it's very much unlikely that anything remotely close to it will be implemented in WebKit in the foreseeable feature since there are specific concerns and constraints we're dealing with Apple's platforms.

[mozfreddyb]

I'd be very much in favor of removing ambiguity from the term "sanitized copy". It's very vague right now.

@rniwa Can you share some of the constraints?

Maybe there's a way to remove some grade of ambiguity while respecting those constraints?

[rniwa]

Sure. This is a trade off between that and user privacy and we chose to value user's privacy more than those concerns.

Well, broken functionality is worse than user "privacy".

That's just your opinion.

Quoting "privacy" because I haven't seen any real-world examples of the privacy risks that you are citing in all your responses. We have discussed this in the Editing WG meetings as well and we are yet to see an example of sites exposing user mailing address. Local file path that you referred to in your earlier response is a temporary folder exposed by Office native apps to support image pasting because converting into base64 encoded image has other issues related to perf, clipboard payload size restriction, delay rendering issue related to resources being available at a later point in time, which I think is orthogonal to this issue.

I've mentioned how to get this time and time again. You can literally launch Microsoft Office products on macOS and copy stuff and see what kind of markup is put into the pasteboard.

I'd emphasize my point once again: Different browser vendors have different priorities and as such, we're not interested in standardizing copy & paste sanitization behavior at this point since we clearly have differing opinion about what the proper level of protection for user's privacy or how much value should be put into the web & app compatibilities.

[snianu]

After some quick testing, this is a snippet of the raw markup saved to NSPasteboard after copying from Microsoft Word for Mac (version 16.53):

Yes, Word and other Office native apps do provide a local image urls, but that doesn't expose user's mailing address. I think we have a separate issue to address this which might alleviate your concern regarding the user's home directory and temp folder.

[rniwa]

I'm done explaining our position here. We are under no obligation to agree to your proposals. We're not gonna change our implementation, and that's the end of this discussion.

[css-meeting-bot]

The Web Editing Working Group just discussed Sanitize clipboard issue.

The full IRC log of that discussion

<Travis> Topic: Sanitize clipboard issue
<Travis> github: https://github.com//issues/150
<Travis> BoCupp: what do we need from the WG on this issue?
<Travis> snianu: We will be taking this discussion to the chromium security group (for chromium only).
<Travis> BoCupp: pastes are unpredictable...
<Travis> .. can't tell if a 3rd party messes with the clipboard.
<Travis> .. the question is whether there's some expected behavior from App to browser...
<Travis> whsieh: We were thinking about adding things to the spec to fix compatibility in the short term. But, if we keep this the same (left to user agent discretion), we are OK with that.
<Travis> BoCupp: We don't think that keeping the spec as-is will be harmful, etc. Propose we can close the issue now.
<Travis> ACTION: BoCupp to close this issue; keep whsieh appraised of the security review (as FYI).

[BoCupp-Microsoft]

Per the log of the last Web Editing WG meeting above, we agreed to leave the details of sanitization up to the UA, i.e. we won't attempt to standardize it at this time. Additionally, to leave room for Safari to implement cross-origin restrictions or whatever policy they would like to use to govern access to the pickled formats (which are also unsanitized) @snianu will land the PR for clipboard pickling without mentioning the usanitized option for ClipboardItems and remove any language that talks about when to sanitize or not or allow access to pickled data or not. I think adding a note saying that those particular behaviors are UA specific would be a good addition in the spec.

We don't think this will affect the developer experience. We do expect that depending on whatever sanitization level the UA chooses to apply will just change the fidelity of the markup available to a paste operation, but developers don't need to write different code and do need to deal with any shape of markup from the clipboard already.

Closing this issue. If you think there needs to be any further discussion please reactivate. Thanks!

[annevk]

Even if we don't define the details of sanitization, which seems like a mistake and something that needs revisiting in due course, I do think we should require the legacy and new API to behave in an equivalent manner. I think it's very surprising that they end up with different results.

[BoCupp-Microsoft]

@annevk I'm not clear on what you're proposing. If we aren't standardizing (at least for now) whether or not to sanitize or what sanitizing is then what are you proposing we should change? Do you just want us to write down that both APIs should be aligned in terms of whatever sanitization steps they choose to apply?

[snianu]

In addition to @BoCupp-Microsoft 's comment above, we also want to set some expectations here. We are NOT going to change anything in the legacy DataTransfer APIs as that would break our first party apps and legacy Win32 Office apps that are still being used in enterprises. If the expectation here is to align async clipboard APIs with the DataTransfer APIs, then I propose to open a new issue as from the comments above it is pretty clear that we are not going to come to an agreement. At least on Windows we want to provide the best developer and user experience. We are not going to compromise on functionality that would worsen the experience on our platform.

[annevk]

@BoCupp-Microsoft right.

@snianu how would moving things to a new issue help matters?

[snianu]

@snianu how would moving things to a new issue help matters?

It probably wouldn't and that is why we decided to close this issue. I'm not sure why you reopened it?

[snianu]

@annevk @mbrodesser Could you please clarify Mozilla's position on providing the sanitization behavior for async read/write methods for well-known formats? From @annevk's proposal here, it sounds like you agree that we shouldn't be sanitizing text/html during read/write as the DataTransfer APIs don't. I think we'd support that proposal as it aligns with our needs. If you agree with that, then I think we can add it to the clipboard API spec since there are two implementers that support this proposal. Thoughts?

[annevk]

My proposal doesn't attempt to resolve this one way or another. It merely adds support for a parallel set of formats that are never sanitized.

I think for built-in formats we want:

• The same behavior for the new and legacy API.
• Optional, implementation-defined modification of the contents to uphold user agent privacy requirements.

[snianu]

My proposal doesn't attempt to resolve this one way or another. It merely adds support for a parallel set of formats that are never sanitized.

I think it does affect the well-known formats at least on Safari. Consider the below case:
When text/html is copied from website X and pasted within the same origin that X belongs to, then Safari returns the content from the pickled html format (no sanitization involved). With your proposal, now Safari will return sanitized fragment when author queries text/html from X as the pickled HTML format lives in "web text/html". Basically, your proposal doesn't work on Safari which I'm not sure is an issue because Apple doesn't want to support custom format in cross origin anyway, so they can always return the pickled format from "web " bucket if queried from the same origin for text/html.

Now, on Chrome and Firefox, regardless of what origin the author queries text/html from, DataTransfer APIs always return unsanitized HTML format, but this is different from pickled format as the standard HTML format contains platform specific headers as described here. These headers are stripped out, but the HTML markup is a full HTML document, not a sanitized fragment. With your proposal, we have to return unsanitized HTML document with platform specific headers stripped out when authors queries text/html format. Is that correct?

[annevk]

If someone copies text/html onto the clipboard, why would a web text/html entry be created? That doesn't make sense. (I also don't think Apple said they don't want to support web ... formats across origins.)

[whsieh]

I think it does affect the well-known formats at least on Safari. Consider the below case: When text/html is copied from website X and pasted within the same origin that X belongs to, then Safari returns the content from the pickled html format (no sanitization involved). With your proposal, now Safari will return sanitized fragment when author queries text/html from X as the pickled HTML format lives in "web text/html". Basically, your proposal doesn't work on Safari which I'm not sure is an issue because Apple doesn't want to support custom format in cross origin anyway

The way I understood Anne's proposal, if site X wrote "text/html" and then site X reads "text/html", in WebKit, there would be a single item "text/html" that would contain the original unsanitized data upon reading.

If site Y were to read the same data copied from site X, it would contain the sanitized "text/html" data.

[BoCupp-Microsoft]

@snianu and I discussed offline. I don't see any of the points discussed since this post from @annevk as being a blocker for us.

Both of the points mentioned:

• The same behavior for the new and legacy API.
• Optional, implementation-defined modification of the contents to uphold user agent privacy requirements.

...allow for Apple's preferred same-origin behavior, as well as our preferred behavior for Chromium, which is to allow unsanitized access to well-known formats like text/html, which would be consistent with our current behavior for the legacy Clipboard Event API.

[snianu]

Closing this issue as it's resolved in #174