Re: [w3c/editing] [Delayed Clipboard Rendering] Privacy issue while reading data for web custom types (Issue #439)

The Web Editing Working Group just discussed `[Delayed Clipboard Rendering] Privacy issue while reading data for web custom types`, and agreed to the following:

* `RESOLVED: Privacy concern doesn't exist if we only support built-in formats. We'll do builtins first and then custom formats in the future.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dandclark> topic: [Delayed Clipboard Rendering] Privacy issue while reading data for web custom types<br>
&lt;dandclark> github: https://github.com/w3c/editing/issues/439<br>
&lt;dandclark> snianu: TAG had feedback on this, had same privacy concern. Proposed mitigations that don't work. I responded in thread.<br>
&lt;dandclark> ...: At this point, issue has been dragging for too long. Privacy issue is from web custom format. Can we do this just for builtin formats?<br>
&lt;dandclark> ...: Can standardize all the infrastructure for this separately without web custom formats, privacy issue doesn't have to block that.<br>
&lt;dandclark> ...: Can we separate the two things? Make web custom formats as separate proposal, move forward with that separately if we find some mitigation.<br>
&lt;dandclark> ...: But that wouldn't require API changes to async clipboard API.<br>
&lt;dandclark> ...: Proposal is standardize for builtin formats. Secondary proposal to restrict custom formats to just 1. But if that's controversial let's resolve to just support builtin formats for delayed clipboard rendering.<br>
&lt;dandclark> smaug: Concern is if we do it only for builtins, and then want to do it later for custom formats, what if API shape needs to be different.<br>
&lt;dandclark> smaug: Could be confusing.<br>
&lt;dandclark> snianu: With the builtin formats, only change is to add callback instead of Blob.<br>
&lt;dandclark> ...: If we dont' have calbacks for web custom formats, if we find some other way for devs to do that it would be some other API. To support web custom format we could add overloaded constructor. It's easily extendable. Don't have to change entire API surface.<br>
&lt;dandclark> smaug: If there's something that can support both use cases, hopefully we can build something forward-compatible.<br>
&lt;dandclark> snianu: Only thing that changes is the callback.<br>
&lt;dandclark> snianu: Say we add more security restrictions, that doesn't need a web API change. If you use web custom format  you are subject to these restructions, if not it just works.<br>
&lt;dandclark> snianu: Builtin formats add real value.<br>
&lt;dandclark> ...: And we're adding more.<br>
&lt;dandclark> whsieh: Hard to imagine case where having callback wouldn't be backwards-compatible.<br>
&lt;dandclark> whsieh: Provides value in short term.<br>
&lt;dandclark> smaug: Maybe.<br>
&lt;dandclark> whsieh: Even then, callback could return object we add.<br>
&lt;dandclark> smaug: Would be nice to see concrete proposal. E.g. I'd like to see using streams to write the data.<br>
&lt;dandclark> snianu: Looking into streams doesn't have to block the current API.<br>
&lt;dandclark> snianu: Proposal is the same, just don't allow custom formats.<br>
&lt;dandclark> smaug: Callbacks were resolved, but what they actually do was not resolved.<br>
&lt;dandclark> ...: Producing data as blob requires lots of memory, streams could solve that.<br>
&lt;dandclark> snianu: Could extend it to support streams in callback.<br>
&lt;dandclark> snianu: Could also talk to partners about this.<br>
&lt;dandclark> snianu: Some are interested in that. COuld do it separetely , doesn't have to block this.<br>
&lt;dandclark> smaug: That's fine. Let's get issue filed.<br>
&lt;dandclark> snianu: I'll file issue and link it.<br>
&lt;dandclark> RESOLVED: Privacy concern doesn't exist if we only support built-in formats. We'll do builtins first and then custom formats in the future.<br>
&lt;snianu> https://github.com/w3c/clipboard-apis/issues/191<br>
&lt;dandclark> s/and then custom formats in the future./and then consider custom formats in the future.<br>
</details>


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

Message ID: <w3c/editing/issues/439/1934719705@github.com>