Re: [w3c/editing] Delayed clipboard rendering TAG feedback (Issue #459)

Thank you for the detailed feedback and suggestions for the privacy issue!
Some initial comments:
> This is unavoidable given our current model where a website can put whatever it pleases on the clipboard (with the only condition being that they receive an interaction of some sort)

In Chromium browsers, clipboard write permission is required to write data to the clipboard unless it's inside a copy event handler. This is a trust signal from the user that they want to give the site access to the clipboard. According to this model, if a trusted site that has access to the clipboard writes bogus/malicious content to the clipboard, then why would the user continue to use this site for copying content?

If we focus our discussion on just the malicious sites that somehow got the trust signal from the user, then our proposal is to mitigate the damage by allowing just one web custom format to be delayed rendered so the site can't cast a wider net to track user paste activity.

> The delayed rendering creates a potential bidirectional channel, with the destination choosing from a multiple choice selection. The site learns what choice is made. The choice itself carries novel private information. The timing of the paste is also revealed.

If the choice is a standard format (`text/html`, `image/png`, `text/plain`), then it doesn't leak any information about the source app where the content was copied from. The timing of paste is at best a guess as the entire process is asynchronous (both in the OS kernel and in the browser).

> Render all formats when paste occurs.

This defeats the purpose of delayed rendering as sites don't want to do the work to generate data for a format that may never be used during paste. e.g. See [Adobe's use case](https://github.com/w3c/editing/issues/417#issuecomment-1464355663).

> At copy time, produce a single format from which all others can be produced. Let the destination application perform format translation.

IIUC, this means the source apps have to produce the data for all supported formats? Again, that defeats the purpose of delayed rendering.

> Finally, we could define a new media type that carries a URL. That URL, when resolved, provides the destination application with information in whatever form it desires.

This solution sounds like something that is outside of the control of the OS system clipboard and introduces additional security concerns in platforms where there are certain expectations from the OS about how delayed rendering should work for copy-paste. For more information on delayed rendering on Windows, please see https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-operations#delayed-rendering-guidance

> The whole point of delayed rendering is to add a level of indirection. 

This is incorrect. Point of delayed rendering is to not generate data for an expensive format that is never used during paste. For more information on delayed rendering on Windows, please see https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-operations#delayed-rendering

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

Message ID: <w3c/editing/issues/459/1930668091@github.com>