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

> Thank you @rniwa for the feedback! I've addressed your comments below. Please let me know if you have further questions!
> 
> > Per prior discussion, for (1), native applications must opt-in to expose information to web apps directly. So, solving this problem requires some kind of agreement between native applications and web browsers to do this.
> 
> That is correct. We want native apps and sites to explicitly opt-in to reading the custom formats from the clipboard so we don't expose potentially harmful content without the sites/apps being aware of the security implications. `unsanitized` option lists the formats that we want to expose to the clipboard without performing any kind of sanitization. This could contain custom formats defined by sites like Excel Online(e..g a shadow workbook) as well as standardized formats (such as HTML, PNG etc) predefined by the OS. Sites would use this option to read/write unsanitized formats that the native apps can use (or vice versa) to provide high fidelity copy-paste. e.g. Excel Online would use this API to read/write shadow workbook that could contain tables with formulas and other rich formats. That way browsers don't have to add explicit support for these formats and sites/apps can leverage custom formats to enable this feature.

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.

> > The proposal also suggests adding ability to write unsanitized version of things. Again, I'm unsure why this is needed. Why can't the browser always make unsanitized version available to native apps which request it? Why does a website explicitly need to request this?
> 
> The `unsanitized` option is particularly useful when [reading/writing standardized formats](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickled-version-for-sanitized-formats) as that is the default set of formats that all browsers support. This option helps us to only read the unsanitized version of the standard formats that were requested by the web author so we don't have to read both sanitized and unsanitized version of all the standard formats that are present on the clipboard.

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

> It is described [here ](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#alternative-considered-unsanitizedtrue)in the explainer. If the web authors provide custom format in the `unsanitized` list, then we will only request the unsanitized version of the custom format. The standard formats mentioned in the read/write async APIs will be processed as usual i.e. read/write with proper sanitization steps.

I really don't follow the description there. 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. Namely, if a website rewrite "unsanitized" HTML markup, then the browser *SHOULD* provide both sanitized version & unsanitized version to other native applications at least on Apple platforms.

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