Clipboard API

[mconca]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Clipboard API and Events
• Specification or proposal URL: https://w3c.github.io/clipboard-apis/

Other information

In Firefox, Mozilla currently supports the Clipboards Events described in the draft specification, so this RFP is in regards to the Asynchronous Clipboard API from the spec.

Google recently implemented and shipped the text-only API as part of the April 17, 2018, Chrome M66 release. Their reasoning behind implementing the draft spec (and limiting it to text-only for now) is documented in a March 2018 developer blog post.

Mozilla also receives many requests from extension developers to expose a better clipboard interface (the execCommand method has limitations in extensions). These API could be provided, but they would be redundant with those described in the W3C draft spec. The policy of the WebExtensions API has been to not provide proprietary extension API for features that can be accomplished via standards-based API. Knowing Mozilla's position on this draft specification, therefore, is important for planning the WebExtensions API roadmap.

[martinthomson]

The challenge here is in managing permissions. That is, how do we avoid sites capturing arbitrary text from the clipboard. Given the frequency with which secrets pass through clipboards, this is a pretty big security concern.

You will notice the permissions prompt is the very first thing that appears in the video in the Google developer blog post. I don't believe that asking permission is an appropriate defense, even though sites can only access events when they are in the foreground. Keep in mind that permissions persist and are easily forgotten.

I don't have a good solution for this.

[mystor]

I intend to have my intern implement some part of this API this summer. We're dodging the challenge which @martinthomson brought up by not exposing the clipboard reading APIs to the web (they will unconditionally fail, as though the site does not have the correct permissions), and only exposing them to webextensions which already can use the execCommand("paste") API.

This will, of course, be implemented behind a pref, and we will potentially iterate on the API before we ship it.

[martinthomson]

Use within a webextension is a great way to start. I certainly think that the concerns about permission are manageable in that context. @mystor, is the intent to have another permission for the webextension, or to implicitly grant all webextensions this capability? I think that we probably still want accountability on that front, as well as to apply the principle of least privilege. But that's product-related decisions only.

p.s., it's not access to "paste" that is the concern.

[mystor]

@martinthomson We already expose the ability to copy to webextensions in the same manner as we expose it to the web. The two permissions (clipboardWrite and clipboardRead) are also present for allowing writing/reading the clipboard whenever.

I am not intending to make any changes to that established permission model.

There are some more details on the current API here: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Interact_with_the_clipboard

[mconca]

@mystor I'm very happy to hear this. Extending the clipboard API has been a high-priority request from extension developers and glad we're going to do it in a standards-based way.

[annevk]

Related issues: w3c/clipboard-apis#101 and w3c/permissions#175.

I'm not sure what to make of this as it's clear that there are some parts that we support (and ship) and there are some parts in this specification that are clearly problematic. I guess this is a case where #249 would help.

(It's also not entirely clear how -read made it into the specification as neither Firefox nor Safari wants it.)

[marcoscaceres]

(It's also not entirely clear how -read made it into the specification as neither Firefox nor Safari wants it.)

Old WebAppsWG process had no oversight (when this was added, before I was Chair). I've introduced a pull request template to hopefully prevent this from happening again. However, it requires Mozilla folks involved in this spec to very vigilant at not allowing things like this to happen as not all working groups have such a template. We might need better enforcement (e.g., 3 reviews, one from each browser vendor, before merge).

[hober]

I've introduced a pull request template to hopefully prevent this from happening again. However, it requires Mozilla folks involved in this spec to very vigilant at not allowing things like this to happen

Please let me know how we can help.

[marcoscaceres]

@hober, the biggest help would be to have a co-Editor join from Apple. They wouldn't need to "edit" - but would be nice if they did! They would provide editorial oversight and could easily be called upon for review. That way, we share the responsibility, accountability, and pain! and, as a result, hopefully we end up with higher quality specs.

The above applies to us (Mozilla). We should be co-editing any spec we are involved in. I know it's a big investment - but something we should seriously consider.

[hsinyi]

Related issues: w3c/clipboard-apis#101 and w3c/permissions#175.

I'm not sure what to make of this as it's clear that there are some parts that we support (and ship) and there are some parts in this specification that are clearly problematic. I guess this is a case where #249 would help.

(It's also not entirely clear how -read made it into the specification as neither Firefox nor Safari wants it.)

Several issues mentioned above were closed. Worth revisiting this?
@annevk @smaug---- @mbrodesser

[annevk]

Unfortunately there's still major problems with the specification, e.g., #525 (comment) onward.

We have made some progress on how we want to expose reading, which will largely be based on Safari. Essentially require user activation followed by showing the user a non-modal dialog in context (similar to what we use for form autofill) that says something along the lines of "Paste your clipboard contents to example.com? [Paste] [Cancel]". (We don't want permissions here as that would allow continuous monitoring of clipboard contents.)

So overall this is worth prototyping I'd say, but I'm hesitant to mark it as such given the specification is essentially a skeleton.

[EdgarChen]

Spec was improved significantly by w3c/clipboard-apis#158 which defines clearer steps and adding ClipboardItem interface.

[EdgarChen]

I suggest we resolve the issue with position positive, as we are implementing it and Chrome/Safari shipped already.

[zcorpan]

Agreed. I'd like a bit more detail for rationale that answers "do we think this is good for the web?" and how it handles security concerns, independently of implemented status, though.

[EdgarChen]

Async Clipboard API could supersede accessing clipboard via execommand which is no longer recommended. The security concerns are addressed as @annevk commented earlier, i.e. it requires user activation and an additional dialog shown to get user confirmation.