Raw Clipboard Access API

[dway123]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Raw Clipboard Access API
• Specification URL: https://w3c.github.io/clipboard-apis/ (Note that this API's contents are not yet in this spec, but this spec is where it will end up)
• Explainer (containing user needs and example code)¹: https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md
• GitHub issues (if you prefer feedback filed there): https://github.com/dway123/raw-clipboard-access/issues
• Tests: TBD (directory will be https://github.com/web-platform-tests/wpt/tree/master/clipboard-apis)
• Primary contacts (and their relationship to the specification): @dway123

Further details:

• Relevant time constraints or deadlines: We'd like to discuss this at TPAC (Sept 16, 2019), so getting TAG review in early Sept before TPAC would be great, so that we can iterate before TPAC. We also plan to Origin Trial M79 Oct 17, 2019.
• 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
• The group where the work on this specification is: Editing TF

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

• Links to major pieces of multi-stakeholder review or discussion of this specification:
• Links to major unresolved issues or opposition with this specification:

You should also know that...

The previous TAG review for the Async Clipboard API, which this is built on is here.

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]

---

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

[hober]

The link provided to your privacy & security self-assessment 404s. I'd be especially interested in a privacy & security self-assessment that considers the issues raised in WICG/raw-clipboard-access#3.

[dway123]

Thank you for the prompt response, and sorry I had missed the privacy and security self-assessment.

I have uploaded the privacy and security self-assessment, and updated the link, so that it should no longer 404. It does now also consider the issues raised in WICG/raw-clipboard-access#3.

[dway123]

As an update, I took a quick look at the explainer right before review, and added a few potentially interesting API design issues. I've filed them as issues on the explainer to point them out, and would appreciate if TAG would take a look at them as well. (Discussion regarding privacy and security concerns has been continuing as well). Thanks!

[travisleithead]

FYI: Minutes just posted to Editing TF list. For Raw Clipboard, scroll down to:
12:24 AM Topic: Raw Clipboard Access
https://lists.w3.org/Archives/Public/public-editing-tf/2019Oct/0004.html

[hober]

Thanks @travisleithead!

[torgo]

We are discussing in a TAG breakout with @hadleybeeman @hober and me today. Major concerns here with the privacy and security aspects of this and possibly with async clipboard API #222 as well.

One concern we see is the following (ab)use case:

1. User copies some text (say a URL) in order to paste it into another application. That URL remains in the clipboard.
2. Later, the user returns to a tab where clipboard access permission had already been granted (user activation).
3. This text in the pasteboard (the URL) is now available to the web application running in this tab - the application harvests this data and adds it to the user profile and proceeds to spin ads to the user based on the contents of that URL.

I think we raised this and similar issues in our review of Async Clipboard (see comment from @triblondon #222 (comment)). The feedback from that review was registered in clipboard API in a few issues there that are still open:

w3c/clipboard-apis#52 User gesture requirement for Clipboard API access
w3c/clipboard-apis#51 Clipboard Permission
w3c/clipboard-apis#78 Explicitly require current focused document check in algorithm

...which seem related.

Considering that the raw clipboard access adds additional power to the clipboard API, and that these privacy and security issues remain unresolved in the clipboard API itself, it seems even more important that those issues are resolved and that the types of data leakage that I've outline above are locked down. Any comment, @dway123 or @garykac?

[hober]

The writing-native-exploit-onto-the-pasteboard concern WICG/raw-clipboard-access#3 is very serious, and engineers from multiple browser engines have stated that (1) the current approach is a non-starter due to this problem, and (2) that a pickling approach would be far more palatable. See WICG/raw-clipboard-access#3, mozilla/standards-positions#206, and the most recent TPAC minutes for examples.

In your explainer, you say (emphasis mine):

Pickling was not chosen as it does not meet the requirements desired for raw clipboard access. Namely, interoperability between native and web applications could not be assured within a reasonable time-frame through pickling.

Rephrasing, your concern with pickling is with adoption. Perhaps a more pressing adoption concern is that, without pickling, your API is unlikely to be adopted by other browser engines?

[torgo]

@dway123 @garykac any feedback on the above? We're trying to provide some input in a timely and useful fashion here but we really need your feedback on the issues raised above in order to progress this. Thanks.

[dway123]

Thank you for the feedback, and sorry we haven't responded yet. I'll provide a response next week, as we'd like some time to collect our thoughts and provide an appropriate response.

[dway123]

Thank you for the review.

Re: privacy concerns via user activation (@torgo):

Yes, we have discussed user activation requirements, and recognize that user activation could lock down that abuse case. The Chrome team has been actively investigating mentioned mitigations, including an expiring/ephemeral permission and user activation requirements, and has implemented and helped specify the document focus requirement. That said, there are several use cases (remote desktop applications and custom context menus) that would break with a user activation requirement, so we think it would be overly restrictive to require this. I’ll also place some responses in the tagged issues.

Re: security concerns and native exploits (@hober):

We’ve seen significant user and developer demand on the web for interoperability with native applications’ clipboards, and would like to provide a safe mechanism to do so. Pickling unfortunately does not meet these compatibility requirements with legacy native applications (explainer section). That said, pickling is probably worth pursuing in parallel to address separate use cases, but we currently find it to be lower priority, and the raw clipboard access API design shouldn’t preclude pickling.

Raw clipboard access opens up a similar surface as Downloads, where data may touch legacy native surfaces without sanitization. We are interested in pursuing this approach despite more difficult security implications due to expressed demand, and we should be able to secure the Clipboard in a similar way as Downloads. We are exploring the use of a clipboard mark of the web (TPAC minutes), safe browsing, and other familiar protections used in Downloads.

We’ve also filed some potential concerns as issues in the repository. Is there any feedback on those issues? Thanks!

[torgo]

Hi @dway123 I don't quite know where to go with this. Speaking for myself, I see this kind of privacy guarantee is a sine-qua-non for the web. I would never knowingly use a web browser that allowed this kind of access to my copy-paste buffer and I would certainly never want to foist this on a the general population of web users. I don't really understand how Chrome can be even considering this, considering the myriad of ways this could be (and will be) abused. I'm fairly certain the TAG consensus would be the same. I think this is a really good example of how "move fast and break things" is not a good approach for addition of new APIs to the web.

[hober]

Re: security concerns and native exploits (@hober):

Raw clipboard access opens up a similar surface as Downloads, where data may touch legacy native surfaces without sanitization. We are interested in pursuing this approach despite more difficult security implications due to expressed demand, and we should be able to secure the Clipboard in a similar way as Downloads.

I don't find this a promising rationale; consider @othermaciej's feedback on WICG/raw-clipboard-access#3:

Downloads are one of the most dangerous features of the web platform, in terms of opportunities to escape the sandbox and install persistent malware. So saying this is just like downloads is not very encouraging!

Further, many defenses around downloads are not sensibly applicable to copy/paste, or would create a serious privacy problem if implemented. For example, opening a downloaded file requires an action in native API and creates an opportunity to prompt. But merely copying malformed data in an arbitrary format can already expose the system clipboard/pasteboard surface to security vulnerabilities. A prompt before copying is both an inadequate defense ("opening this downloaded file may be dangerous" is much more understandable than "copying this data to the pasteboard may be dangerous"), and a major usability hit. Download protection via Safe Browsing is done in a way that gives a central service (run by Google) information about anything downloaded ever. We at Apple are uncomfortable with giving Google that info about every download, but every copy operation would be that much worse! Downloads are generally from an enumerable set created up front. But copy/paste data is very personal, often user created, and it would not be appropriate to update info about it (even such info as hash, length, or what web app the user was using) to a central service.

Finally, "assume that our security teams can figure out similar solutions" is not an adequate security story for a new web API that presents serious security risk. The security defenses need to be spelled out and reviewed. There are many reasons to think that copying the approach of downloads would not be an adequate solution.

[torgo]

@dway123 we discussed this topic in the last f2f with @slightlyoff in the "Fugu" discussion and it's my understanding there has been a project Fugu meeting of some kind since then. Has there been any progress since then on this topic? Our specific request (from the f2f minutes) was :

Alex: To get back to the specific request: to expand security and privacy section: expand the abuse cases, and mitigations, spelled out in a way that's understandable to someone not familiar with the API.

So, for example, can you ensure it spells out how this API could be used to gain access to the user's clipboard without their knowledge / explicit action, some of the potential ways that could be used to gain access to private information (e.g. if they have a password or other personally identifiable information in their clipboard), how the spec normatively mitigates against these outcomes and what non-normative guidance there might be around this that could additionally mitigate?

Additionally, we are looking for some progress on the "pickling" issue that @hober has described above. Is there a "middle ground" that could be struck?

[dway123]

Sorry for the late response. We’ve been in discussions with Chrome privacy/security since then, as well as with @slightlyoff.

We’ve decided that we may start with a more restrictive API surface, and later reconsider opening things up. As such, we’ll likely gate API use on user activation, via the user activation API, and are taking a deeper look at Pickling. We will send out an explainer for Pickling, either as an alternative to Raw Clipboard, or as a supplement.

Regarding abuse cases, we did mention this in our design document, which was intended as a longer, more technical (and sometimes Chromium-specific) version of the easy-to-digest explainer, but which unfortunately wasn’t linked at the top of my explainer.

I originally opted to exclude longer discussions of security and privacy from the explainer and TAG process as the TAG explainer explainer, which while very helpful, did omit a Security and Privacy section, and was clear that this document should be “brief and easy”, but after similar repeated questions, will soon release a more fleshed out security/privacy considerations document.

[hober]

@dway123 wrote:

We’ve decided that we may start with a more restrictive API surface, and later reconsider opening things up.

Great. This sounds really promising!

As such, we’ll likely gate API use on user activation, via the user activation API, and are taking a deeper look at Pickling. We will send out an explainer for Pickling, either as an alternative to Raw Clipboard, or as a supplement.

I encourage you to pursue a pickling solution first, as it's more likely to see cross-browser adoption, and then perhaps revisit raw access later.

Regarding abuse cases, we did mention this in our design document, which was intended as a longer, more technical (and sometimes Chromium-specific) version of the easy-to-digest explainer, but which unfortunately wasn’t linked at the top of my explainer.

Thanks for this; this is a really interesting document. There are documents linked from it that sound tantalizing but unfortunately aren't public, e.g. the document linked in the sentence beginning "there are concerns regarding this lack of explicit user activation".

I originally opted to exclude longer discussions of security and privacy from the explainer and TAG process as the TAG explainer explainer, which while very helpful, did omit a Security and Privacy section, and was clear that this document should be “brief and easy”,

I think that's fair. The explainer explainer does say this:

As your work progresses, the explainer can help facilitate multi-stakeholder discussion and consensus-building by making clear:[…]

• accessibility, security and privacy implications which have been considered as part of the design process.

... but it could go a lot farther, and should more strongly encourage explainer authors to elaborate on the privacy and security thoughts that have gone into the design. I've filed w3ctag/tag.w3.org#21 to track this.

[hadleybeeman]

Hi @dway123 - we are picking this up in the context of our Wellington W3CTAG F2F. We appreciate your last comment, saying that the work on the spec has been addressing the concerns we've raised before. We're hoping you can help us see where and how this is being addressed in the spec.

Specifically, it looks like the following issues on clipboard access itself are still open:

• User gesture requirement for Clipboard API access w3c/clipboard-apis#52 User gesture requirement for Clipboard API access
• Clipboard Permission w3c/clipboard-apis#51 Clipboard Permission
• Explicitly require current focused document check in algorithm w3c/clipboard-apis#78 Explicitly require

And that this issue on raw clipboard access:

• Allowing raw clipboard access is not acceptable for privacy & security WICG/raw-clipboard-access#3 Allowing raw clipboard access is not acceptable for privacy & security

...is also still open and hasn't had any recent activity.

Can you provide some more info on what's happening?

[dway123]

Hi @hadleybeeman - sorry for the lack of update, and thank you for following up.

After more internal discussion, we've decided we need to experiment with and discuss/document this API proposal more before continuing the TAG review, and suggesting changes for the specification.

Can we please close this review, and re-open via a new review when we're ready to continue? Thank you all for your time and thoughts in discussing and providing feedback on this API so far! I understand the potential for abuse has been very concerning, so this review has likely been more difficult and involved than usual.

[cynthia]

Sure thing!