Re: [w3c/editing] Seeking feedback on Clipboard Pickling APIs. (#334)

Just wanted to quickly reply to some of your concerns now. Will post another reply to the below question describing the threat model in more details:
> Again, I'm getting really confused by mixing up reading & writing of system pasteboard content. What problem exactly are we solving by explicitly requesting unsanitized format for reading or writing pasteboard content in a website / webapp. Please define the threat model of each scenario separately, and explain why an explicit request for unsanitized content is required.

If we make the process of reading/writing unsanitized content more explicit, then there is an implicit expectation that the developers are aware of the security implications and would have mitigations in place(e.g use intense fuzzing, such as provided by [OSSFuzz](https://google.github.io/oss-fuzz/)). Quoting @dway123 here as I think this response captures lot of details about why we are proposing the `unsanitized` option:
> Requiring sites to provide the unsanitized list allows sites to support both an unsanitized (for reading by the site) and sanitized (for reading by other sites/native apps) version of the same payload, in case a site requires information removed by sanitization. Therefore, writing unsanitized data by default (rather than via the unsanitized list) would also make addition of sanitized payloads by browser implementations be web-incompatible, as previously unsanitized content would become sanitized, potentially wiping metadata a site relies on.

In Chromium implementation at least, when clipboard read method is called, we query all the standard formats from the clipboard that are supported by the Browser. This would be very expensive if we have to read all custom formats as well even if the sites haven't requested for any custom formats. `unsanitized` option gives Browsers the flexibility to decide if they want to read any custom formats along with standard MIME types(such as text/html, text/plain, image/png etc) when web deveopers call `navigator.clipboard.read`.

> Why would the browser need to read both versions without this option?

Well, in clipboard read, we use the `ClipboardItem` that only takes MIME types as input. How would you know if the site is requesting unsanitized content for HTML format?
e.g. 
```
const clipboardItems = await navigator.clipboard.read();
const clipboardItem = clipboardItems[0];
const htmlBlob = await clipboardItem.getType('text/html'); // Should this return sanitized or unsanitized HTML content?
```

> When the user copies something on a website, the website shouldn't be in control of whether a given MIME type should be exposed to another app or not.

Well, async clipboard write method gives complete control to web authors as to what content should be written to the clipboard. This is being achieved by providing the MIME types in `ClipboardItem`, so I'm not sure what the concern here is exactly. Default copy operation (using execCommand or copy command when user presses ctrl+v) writes all the supported/applicable formats to the clipboard based on the selected content so this process is completely different than async clipboard read/write APIs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/334#issuecomment-909454233