- From: CSS Meeting Bot <notifications@github.com>
- Date: Fri, 08 Oct 2021 10:13:25 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/334/938890189@github.com>
The Web Editing Working Group just discussed `Continue discussion on clipboard APIs`. <details><summary>The full IRC log of that discussion</summary> <Travis> Topic: Continue discussion on clipboard APIs<br> <Travis> github: https://github.com/w3c/clipboard-apis/issues/150<br> <Travis> BoCupp: Not sure this is the right issue...<br> <BoCupp> https://github.com/w3c/editing/issues/334<br> <Travis> .. Ah, in a different repo: https://github.com/w3c/editing/issues/334<br> <Travis> github: https://github.com/w3c/editing/issues/334<br> <Travis> BoCupp: we were able to resolve half the discussion. Agreed to add a non-normative note on the format that is used to communicate with native apps (and vice-versa)<br> <Travis> .. from native->web: current read behavior of nav.clipboard, you get sanitized content.<br> <Travis> .. for exchange with office apps (or similar) the fidelity is too low (loss of formatting, for example)<br> <Travis> .. so we want to add an "unsanitized" option to the read API.<br> <Travis> .. (trying to match ctrl+v)<br> <whsieh> q+<br> <Travis> .. we want raw content from the pickle jar (if exist) or from well-known HTML format.<br> <Travis> .. if you get that raw data, then native->web works great even for apps not yet updated.<br> <Travis> .. (also want to talk about web->native)<br> <Travis> .. when writing, there is also sanitization happening today.<br> <Travis> .. if we can't support well-known HTML format write, then our partners won't be able to support the API because it cuts off existing support already provided by the setData legacy API.<br> <Travis> .. today in all browser setData is a raw-write for HTML to clipboard. If they lose that in async clipboard it blocks them.<br> <Travis> .. (it's a downgrade for existing apps already having migrated to async clipboard)<br> <Travis> ack whsieh<br> <Travis> whsieh: As discussed there are a few privacy/security issues at play (not fully address from last time)<br> <Travis> .. in webkit the getData/setData, for these webkit treated as a security fix--was surprising to hear this was only limited to one of them.<br> <Travis> .. on copy/paste of content to native apps, they can reach into the pickle jar. So this can already work without a sanitized write.<br> <Travis> .. Without any explicit Api changes<br> <Travis> .. there are privacy issues native->web copy/paste.<br> <BoCupp> q?<br> <Travis> .. e.g., Word does add some things (like filepaths) into the clipboard and could expose directory structure to the web, and would be a non-starter for unsanitized read.<br> <Travis> BoCupp: Problem: some existing native apps would take a long time to update (they only read from the well-known format today). They can't simultaneously use the new API (when avaiable) and the old one. (They have to pick one.)<br> <Travis> .. This then creates a blocker until apps updated to read from new pickle jar.<br> <GameMake_> q+<br> <Travis> whsieh: So native app side, they would try to read from pickle jar?<br> <Travis> BoCupp: an existing app--doesn't know about the pickle jar yet.<br> <Travis> .. today they read and get full fidelity.<br> <Travis> whsieh: problem is... web pages adopt new API, old version of native apps would get ?<br> <Travis> .. they can't use both setData AND nav.clipboard.write (it's one or the other)?<br> <Travis> johanneswilm: What would happen in that case?<br> <Travis> BoCupp: Maybe last write wins? But code is not written to handle that (one overwrites anything else).<br> <Travis> .. the writes are basically atomic for a write (and the results that get generated)<br> <Travis> .. might be able to specify how they work together?<br> <Travis> .. but want to have unsanitized write using the new API.<br> <Travis> ack GameMake_<br> <Travis> GameMake_: I understand that new version is not backward compatible... how is this new version back compatible?<br> <Travis> .. so how does old version of Word work?<br> <Travis> .. Given a new API (unsanitized write).. How does the old version of word get this today?<br> <Travis> BoCupp: Word is coded to read a well-known HTML format. WebApps fills this format today with whatever they want (and it goes through unsanitized).<br> <Travis> .. using setData API.<br> <Travis> .. on async write, we started sanitizing content and putting it into the same "slot" that Word reads from.<br> <whsieh> q+<br> <Travis> .. am proposing that the write on async clipboard fill the same slot in the same way.<br> <Travis> GameMake_: So, when on web, when using new API with unsanitized version, then only the unsanitized version is being written?<br> <Travis> .. thinking that sanitization was to improve security. So, how does this not become a problem.<br> <whsieh> q-<br> <Travis> BoCupp: threat was for arbitrary (new) formats (never accessible from the web) before. And Apps wouldn't be prepared and would be vulnerable to this. (The web being able to write to those format names.)<br> <Travis> .. Those were the threats we were concerned about.<br> <Travis> .. I don't think apps (like Word) aren't aware of the risk, as they are already using the HTML format.<br> <whsieh> q+<br> <Travis> .. I think native apps, getting HTML should be ready.<br> <Travis> GameMake_: So the new sanitized format flag only work for well-known formats?<br> <Travis> BoCupp: the behavior of write not only allows arbitrary mime-types to be written (sanitized), pre-existing well-known types to flow through in the way they did in the past.<br> <Travis> .. am primarily focused on HTML format write now. (But may want to expand to other well-known, existing types.)<br> <Travis> .. For read, there must be an explicit option to "give me raw".<br> <Travis> .. (restating) we built a new API, but customers won't move to it (because it's a loss of functionality available today).<br> <Travis> GameMake_: Didn't know why we chose to open the whole...<br> <Travis> s/whole/hole<br> <Travis> BoCupp: Agree that we did too much (sanitizing on write for well-known)<br> <Travis> GameMake_: Not sure I see the complete problem<br> <Travis> .. if we were solving for a problem, we can't just ignore that problem...<br> <johanneswilm> +q<br> <Travis> .. but if we bringing this back to a prior state, I could be more supportive.<br> <whsieh> q-<br> <Travis> BoCupp: In the security process, we fix/patch the holes. They've supposedly been addressed in the past (or continue to be so).<br> <Travis> .. when the async clipboard write was proposed in the prior group (with garykac's proposal), I opposed the change.<br> <Travis> .. was there a real threat, we would have tried to solve that. But the change wasn't based on a threat, it was just a suggestion.<br> <Travis> .. If there was a motivation for the change, I'd really like to know what it was.<br> <whsieh> q+ to: mention that we really can't expect all native apps to sanitize `script` tags, for instance<br> <Travis> GameMake_: I definitely want to know what the reason was.<br> <Travis> q?<br> <Travis> ack johanneswilm<br> <Travis> johanneswilm: If Safari was the only one that removed it, then maybe they can tell us what the issue was?<br> <Travis> whsieh: Don't know of a specific native app that might have been taken by the exploit.<br> <Travis> .. Just don't want to expect all native apps (moving forward) to be able to do the sanitization steps.<br> <Travis> .. It's hard to get that right.<br> <BoCupp> why would native Word need to worry about stripping onmouseover events?<br> <BoCupp> that's a web app concern<br> <Travis> .. the Browser is in the middle, and should be responsible for sanitizing.<br> <Travis> .. is also at odds with the compatibility story.<br> <BoCupp> q?<br> <Travis> whsieh: to BoCupp, maybe not native word, but perhaps an electron app?<br> <Travis> .. there are some corner cases we wouldn't expect them to catch.<br> <Travis> BoCupp: For electron, they have access to sanitization on read (default) (if they are web-based).<br> <Travis> whsieh: this requires them to use the web API...but they aren't limited to that given they are native?<br> <Travis> .. my understand would be the only way to access the data would be through opt-in unsanitized read.<br> <Travis> BoCupp: special meeting to continue this discussion?<br> <Travis> .. given we're out of time<br> <Travis> johanneswilm: I propose we meet again on the 15th.<br> <Travis> BoCupp: Sounds fine.<br> <Travis> .. I do want to make progress... if we're running in circles I don't want to waste folks time.<br> <Travis> action: add a special meeting on October 15th (same time/place)<br> <Travis> travis: will just cover this topic on the 15th.<br> <Travis> whsieh: I'm sure we can come to some consensus ;-)<br> <Travis> Thanks everyone! I think we covered a lot of ground today.<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-938890189
Received on Friday, 8 October 2021 17:13:39 UTC