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

I see a few different approaches we could take to making it possible to request gestureless access. 

**Question 1: How do we represents the permission states that allow gestureless access?**

Approach 1:
**read** may require a gesture even when granted (UA-dependent)
**write** may require a gesture even when granted (UA-dependent)
**full** may require a gesture (UA-dependent)

The idea is that in Chrome, read would require a gesture when granted, but write and full would not require a gesture. The advantage here is a simpler permission descriptor. The disadvantage is that because user gesture behavior will vary across browsers, developers will have to have the specific rules per browser baked into their applications and have no good way to query this behavior at runtime.

Approach 2:
Have an extra field in the PermissionDescriptor called **requiresGesture**. The behavior of **read**, **write** and **full** depend on **requireGesture**.

The advantage here is that developers can query access to gestureless behavior at runtime. The disadvantage is a more complicated permission descriptor. Also, user gesture behavior becomes a part of the API which may or may not be desirable.

**Question 2: How do developers request gestureless access?**

Approach 1:
Have a clipboard.request() function that permits obtaining gestureless access. 

The advantage here is that it doesn't require changes to the design of the clipboard API. It also provides a clear way to request "full"/gestureless access. The main disadvantage here is that I think a request() function that does not return anything is very poor API design and has the disadvantages listed in [Permissions #83](https://github.com/w3c/permissions/issues/83). 

Approach 2: 
clipboard.write() and clipboard.read() are already planned to implicitly request permission. If clipboard.read() or clipboard.write() are called outside of a user gesture, then we could request gestureless access which may trigger a prompt. 

The advantage of this approach is that permission elevation is implicit in use of the API. The disadvantage is that it may be non-obvious to developers when prompts will be shown in different circumstances (browser variations, user-gesture variations, etc.). The other big problem is that it's still not clear how to get read and write access together - both functions would have to be called simultaneously which would be unnatural use of the API.

Approach 3:
Change the design of the clipboard API such that requestClipboard returns a handle to the clipboard instead of it hanging off navigator.

The advantage here is that requesting permission is tied to resource acquisition. It's also very clear/simple how to request "full"/gestureless access. The main disadvantage is that it would likely require substantial changes to the spec design and implementation.


@garykac @jyasskin does the above sound accurate to you? Do you see other alternatives?

This sounds very much like an API-design question in some respects and I'm wondering if TAG would be helpful? 

-- 
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-334045235