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

The Web Editing Working Group just discussed `Seeking feedback on Clipboard Pickling APIs`.

<details><summary>The full IRC log of that discussion</summary>
&lt;Travis> topic: Seeking feedback on Clipboard Pickling APIs<br>
&lt;Travis> github: https://github.com/w3c/editing/issues/334<br>
&lt;tilgovi> bo: right now we have a GitHub issue continuing security review led by some GitHub engineers. The last consensus that we had was that we want to document a format for interchange between native apps and web application. We agreed we would write that in a non-normative note.<br>
&lt;tilgovi> ... we had some disagreement on the sanitization procedures for both read and write<br>
&lt;tilgovi> ... Our proposal has been that when we read, we could supply a new option, "unsanitize", that takes a list of content types to read without sanitization<br>
&lt;tilgovi> ... We maintain that it's unnecessary to sanitize on write to the clipboard. Certainly for clipboard pickling, you can't sanitize a format you don't understand. More importantly, for the well-known format text/html, we want to be able to write it unsanitized. We detailed the impact that it has on applications if we lose the fidelity of writing unsanitized HTML.<br>
&lt;tilgovi> ... We had resolved that we would allow user agents to sanitize or not, at the last special meeting. I don't think we have anything new.<br>
&lt;tilgovi> Anne: It sounds quite bad for web developers, everything that is optional.<br>
&lt;tilgovi> Wenson: it would be nice to reiterate why sanitize is necessary on read.<br>
&lt;tilgovi> Bo: At least with Chromium implementation, if you Ctrl+V, if you don't do anything, we process HTML before we put it into the document. We make "insert ready" HTML.<br>
&lt;tilgovi> Bo: Unlike the legacy API, that returns unsanitized content, Chromium browsers produce an insert ready fragment today. This has a side effect of degrading the fidelity of the HTML that the application can see.<br>
&lt;tilgovi> ... the web application for Word online is not able to change to the new API because it needs style rules inserted by MS Word. In a nutshell, supporting unsanitized is backwards compatibility.<br>
&lt;snianu> Some context on the HTML sanitization issue: https://github.com/w3c/clipboard-apis/issues/150<br>
&lt;tilgovi> Wenson: When we shipped sanitization for clipboard, at lest for cross-origin, all data is sanitized. Including native to web app<br>
&lt;tilgovi> ... We have certain quirks in the algorithms for sanitization, some of them for things like MS Office, to make some workflows work.<br>
&lt;Travis> q?<br>
&lt;tilgovi> Bo: I think it might be hard to specify the quirks we would need.<br>
&lt;johanneswilm> q+<br>
&lt;Travis> ack johanneswilm<br>
&lt;tilgovi> johanneswilm: The thing that you're saying about exceptions is not really accessible to developers making applications. It would be good if this doesn't just happen to work in MS Word.<br>
&lt;tilgovi> Wenson: There are security goals we need to uphold, but workflows we acknowledge will be useful for unsanitized content. For those we want to expose native APIs that allow apps to expose raw content if they want to do so, knowing that it's going to be read by arbitrary web content. That is something we want to support, but I don't think we can do it and uphold security goals at the same time.<br>
&lt;BoCupp> q+<br>
&lt;tilgovi> annevk: I have a question about security goals.<br>
&lt;tilgovi> ... say there is a cross origin exchange, web->web or native->web. Either they could agree to use a pickled type, or they could agree to opt into unsanitized behavior. I'm not sure what the difference is between using a new MIME type or a MIME type with unsanitized.<br>
&lt;tilgovi> BoCupp: the difference is for native apps that are already writing the well-known HTML format, can web apps read that existing HTML. If they both opt into using text/html2, they can. But it should be acceptable for them to read text/html as they exist today.<br>
&lt;tilgovi> ... Native -> web, Wenson railed a concern that native apps might put in comments author metadata that might reveal private information.<br>
&lt;tilgovi> Wenson: there are real world examples of this. MS Word will put a user's file paths within attributes that get copied.<br>
&lt;tilgovi> johanneswilm: one question here. One example I've heard is MS word file paths and this is what all this about. But MS word is also the one application you happen to make exceptions for in the paste rules. But this affects other applications, too, right?<br>
&lt;Travis> q?<br>
&lt;tilgovi> Wenson: that's currently the case, yes.<br>
&lt;Travis> ack BoCupp<br>
&lt;tilgovi> BoCupp: this is just a recap of the special meeting. We have scenarios we need to enable. We differ in behavior today, and we haven't come to consensus except to say this is all optional.<br>
&lt;tilgovi> annevk: there was agreement to make it optional?<br>
&lt;tilgovi> BoCupp: we did agree we could write "browser MAY do this".<br>
&lt;tilgovi> Wenson: that is correct<br>
&lt;tilgovi> annevk: that was instead of an "unsanitized" options bag that some implementation might ignore?<br>
&lt;tilgovi> BoCupp: can someone propose a step for moving forward?<br>
&lt;tilgovi> BoCupp: from our perspective, it's not locked down with the legacy APIs and it's unfortunate that the new APIs don't allow the same support. Our customers can't use it as it's currently authored.<br>
&lt;tilgovi> annevk: I see it as Chromium has a privacy bug in its legacy APIs.<br>
&lt;tilgovi> BoCupp: well, the idea that HTML as a format isn't meant to be shared with the web is strange.<br>
&lt;tilgovi> Anupam: Firefox also returns unsanitized content.<br>
&lt;tilgovi> ... If there was privacy or security concern it's been there for decades.<br>
&lt;snianu> The issue that I linked above shows how FF, Chrome, Edge(old and new) return unsanitized HTML content via DataTransfer APIs.<br>
&lt;tilgovi> rrsagent, bookmark<br>
&lt;RRSAgent> See https://www.w3.org/2021/10/29-editing-irc#T16-32-41<br>
</details>


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