Re: [w3c/clipboard-apis] Clipboard Permission (#51)

There seem to be several things that these permissions are intended to govern.  But I don't see any motivation for any of those things.  

It's not clear to me whether the last item is being considered here or not, but this seems to be entirely predicated on the assumption that the asynchronous API is useful.  But I couldn't find any motivation for that API at all.  Can someone provide some justification for providing access to:

* the clipboardchange event - learning when the clipboard changes in other tabs or applications
* access to reading or writing the clipboard without a user gesture (if I understand correctly, it is possible to write with just a click or keypress, but reading might require the user pressing the "paste" system hotkey)

It also seems like reading or writing media types other than those listed as being safe is also being considered here, that should be made clearer.

It seems to me that all of the above can be managed in different ways.  Some by doing nothing, which is generally the best plan if at all possible.

I note that there is no restriction on use of the clipboard by sites that don't have input focus.  I don't think that sites should be able to read or write unless they have focus.  Just as they don't receive keyboard and other input events.   This suggests that a blanket permission, and a simple "site has permission to read" - as implied by this thread - isn't the only prerequisite for access.

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