Re: [w3c/clipboard-apis] Make async clipboard APIs (read/write) to sanitize interoperably with setData/getData for text/html (#150)

The Web Editing Working Group just discussed `Make async clipboard APIs (read/write) to sanitize interoperably`.

<details><summary>The full IRC log of that discussion</summary>
&lt;Travis> topic: Make async clipboard APIs (read/write) to sanitize interoperably<br>
&lt;Travis> github: https://github.com/w3c/clipboard-apis/issues/150<br>
&lt;Travis> BoCupp: pull request open in chromium to write unsanitized to the clipboard (for well-known HTML format) AND reading with well-known format if unsanitized flag provided.<br>
&lt;whsieh> q+<br>
&lt;Travis> .. specific action for 150?<br>
&lt;Travis> anupam: we decided that reading unsanitized HTML, web authors can opt-in to unsanitized text/html using new option (that takes a list of mime-types to read unsanitized).<br>
&lt;Travis> BoCupp: That's the current plan for chromium<br>
&lt;Travis> .. from @rniwa last comment is that this isn't something we want standardized.<br>
&lt;Travis> ack whsieh<br>
&lt;Travis> whsieh: when we last discussed, @annevk noted an API that blink would implement, but webkit would implement (but perhaps as a no-op).<br>
&lt;Travis> .. we wanted unsanitized flag for compat with those who already adopted the read API.<br>
&lt;Travis> .. how widespread is the adoption?<br>
&lt;Travis> .. seems more sensible to move forward without sanitization for Blink?<br>
&lt;Travis> .. just have the clients use the unsanitzed data?<br>
&lt;Travis> anupam: I check the usage, it's 0.001 / 0.002<br>
&lt;Travis> BoCupp: read is giving an "insert-ready" content... if these sites were relying on the browser to sanitize, could create a XSS vuln that we are creating...<br>
&lt;Travis> whsieh: potential for XSS is present anyway (where there is no sanitization)<br>
&lt;Travis> BoCupp: but we're changing the contract; there's an expectation that they have to write a sanitizer.. when they switch to read, they may have been glad that sanitizer is provided by the browser.<br>
&lt;Travis> .. but if update the contract--nothing will signal to these people that they need to change to start sanitizing.<br>
&lt;Travis> .. agree with whsieh points... but tough to change from sanitized->unsanitized.<br>
&lt;Travis> whsieh: so does this need to be put into the spec?<br>
&lt;Travis> .. seems more of a problem just for an implementation (blink)<br>
&lt;Travis> .. maybe something that's not in the spec could be put in place for this case?<br>
&lt;Travis> BoCupp: does webkit ever return unsanitized?<br>
&lt;Travis> whsieh: copy/paste between same origin does this.<br>
&lt;Travis> BoCupp: Oh, I thought you always produced a sanitized read?<br>
&lt;Travis> whsieh: yes, that's for getData... we have a bug to do this for clipboard...<br>
&lt;Travis> BoCupp: so you might have the same concern for that when you make that future change?<br>
&lt;Travis> whsieh: in async clipboard, they always get sanitized.<br>
&lt;Travis> .. don't expect there to be huge problems with getting unsanitized data.<br>
&lt;Travis> BoCupp: we have a security review issue open; chromium security folks were saying we needed to be explicit. I think for read? or was it write?<br>
&lt;Travis> .. in any case, need to cross-review with security folks.<br>
&lt;johanneswilm> q+<br>
&lt;Travis> .. suspect perhaps might not fly<br>
&lt;Travis> whsieh: fwiw, that's webkit's stance.<br>
&lt;Travis> .. maybe just not something that's in the spec.<br>
&lt;Travis> BoCupp: there's a usefulness to this also--having the browser produce an "insert ready" fragment (like the default action for paste)<br>
&lt;Travis> .. there's no primitive that exposes the browser's default processing.<br>
&lt;Travis> .. Can get the clipboard data from a read today without needing complicated workarounds.<br>
&lt;Travis> ack johanneswilm<br>
&lt;Travis> johanneswilm: if usage is low, and text editing is happening in only a handful of libraries--could we check with them on if that's the major usage?<br>
&lt;BoCupp> q+<br>
&lt;Travis> .. the "they have to just put it in the DOM without thinking" is dangerous--leads to them allowing everything to go through--but tables could break editor scenarios... JS sanitiation is usually needed anyway.<br>
&lt;Travis> ack BoCupp<br>
&lt;Travis> BoCupp: The default browser behavior for paste is to just insert it into contenteditable<br>
&lt;Travis> .. agree with johanneswilm that the editor must be written to have a filter (for what can be edited)<br>
&lt;Travis> .. however, it's the current default behavior for paste!<br>
&lt;Travis> .. often we're exposing the internal of the browser... this is one more of those things.<br>
&lt;Travis> .. there is a sanitizer that we employ but we're not giving access to it. Maybe through a sanitizer API with configuration that allows it to work like the paste to contenteditable? (Could be interesting.)<br>
&lt;Travis> ... but we do something today that authors can't get today; additionally we have a web compat concern. So why not leave it?<br>
&lt;snianu> Base: https://github.com/w3c/clipboard-apis/pull/158<br>
&lt;snianu> Pickling: https://github.com/w3c/clipboard-apis/pull/162<br>
&lt;Travis> action: wait for snianu's PRs (base:  https://github.com/w3c/clipboard-apis/pull/158 pickling: https://github.com/w3c/clipboard-apis/pull/162). (It re-writes the spec with better algorithmic language. Then there's some pickling work on top of that... Would like folks in the WG to read/review the upcoming PRs.<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/clipboard-apis/issues/150#issuecomment-967297138