Repository navigation
Clipboard APIÂ #89
Description
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.
Activity
martinthomson commentedon May 9, 2018
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 commentedon May 14, 2018
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 commentedon May 15, 2018
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 commentedon May 15, 2018
@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 commentedon May 16, 2018
@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 commentedon Jul 21, 2020
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 commentedon Jul 23, 2020
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 commentedon Jul 23, 2020
Please let me know how we can help.
marcoscaceres commentedon Jul 24, 2020
@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 commentedon Sep 29, 2021
Several issues mentioned above were closed. Worth revisiting this?
@annevk @smaug---- @mbrodesser
annevk commentedon Sep 29, 2021
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 commentedon Mar 9, 2023
Spec was improved significantly by w3c/clipboard-apis#158 which defines clearer steps and adding
ClipboardIteminterface.EdgarChen commentedon Mar 9, 2023
I suggest we resolve the issue with position
positive, as we are implementing it and Chrome/Safari shipped already.zcorpan commentedon Mar 9, 2023
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 commentedon Mar 9, 2023
Async Clipboard API could supersede accessing clipboard via
execommandwhich 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.Clipboard API (positive)
Clipboard API (positive) (#764)
[-]RFP: Clipboard API[/-][+]Clipboard API[/+]