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

Someone indicated that I should expand a little on option 3, so here's an attempt at that.

The whole point of delayed rendering is to add a level of indirection.  Rather than getting the content on the clipboard in a given format, you are instead given a promise for that content, or a token that you can exchange in return for that content.

We have a standard form for that on the Web, which is a URL.  The clipboard item could be provided in the form of a URL.  Applications that support this would be able to obtain content in whatever form they prefer, using fetch and HTTP content negotiation (if they are on the Web) or whatever HTTP library they prefer otherwise.

The key thing this provides is a *lack* of transparent backwards compatibility.  The destination application would need to support this new means of obtaining clipboard data.  Now, usually, that would be a drawback in the sense that you can't just continue to use Word Perfect (to use the example @hober chose) and get this delayed rendering.  But that's what provides the privacy gain.

---

A brief side note about this stuff.

What is not clear about Web clipboard APIs is that they have this wonderful covert channel in them.  A site can populate the clipboard with totally usable `text/html` or `text/plain` content, but also `sneaky/af` content.  Most applications will read and use the common format, but a malicious app can harvest the extra information in `sneaky/af` formatted clipboard content.  That could include any amount of surprising information.

You thought that you just copied and pasted a quote from a news article?  Nah, you just made a copy of your entire user profile.

The main thing stopping this from being completely terrible is that a site has very little influence over where you ultimately paste it.  So while there is a one-way communications medium here that has these wonderful covert channels, it is still largely under user control.

---

Delayed rendering creates a two-way medium.  Admittedly, the timing and format choice convey very little in the reverse direction, but it's there.

Exploiting the covert channel to carry a new overt callback provides better accountability.  It also means that the destination has to actively opt in to sending the signal.  That protects most existing applications -- and users of those applications -- by default.

That this requires an online connection to resolve is something that could be iterated on.  Obviously, same-host communication is what we really want, so it might be possible to supply alternatives that don't require a long trip to a server, as an optimization.  That is assuming that you don't want to use the server to set up a local WebRTC connection for you, which is probably more work than is justified.  That said, a server can provide content from a web page that has gone away, so there is that.

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

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