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

I'm working to setting on a set of Permissions for the Clipboard API. Currently, we have a placeholder in the [Permissions API](https://w3c.github.io/permissions/#clipboard):

### Current Proposal

Because the Permissions tend to be hierarchical (with a generic top-level permission and flags for special access - see Permissions for Midi), we were settling on:

> { name: "clipboard" }   <- for basic Write access
> { name: "clipboard", allowRead: true }  <- for both read/write access

Since read access is more of a privacy risk than write (eg: reading passwords and PII from clipboard).

Each of these permission descriptors is set to either GRANTED, DENIED or PROMPT. So, a user agent could (for example) decide to have the following defaults:

> { name: "clipboard" }  = GRANTED
> { name: "clipboard", allowRead: true }  = PROMPT

And the "allowRead=true" version is known to be "stronger" than the "allowRead=false" version so the user would not be queried if a "strong" permission was already granted.

### Mozilla Permissions

Mozilla's clipboard permissions are basically:
- clipboardWrite
- clipboardRead

Which makes sense as 2 independent bools, but doesn't really fit in to the basic-access/specific-access model common in Permissions.

But the Proposed Permission model described above doesn't map cleanly to Mozilla's current permissions since there is no way to grant Read access but deny Write access.

### What if we had separate flags for read and write?

An alternate way of doing Permission (that we originally considered) is to instead have:

> { name: "clipboard", write: true/false, read: true/false }

This more closely matches with Mozilla has but that allows weird combinations like:

> { name: "clipboard", write: false, read: false } = GRANTED

What would this even mean? And how would it be different from having the other permissions set to DENIED?

And the "strength" relationship between the permissions in this scenario is less obvious:

> write:true, read:true > write:false, read:false
> write:true, read:true > write:true, read:false
> write:true, read:true > write:false, read:true
> but...
> write:false, read:true ??? write:true, read:false
> write:true, read:false ??? write:false, read:true

which means we might end up asking for permission more often (eg: asking the user for write access, then asking for read).

These oddities were why we went with the Proposal mentioned earlier.

My question is: Does the original Proposal work for Mozilla?  How important is being able to grant read, but not write access?
@masayuki-nakano @smaug----


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