Request review of (text only) Async Clipboard API

[garykac]

Hello TAG!

I'm requesting a TAG review of:

• Name: Async Clipboard API (just the text APIs)
• Specification URL: https://w3c.github.io/clipboard-apis/#async-clipboard-api (just navigator.clipboard, readText() and writeText())
• Explainer: https://github.com/garykac/clipboard/blob/master/clipboard.md
• Tests: https://github.com/w3c/web-platform-tests/tree/master/clipboard-apis
• Primary contacts: garykac

Further details (optional):

• Relevant time constraints or deadlines:
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

This review is only for the text parts of the API since we are still in the process of designing the portions of the API that add clipboard support for images and delayed content generation.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[garykac]

Note: We'll have a separate TAG review for the image/delayed-gen portions once we have general agreement on the specification

[slightlyoff]

Some background: https://groups.google.com/a/chromium.org/d/msg/blink-dev/epeaao7l13M/h3FONN3RAwAJ

[chrishtr]

Hi is there any feedback on this API? I see labels for possible review in the f2f in London?

[owencm]

(also just for context, this API is currently targeting a launch in M66 which branches on March 1st, so if there are any concerns, it'd be great to hear them ASAP)

[travisleithead]

In looking through the minutes, it looks like we triaged, but didn't get a chance to discuss this :( So the short--no we don't have any feedback [yet] on this API.

[slightlyoff]

Had a few rounds of follow-up with @garykac et. al. over on blink-dev: https://groups.google.com/a/chromium.org/d/msg/blink-dev/epeaao7l13M/edF5Ho9PBgAJ

The explainer is in a much better place now, which I'm pretty happy about. I have concerns with the spec regarding image formats, introspection of available types, but those aren't being discussed to ship. We got to agreement to continue the discuss on those points here and it looks like Blink is moving forward with shipping the text-only portions.

[torgo]

My concern re: privacy considerations - the response to the self-review doesn't appear to take the privacy issues seriously enough in my view. Lots of private info can be in the clipboard and we should be very very careful before allowing access to it without explicit user consent. Arguably a permission approach does not cover it as once the permission is granted it is not visible to the user what is happening. Arguably it goes against user expectation if the webapp can gain access to the clipboard without affirmative user action (passively). Also arguably the behaviour should be different in private / incognito mode due to these privacy considerations.

[hadleybeeman]

What worries me is that we've all spent a lot energy encouraging users to use password managers, which often rely on pasting passwords in to a form. If an open tab is able to inspect the contents of my clipboard, thereby giving away the password that I've copied... this seems concerning to me. How can we mitigate that here?

[triblondon]

Attempt to consolidate TAG feedback on privacy concerns:

We are generally very concerned about the potential for passive monitoring of the clipboard contents, which could easily capture passwords. We would like to encourage implementations to be as conservative as possible in their attempts to prevent this, and wonder if mechanisms such as these have been considered:

• time limited grants for user consents
• requirement for document focus to allow access to APIs methods
• requirement for user interaction for paste API
• expiration of permission on some event, eg defocus of window, navigation away from page

[dbaron]

I'd also note that even if these things aren't normatively required, they should be discussed in the security considerations section of the spec.

[cynthia]

Ditto on @dbaron 's comment above. Extra emphasis would be to mention unfocused tab reading being disallowed, since that seems to be how it is implemented in Canary.

Another thing that we touched on during the review is that the special case API for text seems something we may regret in the future. read() ideally should be the single interface for reading out of the clipboard (believe this was brought up during the I2S), whether or not individual types read out of the clipboard should be different levels of permission is up for discussion.

Extensibility to allow arbitrary types/objects for content which can be serialized for objects to cross web application boundaries would help a lot of non-text editing application use cases. (e.g. Copy and pasting between two different tabs running web based CAD software, for one example - comes to mind.)

Personal question: The choice of DataTransfer for non-text seems a bit strange. Aside from "it was already there, and was the closest thing to what we needed" were there any compelling reasons for this choice?

[travisleithead]

I think we are looking specifically for responses on:

• User gesture requirement for Clipboard API access w3c/clipboard-apis#52 - I think we'd like to see some mention of the UA mitigation strategies enumerated by triblondon above in the Privacy/Security considerations section of the spec
• Clipboard Permission w3c/clipboard-apis#51 - Good discussion in the issue. I think we are waiting to see the request() API mentioned in the issue get added to the spec.

[torgo]

Discussed on call 5-8

[slightlyoff]

hey @garykac; seems like we keep discussing this without you. My apologies! Would you be up for joining a future call to talk through the details?

[garykac]

Sure. Next Tue at 8am works. Do you meet only on IRC or is it a conference call?

[cynthia]

Raised w3c/clipboard-apis#78 as a follow-up from May 15 telco.