Re: [w3c/editing] Should we modify the clipboard API spec to match Safari's behavior for HTML-referenced media? (#285)

If used means referenced by some element, then I don't think we've prevented any leaks.  

The paste from the default event handler would leak.  Authors that get the HTML and parse it into a document or fragment for sanitization would also leak. Sanitizers [like this one](https://github.com/jitbit/HtmlSanitizer/blob/master/HtmlSanitizer.js) will put the HTML into a connected document in a sandboxed iframe and leak.  Test pages [like this one](https://whsieh.github.io/examples/datatransfer), which just show the contents of the clipboard, will leak.

If we take "referenced by some element" off the list and just focus on having the blob URL passed into an API like fetch as our signal, then that would be reliable since we know the author is retrieving the blob and is aware of the blob URLs.  So we could say that if the blob is being fetched that it won't have its blob URLs revoked.

I'm not sure that creating clipboard / blob lifetime side effects through fetch though is a good design.  I think we'll also be limiting the author's options on the timing for handling the paste result.  I see GMail, for example, getting the HTML from the clipboard but processing it after a setTimeout.  If the fetches are delayed then the blob URLs would already be revoked.

For these reasons I think we need an opt-in mechanism to produce blob URLs.

@rniwa let me know if you think there are other ideas to explore for something that "just works" without leaking and without opt-in.


-- 
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/285#issuecomment-808114396