Intent to Implement: Raw Clipboard Access

[Darwin Huang]

Contact emails

huang...@chromium.org, pwn...@chromium.org 

Explainer

https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md

Design Doc

https://tinyurl.com/raw-clipboard-access-design

Spec

https://w3c.github.io/clipboard-apis/ (not yet updated to include Raw Clipboard Access)

TAG Review

https://github.com/w3ctag/design-reviews/issues/406

Summary

Powerful web applications would like to exchange data with native applications via the OS clipboard (copy-paste). The existing Web Platform has a high-level API that supports the most popular standardized data types (text, image, rich text) across all platforms. However, this API does not scale to the long tail of specialized formats. In particular, non-web-standard formats like TIFF (a large image format), and proprietary formats like .docx (a document format), are not supported by the current Web Platform.

Raw Clipboard Access aims to provide a low-level API solution to this problem, by implementing copying and pasting of data with any arbitrary Clipboard type, without encoding and decoding.

This could be used by:

• Online editors like Google Docs or Microsoft Office 365, copy/paste OpenOffice or Microsoft Word documents/spreadsheets/presentations (proprietary formats).

• Figma or Photopea, to copy/paste PhotoShop/GIMP, GIFs, or RAW images, or already-supported formats with not-supported metadata (long tail of metadata).

• Web Apps supporting “niche” types, like LaTeX, .ogg, etc (long tail of formats).

The existing Async Clipboard API’s re-encoding is still encouraged for use cases requiring only generic types, and easier to use as custom encoders/decoders would not be necessary, but raw clipboard access allows web applications with more specific or sophisticated clipboard support needs to meet those needs.

Motivation

Without Raw Clipboard Access:

• Google Docs requires an extension in order to copy and paste content interoperable with Microsoft Office.

• Some native applications may reverse-engineer Webkit and Blink’s pickling/custom clipboard formats (ex. "org.chromium.web-custom-data") to interoperate with the web, without requiring any permissions protections.

• Web applications are generally limited to a small subset of formats, and are unable to interoperate with the long tail of formats. For example, Figma and Photopea are unable to interoperate with most image formats.

Risks

Interoperability and Compatibility

This feature is built on top of the Async Clipboard API. There is interoperability risk if no other browsers decode to implement.

Edge: No Signals.

Firefox: Negative Signals.

Safari: Negative Signals.

Web / Framework developers: Positive Signals (Figma, Photopea, and SketchUp).

Ergonomics

This feature will be used in tandem with the Blob API. As this API is fairly asynchronous and performant, and is capable of running on a background thread, this should not negatively impact performance.

Activation

This library is more complex to use, as a relatively low-level API. That said, this is intended for web applications with more complex needs, or through indirect use (via a library), so this complexity is necessary to allow low-level access.

Debuggability

Dedicated debugging support on DevTools is not required for this change.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5682768497344512

Requesting approval to ship?

No

[Jeffrey Yasskin]

I haven't fully reviewed the spec, but wanted to point out a few potential problems that I did notice:

https://github.com/dway123/raw-clipboard-access/blob/master/security-privacy.md#2171-how-might-this-specification-compromise-a-users-system-issue says, "Exposing raw clipboard content to the open web platform poses serious security issues, in that this introduces a large surface of unsanitized content, previously not available to the open web. ... A permission prompt is in place for writes to ensure that the user takes care when allowing raw clipboard access."

A permission prompt doesn't seem like enough warning that a malicious or exploited website could get native execution by attacking a local application. (Unless, I suppose, it explicitly asks for permission to run native code, in which case users aren't likely to grant it.)

https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md#minimal-implementation-for-user-agents says that websites can only feature-detect this if the UAs that don't support it reject calls with {raw : true}. I think we usually want a way to feature-detect new features even if other UAs don't implement anything about them.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdfe0147-2f09-4dcf-88a0-e49ea8e962ad%40chromium.org.

[Darwin Huang]

Thank you for the quick response.

On Mon, Oct 7, 2019 at 2:34 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

I haven't fully reviewed the spec, but wanted to point out a few potential problems that I did notice:

https://github.com/dway123/raw-clipboard-access/blob/master/security-privacy.md#2171-how-might-this-specification-compromise-a-users-system-issue says, "Exposing raw clipboard content to the open web platform poses serious security issues, in that this introduces a large surface of unsanitized content, previously not available to the open web. ... A permission prompt is in place for writes to ensure that the user takes care when allowing raw clipboard access."

A permission prompt doesn't seem like enough warning that a malicious or exploited website could get native execution by attacking a local application. (Unless, I suppose, it explicitly asks for permission to run native code, in which case users aren't likely to grant it.)

In addition to a permission prompt, there are also the same guarantees that the async clipboard API is afforded to avoid abuse (secure context, active frame, as well as an asynchronous API that allows room to inject Safe Browsing checks, just like the Downloads and Native File System APIs have.

https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md#minimal-implementation-for-user-agents says that websites can only feature-detect this if the UAs that don't support it reject calls with {raw : true}. I think we usually want a way to feature-detect new features even if other UAs don't implement anything about them.

Sorry, I think that the explainer's wording wasn't too accurate. Feature detection could be accomplished by checking the `ClipboardItem` prototype for the `raw` property (which presumably would be `undefined` if not implemented, and `true`/`false` if implemented). The minimal implementation was more intended for Webkit as a more palatable fallback as they're not interested in implementing raw clipboard access. I've updated the section accordingly.

--

- Darwin Huang

[Jeffrey Yasskin]

On Mon, Oct 7, 2019 at 6:35 PM Darwin Huang <huang...@chromium.org> wrote:

Thank you for the quick response.

On Mon, Oct 7, 2019 at 2:34 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

I haven't fully reviewed the spec, but wanted to point out a few potential problems that I did notice:

https://github.com/dway123/raw-clipboard-access/blob/master/security-privacy.md#2171-how-might-this-specification-compromise-a-users-system-issue says, "Exposing raw clipboard content to the open web platform poses serious security issues, in that this introduces a large surface of unsanitized content, previously not available to the open web. ... A permission prompt is in place for writes to ensure that the user takes care when allowing raw clipboard access."

A permission prompt doesn't seem like enough warning that a malicious or exploited website could get native execution by attacking a local application. (Unless, I suppose, it explicitly asks for permission to run native code, in which case users aren't likely to grant it.)

In addition to a permission prompt, there are also the same guarantees that the async clipboard API is afforded to avoid abuse (secure context, active frame, as well as an asynchronous API that allows room to inject Safe Browsing checks, just like the Downloads and Native File System APIs have.

The first two aren't really defenses, but Safe Browsing might be. I want to confirm that you've talked to the Safe Browsing team, and they have a concrete plan to block raw clipboard data that damages any semi-popular app on both Android and iOS (so that Safari could possibly change their minds), without sending clipboard data to a server?

Also, to be clear, none of this worry applies to raw clipboard *reads*. That has different enough security and privacy implications that you might consider doing read and write as different Intents.

I do agree with Ryosuke's worry there that some apps put dumb metadata in the clipboard that exposes more than the user could see, but I'm reasonably happy calling that an application bug, especially if you can write custom checks to block the leak (or the whole leaky format) for the most common applications.

 

https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md#minimal-implementation-for-user-agents says that websites can only feature-detect this if the UAs that don't support it reject calls with {raw : true}. I think we usually want a way to feature-detect new features even if other UAs don't implement anything about them.

Sorry, I think that the explainer's wording wasn't too accurate. Feature detection could be accomplished by checking the `ClipboardItem` prototype for the `raw` property (which presumably would be `undefined` if not implemented, and `true`/`false` if implemented). The minimal implementation was more intended for Webkit as a more palatable fallback as they're not interested in implementing raw clipboard access. I've updated the section accordingly.

Great, thanks. The new bit about "rejecting …, and instead fall back" seems inconsistent. If it rejects the Promise it hasn't fallen back, and contrapositively. But that's just a wording mistake or a Jeffrey-misunderstanding and not a real problem with the API.

Jeffrey

[Boris Zbarsky]

On 10/7/19 5:16 PM, Darwin Huang wrote:
> Firefox: Negative Signals.

In particular, per
https://github.com/mozilla/standards-positions/issues/206 it's looking
like Mozilla's position on this is that the overall approach is not the
right one from a security perspective. See
https://github.com/mozilla/standards-positions/issues/206#issuecomment-539435685
for a brief description of an alternate proposal that achieved similar
goals while having better security properties.

Does that proposal achieve the goals of this API? Or is there not
enough information in that comment to answer that question?

-Boris

[David Benjamin]

On Tue, Oct 8, 2019 at 12:31 AM Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Mon, Oct 7, 2019 at 6:35 PM Darwin Huang <huang...@chromium.org> wrote:

Thank you for the quick response.

On Mon, Oct 7, 2019 at 2:34 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

I haven't fully reviewed the spec, but wanted to point out a few potential problems that I did notice:

https://github.com/dway123/raw-clipboard-access/blob/master/security-privacy.md#2171-how-might-this-specification-compromise-a-users-system-issue says, "Exposing raw clipboard content to the open web platform poses serious security issues, in that this introduces a large surface of unsanitized content, previously not available to the open web. ... A permission prompt is in place for writes to ensure that the user takes care when allowing raw clipboard access."

A permission prompt doesn't seem like enough warning that a malicious or exploited website could get native execution by attacking a local application. (Unless, I suppose, it explicitly asks for permission to run native code, in which case users aren't likely to grant it.)

In addition to a permission prompt, there are also the same guarantees that the async clipboard API is afforded to avoid abuse (secure context, active frame, as well as an asynchronous API that allows room to inject Safe Browsing checks, just like the Downloads and Native File System APIs have.

The first two aren't really defenses, but Safe Browsing might be.

Not directly related, but I wanted to add to this point, since this confusion comes up a lot. Secure contexts are never mitigations for abuse or attack when it comes to web platform APIs. HTTPS doesn't tell you that a site is trustworthy. It only tells you that you have some reason to believe the URL in the URL bar. evil.example can just as easily set up https://evil.example as good.example can set up https://good.example.

Rather, secure contexts are merely a baseline prerequisite for the question of trust to even make sense. We cannot possibly ask the user or otherwise decide if example.com allowed to do such-and-such if we have no way to identify example.com.

David

[Chris Palmer]

Hi all,

Some thoughts:

I responded to the point Anne made on Github. I had thought Darwin and Gary had spec'd a Mark Of The Web that (as with downloads on some platforms) would enable native apps to check and decide if they want to read the clipboard data. That might be close to satisfying that requirement? But either way, there are limitations to how effective that can be (detailed in Github).

I agree that secure contexts are a baseline requirement, not a mitigation against a malicious or compromised origin.

I do think a permission prompt helps a lot, even though it does not solve the whole problem, because it stops the attack scenario from being a pure drive-by, mass-malware scenario. Unless the user has given permission, the origin cannot populate the clipboard with a raw attack payload.

Even if the attacker could do so, the attack scenario would still require either a vulnerable native app to unilaterally read from the clipboard, or for a user to affirmatively paste into the vulnerable app. Neither of those things is guaranteed to happen, especially given other Cut/Copy gestures the user might issue (thus overwriting the attack payload). An attacker with a working exploit can increase their chances of success/decrease their chances of detection by tailoring their payload to the target platform — e.g. selecting an exploit payload for an app that is likely to be running on a given client OS, or not attacking on client platforms where the exploit won't work — but it's still not a straight shot.

Of course, that doesn't mean attackers won't try, and it doesn't mean they won't sometimes succeed. But I do also think attackers likely currently have more reliable attack chains in-hand. As it is, attackers who can craft memory corruption exploits are typically doing: compromise renderer -> attack available kernel surface -> win far too often. More convoluted attack chains are, unfortunately, not always necessary.

And, of course, the "trick a person into pasting an evil shell command" attack is well-attested already, and requires only plain text.

Note also that this proposed API is by no means the first, only, last, or most likely way that attack code can migrate from the web to native. There are downloads (protected by Safe Browsing/SmartScreen/et c.), Native File System API (also SB/SS/et c.), the HTTP cache (AV software, which is often vulnerable itself, will scan anything that hits the filesystem), and probably other things.

I don't mean to say that "there's already risk, so we should accept this risk too." Don't worry, that's not the kind of thing I generally say. :)

Instead, I mean that we need to have a rational and coherent approach to all these risks, because they are not going away. Raw Clipboard is not as special as it might seem.

I do think that a combination of permission prompts, SB/SS/et c., an expectation of user interaction with the origin, a requirement that the calling origin be the focused and/or main frame, and so on, has served us well and will continue to. Toward that end, Balazs Engedy also drew up a longer-term plan to rationalize the requirements we put on the caller long-term. I bet he'll respond with details.

[Chris Palmer]

Oops, forgot 1 thing:

As nice as Safe Browsing/SmartScreen/et c. are (and they certainly are!), they are not going to be the single thing that makes Raw Clipboard API safe, and the lack of them would not make Raw Clipboard API unsafe. They can look for bad file contents, but they won't (in their current state, anyway) be hunting for native app exploit payloads. (We can imagine adding that, maybe, but that's a whole other thing that would likely take some person-years.)

We (Darwin, I, and SB team) have been talking about providing hooks in Chromium's implementation for SB and SS to do their thing when the clipboard is populated, but I don't know if SB team has committed to implementing anything just yet. Varun might be able to say more.

[Darwin Huang]

As mentioned by Chris, we have reached out to the Safe Browsing team, but they haven't made any concrete commitments yet. That said, I agree that a service like Safe Browsing could certainly be very helpful for Clipboard, both in security implications in writing (preventing malware), and privacy implications in reading (preventing PII leakage), and we will make sure to continue exploring that.

I do also agree that secure context is simply also a prerequisite, and not a mitigation.

Thank you for the alternate proposal, Boris. That proposal is very interesting, but I can't think of a way in which that proposal would allow web applications to interoperate with existing native applications. If there is, it could certainly fulfill our needs. I'll also follow up in the Github thread.

--

- Darwin Huang

[Boris Zbarsky]

On 10/8/19 8:37 PM, 'Chris Palmer' via blink-dev wrote:
> I do think a permission prompt helps a lot, even though it does not
> solve the whole problem, because it stops the attack scenario from being
> a pure drive-by, mass-malware scenario.

I think there's a fundamental disagreement here, for what it's worth.
On the Mozilla side we feel that this is not a permissions prompts users
can usefully evaluate, and hence that click-through rates are likely to
be high. While this does mitigate somewhat compared to not having a
prompt at all, having malware with a high success rate is not _that_
much better than malware with a 100% success rate.

Of course the most useful thing there would be actual data on how users
respond to this prompt. Do you know whether any user studies have been
done on it, by any chance?

> Instead, I mean that we need to have a rational and coherent approach to
> all these risks, because they are not going away. Raw Clipboard is not
> as special as it might seem.

It seems like one coherent approach would be to attempt to reduce or
eliminate existing risks while not introducing new ones...

Other coherent approaches are possible, of course, but leaning on
permission prompts as a major aspect of the coherent approach is a
problem insofar as most users are not in a position to reason in an
informed way about the consequences of granting permission. At least,
again, that is Mozilla's point of view; I realize that the Chrome
security team does not agree.

-Boris

[Varun Khaneja]

I agree that having Safe Browsing check the clipboard contents has clear security benefits against malware.

At the same time, Safe Browsing integration in Chromium is ill-suited, in its current state, to:

1. Provide any privacy protections against clipboard contents, especially PII data.
2. Provide any protection against native app exploit payloads (what Chris said).

As for commitments and bandwidth, let's talk about that offline.

[Chris Palmer]

On Thu, Oct 10, 2019 at 7:09 AM Boris Zbarsky <bzba...@mit.edu> wrote:

On the Mozilla side we feel that this is not a permissions prompts users
can usefully evaluate, and hence that click-through rates are likely to
be high.

I'm not sure that "cannot usefully evaluate" necessarily leads to "will click through", because (in Desktop Chrome, at least) it is possible and common for people to completely ignore prompts. (See below.) They're not modal in Desktop Chrome.

I don't think clipboard permission is as esoteric as some other API prompts. But, yes, it's hard/impossible to explain, in a prompt, the risk of native app memory corruption via clipboard. But as I outlined previously, I don't think the clipboard is the most likely vector to memory corruption in native apps.

My ideal was and is for clipboard access to be mediated entirely by user gestures — actual Control+C, Control+V, et c. actions — but Darwin explained to me that that doesn't work for all the use cases we want to support. If that doesn't come through well enough in the explainer and/or spec docs, then maybe he can clarify further there.

So, a permission prompt is IMO a not-unreasonable fallback.

Of course the most useful thing there would be actual data on how users
respond to this prompt.  Do you know whether any user studies have been
done on it, by any chance?

We don't need to guess; Chrome has its telemetry (Googlers: Permissions.Action.*). I imagine Firefox does too. Assuming Raw Clipboard API takes flight, there will be telemetry for it too.

Our measurements show that people deny, ignore, and dismiss permission prompts very often (for some platform capabilities, far moreso than they allow). That is perhaps odd, but on the bright side it means that people are both not vulnerable to attacks on the prompt-protected attack surface and that they were not likely stymied in their workflow. Permission revocation is much less common but does also happen.

For those cases where the lack of permission would stop the user's workflow, such as trying to paste some .doc data into MS Word, I imagine people would give the permission.

Social engineering is still certainly a thing — we can all imagine a web app that seems legit, asks for raw clipboard for a seemingly-legit reason, and then attacks your native app after convincing you to paste into it. But, there have been successful self-XSS campaigns based on tricking people into opening up Dev Tools and pasting in JavaScript. Social engineering bad downloads is also very much a thing.

 

It seems like one coherent approach would be to attempt to reduce or
eliminate existing risks while not introducing new ones...

Permission prompts are not the world's most awesome thing, but they do fail closed and that is a significant win. And, as I outlined previously, prompts are just 1 part of a multifaceted strategy to control the risks while enabling the platform to have high utility.

The key reason Chrome's security team is willing to accept some risk and mitigate as much of it as possible, rather than doing the 'easy' thing of "not introducing new [risks]" — i.e. saying No to essentially every new platform API — is that we want the web to have a bright future as a powerful platform for powerful applications, while also being as safe as possible. The web is the platform without a centralized gatekeeper that also aims to isolate apps from each other and from the underlying system. The isolation is not entirely hermetic because that is not possible, and would preclude significant and useful use cases. But there are mechanisms of controlling the risk, and people are using them, and failing safely otherwise.

There is no story of monotonically decreasing risk at this stage of the web's development, because that is not what web users and web developers want at this time. If we want the web to be useful and to grow more useful, there will be risk. The era of the web being a world of only static documents ended in 1995. And that is good.

It does mean that we security engineers have a LOT of work to do, at every layer in the stack (and including outside our own stack). But we are. And that is good.

[Bo Cupp]

RE: Edge: No Signals...

This was discussed in the Editing TF (minutes) during this year's TPAC.  I expressed MSFT interest.

My intuition is that there are enough opportunities to enhance the security of the clipboard experience to make this safe.

gl...@microsoft.com and I are following up with our Windows clipboard team and our own security experts so we can understand how we'd mitigate the threats created by this API.  We'll share findings and/or concerns here when we have them.

Bo

[Darwin Huang]

Thank you, Bo! Sorry I didn't put any signals from Edge earlier because I didn't see them explicitly in the minutes, so wasn't sure if interest was public. I've updated the explainer to reflect this now :)

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/rkGWbui8B9A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/74da0061-11db-4912-b5a6-6d4d954c13f2%40chromium.org.

--

- Darwin Huang