Re: [clipboard] Semi-Trusted Events Alternative

(Replying to both Ben's and Ryosuke's mails)

Ben wrote:

> Semi-trusted events in the Clipboard API spec [1] are a potential solution
> to an important problem- sites should be able to use the same infrastructure
> (clipboard events) with their own triggers (button with execCommand('paste')
> as browser initiated clipboard operations (like user presses control+v or
> uses the context menu's 'paste' option). However, I don't really know if
> 'semi-trusted' events are the solution. Users will almost certainly be using
> the keyboard or mouse with websites, so requiring an event to originate from
> keyboard or mouse doesn't seem to make them trusted at all. I know there has
> been some discussion of removing them from the spec [2]. What is the status
> of that?

The intention here would be removing it from the spec but instead referencing something equivalent in other specs, so the implemented functionality would be equivalent.

Ryosuke wrote:

> Users are going to click on somewhere in the page while browsing.  I don’t
> see how, selecting a line of text, clicking on a hyperlink, or pressing the
> down arrow key to scroll etc… could lead to indicate the user’s intention
> to expose the clipboard/pasteboard’s content to the web page.

It's not a perfect solution, but in reality this is the current state and has been for several years, for the millions of users who enable Flash. Implementors who want to give the user more obvious control over this mechanism should implement a per-site permission for reading the clipboard and add a non-obtrusive confirmation prompt that appears on a site's first attempt to do execCommand('paste'). The natural follow-up question is "if we do a per-site permission thingy, why have semi-trusted events at all?", and the answer at the moment is "for Flash feature parity" which might not be a very good reason.

Ben wrote: 
> As an alternative to semi-trusted events, perhaps we should have something
> similar to input type="file"? Perhaps a new input type that must display a
> localized word for "cut", "copy", or "paste", and must not be occluded by
> any other element, could trigger real, trusted clipboard events? I'm not
> sure how this would work, but it seems worth a discussion at least.

Authors apply a lot of weird and creative hacks to style <input type=file>. I don't think we can mandate a specific look for an element and expect authors to use it.. :-/ It's an interesting suggestion and would for example make it possible to prompt the user earlier with a "do you want to let this site read the clipboard"-type question. However, if that's our goal, we should rather aim for a more generic "request functionality" approach, something like 

navigator.desiredFunctionality('paste', 'gps', 'device camera')

or similar. But thanks for re-booting the discussion!
-Hallvord

Received on Saturday, 26 July 2014 06:12:04 UTC