Re: [clipboard] Semi-Trusted Events Alternative

[Responding to several messages about pasting data from same origin here]

----- Original Message -----
From: "Jonas Sicking" <jonas@sicking.cc>

>> * paste: we allow reading clipboard contents if the paste event is not
>> synthetic and not triggered from a document.execCommand('paste') call

> I think we should also allow reading data that was copied from the
> same origin. That way a website can build an editor which has full
> copy/paste capabilities as long as you are only editing within that
> website.

It's an interesting idea that partly fixes the main drawback with the current proposal: that to read clipboard contents, "paste" must be triggered from the browser's own UI, not the website's. The current proposal makes it possible for a website to create a "Copy" button it its UI, and it will just work when clicked, but to create an equivalent "Paste" button the site must be white-listed and allowed to read all clipboard content.

However, this suggestion does add yet some more complexity...

----
From: "Dale Harvey" <dale@arandomurl.com>

> websites can already trivially build editors that use copy and paste within
> the site itself

Indeed, I've seen pretty high profile online editors with a "cloud clipboard"-labelled feature. However, I don't think this is user friendly or understandable eventually. If you copy something from the app to the "cloud clipboard", then copy something from your desktop word processor to the system clipboard, then try to paste - what do you expect to paste? Most users would expect the content from the word processor. The clipboard works precisely because it is ONE global place for exchanging all sorts of content. AFAIK, the experimental "cloud clipboard" disappeared again from the app that was using it (though I don't remember where I saw this, and I may be wrong about it being removed again).

----
From: "Jonas Sicking" <jonas@sicking.cc>

> I'm not sure I fully follow your argument. So let me provide two
> options that I think we have.
> 
> 1. Forbid any attempts at reading directly from the clipboard, no
> matter if the data there came from the current origin or not. Thereby
> keeping the API consistent.

The spec and reality is currently a bit more liberal than that :) - we give any script access to data regardless of origins when it's pasted from the browser's trusted UI (Ctrl-v, "Edit > Paste", Right-click > Paste et al). The only question is whether and how we can safely enable sites creating their own paste UI, allowing said UI to trigger paste with document.execCommand().

> 2. Allow reading data from the clipboard at any time if the data there
> originated from the current origin. Thereby making the API as helpful
> as possible for the case when data is copied within a website.

So, I'm not yet "sold" on this suggestion. As I said already it's interesting - but it adds complexity to security/privacy-sensitive programming logic, and it might add layers of confusion for users. "The paste button worked fine a moment ago, why doesn't it work now??". "Copying from tab A worked fine and I could paste, copying from tab B fails??". 

I believe the simple yes/no choice of a trust/grant privileges UI is easier to understand, and if you're going to type in/edit text on a website in the first place chances are that it's a site you trust. So my gut feeling is that the complexity/usability cost is too high for what this extra rule would buy us. I'm still open to arguments though - perhaps especially if list members can come up with sites that have editors with cut/paste UI, sites where members of this list would want to allow the paste UI to work for reading same-origin content off the OS clipboard, but would NOT want to trust the site with full read access to their clipboards - and where lots of people might feel the same way..

-Hallvord

Received on Monday, 15 September 2014 20:42:39 UTC