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

----- Original Message -----
From: "Jonas Sicking" <jo...@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" <d...@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" <jo...@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

Reply via email to