User gesture requirement for Clipboard API access

[garykac]

We need to document how we want to handle the (current) User Gesture requirement once we have proper Permissions in place.

User gestures were put in place to help reduce drive-by API abuse since we didn't have a Permission mechanism in place. Now that we have Permissions, we could remove the gesture requirement, but some UAs may want to keep the gesture requirement so that they can auto-grant some access to the clipboard without requiring a Permission prompt.

If we want to include this explicitly in the spec, here is an initial proposal:

• Write: Gesture required for clipboard write UNLESS fullAccess Permission has already been granted
  • This is because the fullAccess permission is stronger than the basic permission
  • If basic { clipboard } permission is DENIED, then write will not work (even with a gesture)
• Read: Since clipboard read is more dangerous, require { clipboard fullAccess=true } Permission
  • Note: built-in (UA or OS-level) "paste" buttons may only require a user-gesture

[garykac]

A first attempt at including gesture requirements and permissions is at:
https://w3c.github.io/clipboard-apis/#clipboard-permissions

[gked]

@garykac in 9.1.1, what is the purpose of having to query the user for full access to the clipboard? Isn't the fact that systemPaste is set to true indicates that full access was meant to be granted?

[garykac]

"full" is granting full read/write access to the clipboard without a gesture.
"read" and "write" access require a gesture.

This means that "full" is a bit more than simply "read" + "write"

[garykac]

I've update the spec to include an explicit requireGesture param for the Permission and included an example of how a UA could use to this to provide a single "full" access permission.

[travisleithead]

I'm wondering why this has to be based on a generic user gesture... yes, you want to prevent drive-by clipboard access, but the platform already has a semantic-event that fires when the user is actually requesting the clipboard contents be copied and/or pasted: the copy and paste events! These seem like the ideal "user gesture", and it would be fairly straightforward to limit use of the clipboard API only to the time that these events are being dispatched. (If there is too much baggage attached to these legacy events, then mint new ones for clipboard access--I'll use those in the example.)

The UA would have code like this (Javascript for clarity):

let clipboardWriteAccess = false;
function implementationOfClipboardWrite( data ) {
   if (!clipboardWriteAccess) {
      return Promise.reject("reason");
   }
   // Take the data and put it on the clipboard.
}
function onUACopyMenuOrKeyboardShortcutActivated() {
   clipboardWriteAccess = true; // during this window, the clipboard.write* APIs will work...
   navigator.clipboard.dispatchEvent( new Event("copyrequest") );
   clipboardWriteAccess = false;
}

Similar code could protect clipboard reads.

[travisleithead]

Related to our review: w3ctag/design-reviews#222

[travisleithead]

#52 (comment) this prevents web UI from initiating a copy/paste, which might be a deal-breaker...

[garykac]

For implementations that want to gate this API on a user gesture, then that feels too restrictive to me (since, as you note, it will prevent custom UI for the clipboard operations).

Note that the existing clipboard event API already allows you to override the clipboard operation to the clipboard (see https://w3c.github.io/clipboard-apis/#clipboard-event-api). If people can only access the Write API inside the "copy" event (and Read from within Paste), then that's effectively the same restriction as the current API.

So that sounds like it might be OK, as long as there is still a way to request gesture-less access (which is needed for a number of other use cases)

However, note that Chrome's implementation does not rely on user gestures: Write access is always granted and Read access is protected by a User Permission.

Because of this, I think we should try to get feedback from UAs that intend to use the user gesture requirement to see how they feel about it.

[dway123]

As mentioned here, gating this API on a strict 'copy'/'paste' event may be too restrictive, as it would prevent custom UI for clipboard operations. That said, it's possible that newer User Interaction libraries may fix this, by allowing a 'click' event to be considered as User Interaction (this of course welcomes questions regarding checking the clipboard on every click, and may not be practically useful).

In addition, it has been voiced that remote desktop applications may have difficulty using this API given a user gesture requirement. This is explored in significantly more detail here.

In the last message on this thread, garykac mentioned that this conversation may benefit from some feedback from UAs that intend to use the user gesture requirement. Have any UAs that would prefer this requirement investigated this?

[dway123]

Sorry, I forgot to add folks from other UAs to provide feedback. @whsieh , @smaug---- - are you aware of Webkit or Gecko's stance on adding a user interaction requirement for the Clipboard API? I'm aware that Webkit recently implemented this API, but unsure how it was implemented with respect to user interaction.

Chrome would like to eventually have this requirement, with a caveat that remote desktop applications will require first implementing a 'clipboardchange' event in order to continue to sync the clipboard. Changing existing behavior may also of course be web incompatible, but this is likely worth the privacy concern of sites potentially being able to snoop on the clipboard without this restriction.

[whsieh]

Adding @rniwa

I think we’d support adding a user interaction requirement for clipboard access, for both writing and (especially) reading.

Our current implementation limits clipboard write to user interaction only, and limits clipboard reading to user interaction and, in addition, interaction with trusted native UI for pasting content (i.e. a popup on macOS or callout menu action on iOS).

We did (very briefly) consider not requiring user interaction for clipboard reads when the content was written by a page with the same security origin, but we decided not to because this would still indirectly leak information to the page, since they’d be able to determine exactly when the user has copied content that is cross-origin, or from a different app altogether.

[smaug----]

I agree with @whsieh and webkit's restrictions sound reasonable.

[domenic]

The current spec has "allowed to show a popup", which apparently was the old term for user activation. It would be ideal if this were updated, to consult transient activation and/or to consume user activation.

[torgo]

Hi folks! As discussed on today's TAG call - we think the user activation requirement needs to be very strong - e.g. ^v or selecting paste in a menu. As I wrote in this comment on our issue on the pickling review, we think there are some abuse scenarios that are not being given enough weight in the discussion here. It should not be possible for a web page to have access to the contents of a user's clipboard without a very high bar of informed consent. This is pretty fundamental to what sets the web apart from other platforms in terms of user safety. Since this issue is still open, what can be done additionally to strengthen the spec (and implementations) in this area?

[lapcat]

Hi folks! As discussed on today's TAG call - we think the user activation requirement needs to be very strong - e.g. ^v or selecting paste in a menu. As I wrote in this comment on our issue on the pickling review, we think there are some abuse scenarios that are not being given enough weight in the discussion here. It should not be possible for a web page to have access to the contents of a user's clipboard without a very high bar of informed consent. This is pretty fundamental to what sets the web apart from other platforms in terms of user safety. Since this issue is still open, what can be done additionally to strengthen the spec (and implementations) in this area?

I've created a demo and explainer showing how any web page in any web browser can silently overwrite the system clipboard using many innocent user gestures such as pressing the arrow key to scroll down the web page.

In my testing, these DOM events can activate the Clipboard API: click, copy, cut, focusout, keydown, keyup, mousedown, mouseup, selectstart

User gestures are not user consent. There can be no consent without understanding, and users definitely don't understand that these gestures allow their clipboard to be overwritten.

There is some concern that strictly limiting the Clipboard API would make custom UI impossible. Well... maybe it should be impossible. Or maybe there should be an explicit user site permission that makes it possible. In any case, I can imagine some stricter limits than what current exists, such as only allowing a click event on a <button> element to activate it.

If you look at one prominent implementation of custom UI, there's Twitter's "Copy link to Tweet". Twitter uses this custom UI to add tracking tags to the end of the tweet URL, which users all hate, and which causes unrelated "More Tweets" to appear when a user loads the tweet. So I can't say that this custom UI is very user friendly. I think these discussions tend to revolve too much around what web developers want and not about what web users want.