Allowing raw clipboard access is not acceptable for privacy & security

[rniwa]

I don't think we (Apple's WebKit team) are interested in allowing the "raw" access as proposed in the explainer as it poses serious privacy & security issues:

• Allowing raw clipboard content to be read poses a serious privacy risk because native applications put things such as user's physical mailing address into the clipboard content in a subtle way the user wouldn't even notice (e.g. in meta element in a HTML document)
• Allowing writing of arbitrary bytes as an arbitrary type would allow security vulnerabilities of native applications in which such a content is pasted to be exploited.

[othermaciej]

Indeed, this would expose all apps on the system with copy/paste to untrusted data from the internet, which is significant additional attack surface for sandbox escapes. Downloads present a similar issue, and browsers and operating systems have gone out of their way to limit malicious downloads. None of that would apply for data placed directly on the clipboard.

(You can take this as a negative implementor signal from Apple, at least as to the current version.)

[dway123]

Thank you for the prompt response, and sorry it took me a bit to reply.

The privacy and security self-assessment considers these issues now.

Privacy: The privacy concern of PII being placed in raw clipboard content should partially be addressed by the same protections afforded to the existing Clipboard API. Namely, there will be the same requirements of secure context, focused frame, and for the user to allow the permission. Arguably, the clipboard format that transfers the most sensitive content is plain text, which is commonly used to transfer passwords, social security numbers, and other sensitive information. Therefore, an email with an exposed email address should not be more dangerous than other content already placed on the clipboard. This is covered in more detail here.

Security: The security concern of malicious clipboard contents attempting to take advantage of insecure native application decoders, for example to do remote code execution, is addressed here. A permission prompt, and requirements of secure context and focused frame should help avoid unintended malicious clipboard contents from being written.

Downloads: Regarding downloads, as this proposed API is Async in nature, it should allow for user agents limit malicious clipboard use before resolving the promise.

Thank you for pointing out these concerns, and sorry I hadn't provided the privacy and security self-assessment earlier. I hope this helps address some of the concerns.

[rniwa]

Arguably, the clipboard format that transfers the most sensitive content is plain text, which is commonly used to transfer passwords, social security numbers, and other sensitive information.

This isn't entirely true. If the user were to paste a social security number or a password from somewhere as plain text, the user knows such sensitive information is being pasted.

What's problematic about meta data, etc... in other documents is that the user is often completely unaware of the presence of such information. For example, if I typed "hello, world" into a word processing app, I don't expect copying & pasting that into a website would expose my physical mailing address, my employer's name & my job title.

The issue is really of expectation & reality. So I do not agree with such a proposition. Also, even if I were to agree this is a more serious threat (which I do not), that is no basis to say we can ignore other threats.

Namely, there will be the same requirements of secure context, focused frame, and for the user to allow the permission.

The user would not understand the implication that pasting something into a website would expose user's physical mailing address. There is a lot of subtlety that needs to be explained, and a permission dialog would train the user to always click yes so we generally stay away from it. Not to mention that it would be a terrible user experience to prompt the user whenever the user tries to paste any content into a web app.

A permission prompt, and requirements of secure context and focused frame should help avoid unintended malicious clipboard contents from being written.

Secure context and focused frame would do nothing to protect random native applications in the local system. In fact, on iOS and macOS, the simple act of writing any data into pasteboard / clipboard can result in UIKit / AppKit to generate alternative types of the written data. This would mean that these system frameworks are actively parsing / processing the data put into the pasteboard. Given the current policy of writing into pasteboard in Safari and many other browsers is any direct user gesture such as clicking anywhere, this is not an acceptable security surface.

Furthermore, many users run clipboard / pasteboard utility applications which show previews, records history, etc... on their system. Any security vulnerability in such an application can be immediately exploited if we allow arbitrary bytes to be written into the clipboard of any MIME type.

Again, it would be a terrible user experience to prompt the user whenever the user tries to copy something from a web app. And the user would not understand many of the intricate details of what putting a content into the pasteboard would entail.

[dway123]

Hidden metadata: The user agent should make clear of the risks of accepting such a permission, and properly set expectations, to avoid issues of a user's expectations deviating too far from reality.

Permission: The dialog should be clear of the risks, and a user would therefore reject the permission if it doesn't seem reasonable for their use-case. As far as I'm aware, there are permissions for which users often reject, like "show notifications" and "allow GPS". Also, the user doesn't need to respond to a prompt whenever they try to paste content. The spec leaves this up to the implementation, and Chrome persists this permission on a per-origin basis.

Native Applications persistently processing clipboard data: The user should generally avoid allowing malicious websites access to raw clipboard access, just many other web APIs, but in the end the implementer/browser should protect the user. As this is an asynchronous API, there is plenty of time for implementers to insert safety checks like safe browsing, just as most implementers already do for Downloads.

Metadata and potentially dangerous data is currently removed via encoding/decoding, and stripping metadata/disallowing datatypes we can't ensure the safety of. The open web has requested a capability to access, for example, image metadata (JPEG image orientations), interop with specialized types (like audio formats or LaTeX), and similar things. They want to avoid the excessive (for their use cases) times associated with encoding/decoding, and generally achieve more on the web’s clipboard. If this proposal doesn’t sound like an appropriate solution, is there any different proposal, or a modification of this proposal, that might seem more appropriate?

[rniwa]

Hidden metadata: The user agent should make clear of the risks of accepting such a permission, and properly set expectations, to avoid issues of a user's expectations deviating too far from reality.

I don't think that's possible. Ordinary users hardly understand what it means to copy & paste. They have no idea of what meta data is even.

Permission: The dialog should be clear of the risks, and a user would therefore reject the permission if it doesn't seem reasonable for their use-case.

I don't think it's possible to come up with such an UI.

Also, the user doesn't need to respond to a prompt whenever they try to paste content. The spec leaves this up to the implementation, and Chrome persists this permission on a per-origin basis.

That is not the model of permission currently under consideration for Safari / WebKit.

The open web has requested a capability to access, for example, image metadata (JPEG image orientations), interop with specialized types (like audio formats or LaTeX), and similar things. They want to avoid the excessive (for their use cases) times associated with encoding/decoding, and generally achieve more on the web’s clipboard.

Just because someone requests for an API, it doesn't mean that adding such an API is a good idea. If someone were to request adding an API to have access to kernel memory, would you propose adding such an API? Some things are inherently unfit on the Web.

If this proposal doesn’t sound like an appropriate solution, is there any different proposal, or a modification of this proposal, that might seem more appropriate?

That needs to be decided on case by case basis for each and every use case. In the case of image meta data, for example, I could imagine each browser preserving a subset of EXIF data such as orientation, and even the clipboard spec having some suggestion as to what EXIF data should be preserved.

[dway123]

Safety and Understanding: While user agents should appropriately set expectations using appropriate strings to represent the API, safety in general should be assured by the user agent when providing an API to users. This API surface's async nature allows the opportunity to perform the same safe browsing checks applied for the Downloads API.

Appropriate-ness: Chrome believes that this API is appropriate for the web, and important to meet use cases the web would like. An issue with deciding sanitization schemes on a case-by-case basis is that user agents end up with a large array of encoders, decoders, and sanitizers, which may be better provided by web applications. These utilities are expensive to add and maintain, and more importantly, it is difficult to ensure cross-browser support for all these utilities. Therefore, Chrome does not think it’s appropriate to ignore the long tail of formats, and would like to provide this access through this API.

[rniwa]

Appropriate-ness: Chrome believes that this API is appropriate for the web, and important to meet use cases the web would like. An issue with deciding sanitization schemes on a case-by-case basis is that user agents end up with a large array of encoders, decoders, and sanitizers, which may be better provided by web applications. These utilities are expensive to add and maintain, and more importantly, it is difficult to ensure cross-browser support for all these utilities. Therefore, Chrome does not think it’s appropriate to ignore the long tail of formats, and would like to provide this access through this API.

Okay, so you're saying the ability to address the long tail of formats and the maintainability of your own codebase is more important than providing the best protection for user's security & privacy? That doesn't sound like the right trade off.

Also, web apps providing better privacy & security than a browser engine isn't a thing. While some web apps may opt to do so, one of UA's most important duties is to protect users from malicious websites; ones that don't provide such a protection.

So I guess we can continue to disagree on this point. However, I can't emphasize enough that bringing these same talking points at any F2F or elsewhere would not change the concerns we have expressed and we would not support this API as currently proposed. Without a cross vendor support, this API will likely remain as a prosperity API of Blink / Chrome.

[sspi]

An intermediate way: authorize any raw content, but restrict the content-type obligatorily prefixed by something like "web-unsecure/".

Thus, receivers knows they handle potentially compromised content and must parse it carefully and senders knows that the content can be potentially read by malicious code (and should not put sensitive data in metadata).

This solution does not resolve all use cases but allow many more use cases than the only "supportedFormats" approach.

[pwnall]

We (Chrome) do believe that Web applications need to interoperate with native applications using a long tail of formats in order to be competitive. Every creative application, from G Suite to Figma, would have an easier time gaining adoption if it were able to interoperate seamlessly with its native counterparts.

That being said, we want to do our best to ensure that we only ship capabilities that respect our users' security and privacy. I currently think that there is a way to make Raw Clipboard Access safe and, if I'm wrong, I'd like to learn why that is the case.

Code base maintainability is not a significant issue here. We have a solid foundation for adding new format support to our Async Clipboard API implementation. The main problem with having support for very many formats built into the browser is binary size. Every browser user has to pay bandwidth, disk space, and potentially RAM, for every format support. As we go further down the long tail of formats, this tradeoff becomes unfavorable.

To be clear, having many standardized formats / a large binary size is a side problem. I think that the real blocker to the strategy of building dedicated support for each format is that it takes a significant amount of resources to get something on the Web Platform.

Regarding the security concerns, I am probably overly naive, but raw access via the Async Clipboard API seems very similar to the Downloads API to me. Both APIs facilitate storing an opaque binary blob in a system location where native applications may read it. In both cases, native applications may access the data without any additional user interaction. Examples for the Downloads API case are file browsers (File Explorer, Finder, etc.) that render previews, and Camera Upload software that scans the system for media files and uploads it to the user's cloud account.

Browsers have developed (formidable) defenses for the Downloads API, such as Safe Browsing. These defenses can detect malicious content of all formats, ranging from executable code, to scripts embedded in documents and spreadsheets, to media. Right now, I think it's reasonable to assume that our security teams can figure out similar solutions for the Clipboard API. The problem doesn't seem very different to me.

[rniwa]

To be clear, having many standardized formats / a large binary size is a side problem. I think that the real blocker to the strategy of building dedicated support for each format is that it takes a significant amount of resources to get something on the Web Platform.

Yes, arguing & agreeing on how to make each & every format safe for the consumption on the Web would take a lot of time & effort. But that's no excuse for adding a Web API that poses serious security & privacy threats.

Regarding the security concerns, I am probably overly naive, but raw access via the Async Clipboard API seems very similar to the Downloads API to me. Both APIs facilitate storing an opaque binary blob in a system location where native applications may read it. In both cases, native applications may access the data without any additional user interaction. Examples for the Downloads API case are file browsers (File Explorer, Finder, etc.) that render previews, and Camera Upload software that scans the system for media files and uploads it to the user's cloud account.

A downloaded file or a file in external drive potentially being dangerous is a well known security. This is why many operating systems such has macOS and Windows specifically tag downloaded files as such, and ask the user before opening it.

On the other hand, there is no user prompt for when the user copies or pastes content on the Web. Native applications aren't typically written to deal with the system clipboard containing malicious content.

Browsers have developed (formidable) defenses for the Downloads API, such as Safe Browsing. These defenses can detect malicious content of all formats, ranging from executable code, to scripts embedded in documents and spreadsheets, to media. Right now, I think it's reasonable to assume that our security teams can figure out similar solutions for the Clipboard API. The problem doesn't seem very different to me.

So... instead of the browser implementing ways to detect & sanitize data formats, the operating systems are going to implement ways to detect & neutralize all malicious contents? I really don't see how that's any different from standardizing on each MIME type for the clipboard API in the first place because one implementation of such a safety mechanism in the operating system is to prohibit reading & writing of arbitrary MIME types, and only allow a fixed set of MIME types whose contents are then sanitized.

Note that the privacy aspect of the proposed API is even worse. The user has no expectation that pasting a single line of a text from a native app would expose privacy sensitive information whereas the user generally understands the idea that any information included in a file is exposed to a website if the user uploads the file to the website.

[othermaciej]

Browsers have developed (formidable) defenses for the Downloads API, such as Safe Browsing. These defenses can detect malicious content of all formats, ranging from executable code, to scripts embedded in documents and spreadsheets, to media. Right now, I think it's reasonable to assume that our security teams can figure out similar solutions for the Clipboard API. The problem doesn't seem very different to me.

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.

[othermaciej]

An intermediate way: authorize any raw content, but restrict the content-type obligatorily prefixed by something like "web-unsecure/".

Using custom MIME types that are not in current use anywhere would be closer to being safe. But it would also defeat the interop purpose of this API, at least until apps start recognizing these untrusted types, as well as putting them on the pasteboard.

[sspi]

Using custom MIME types that are not in current use anywhere would be closer to being safe. But it would also defeat the interop purpose of this API, at least until apps start recognizing these untrusted types, as well as putting them on the pasteboard.

Sure, but if a such prefix is standardized in few months or years each native apps will implements the trusted AND untrusted formats (with less privacy datas on write and more carefully parsing for reads). Each mime "application/xyz" will have his counterpart, like "untrusted/application/xyz".

These additional months of waiting are not prohibitive if this solution proves to be the best compromise between features and security.

[othermaciej]

These additional months of waiting are not prohibitive if this solution proves to be the best compromise between features and security.

I agree that this version would likely be better from a security POV, just not sure how long it would take native apps to support web-safe parsing. There's also the reading side to consider. Native apps would have to learn to output the extra web-safe format to the clipboard.

[dway123]

@sspi, use of some not-already-used format (either through a prefix or as one consistent format name) was considered in the design of raw clipboard access, but as mentioned by @othermaciej, this would break the compatibility goals of this API, as native apps would be unlikely to quickly adopt such an API. Many popular native apps are no longer under active development, or have release cycles of only once every year (or slower).

[pwnall]

To be clear, having many standardized formats / a large binary size is a side problem. I think that the real blocker to the strategy of building dedicated support for each format is that it takes a significant amount of resources to get something on the Web Platform.

Yes, arguing & agreeing on how to make each & every format safe for the consumption on the Web would take a lot of time & effort. But that's no excuse for adding a Web API that poses serious security & privacy threats.

I didn't mean to post my reply as an excuse. I mean it as a motivation for spending time and mental energy to reason about this feature. In our view, the problem of enabling long-tail formats on the clipboard is worth solving. We want to solve the difficult problems involved here, not side-step them. Rest assured, we do not intend to settle for something that would undermine our users' security and privacy.

Regarding the security concerns, I am probably overly naive, but raw access via the Async Clipboard API seems very similar to the Downloads API to me. Both APIs facilitate storing an opaque binary blob in a system location where native applications may read it. In both cases, native applications may access the data without any additional user interaction. Examples for the Downloads API case are file browsers (File Explorer, Finder, etc.) that render previews, and Camera Upload software that scans the system for media files and uploads it to the user's cloud account.

A downloaded file or a file in external drive potentially being dangerous is a well known security. This is why many operating systems such has macOS and Windows specifically tag downloaded files as such, and ask the user before opening it.

I don't think I agree with this claim in its entirety. When I save images from the Web, both Finder and File Explorer render previews of the images. If their image decoders are exploitable, this could result in malicious code execution.

On the other hand, I do think it's worth exploring adding a tag to clipboard content generated by Web applications. I expect that we'll follow up on this idea. Thank you!

On the other hand, there is no user prompt for when the user copies or pastes content on the Web. Native applications aren't typically written to deal with the system clipboard containing malicious content.

I agree that this is how copying and pasting is handled right now, but I don't think this should limit future API design. In my understanding, the asynchronous nature of the clipboard API means the browser could choose to prompt the user (in a myriad of ways) before operating on the system clipboard.

Browsers have developed (formidable) defenses for the Downloads API, such as Safe Browsing. These defenses can detect malicious content of all formats, ranging from executable code, to scripts embedded in documents and spreadsheets, to media. Right now, I think it's reasonable to assume that our security teams can figure out similar solutions for the Clipboard API. The problem doesn't seem very different to me.

So... instead of the browser implementing ways to detect & sanitize data formats, the operating systems are going to implement ways to detect & neutralize all malicious contents? I really don't see how that's any different from standardizing on each MIME type for the clipboard API in the first place because one implementation of such a safety mechanism in the operating system is to prohibit reading & writing of arbitrary MIME types, and only allow a fixed set of MIME types whose contents are then sanitized.

Apologies, I must be using terms that have different meanings in our corners of the world.

Chrome's Safe Browsing technology is built into the browser, and flags malicious content before it is exposed to other applications. We only use the other steps discussed here (Mark of the Web, invoking the OS anti-virus software) for content that cleared Safe Browsing checks.

So, I didn't intend to abdicate responsibility to the OS here. We are working closely with Chrome's security teams for every new capability that we aim to expose to the Web. We consider that the measures we are building into Chrome will keep our users safe.

Regarding the difference between blocking bad content via the Raw Clipboard Access and standardizing each MIME format -- I think they are fundamentally different problems. Most solutions that I'm aware of for flagging malicious content do not require perfect understanding of the content. So, I think it is worth designing a general API, even if some browser vendors will choose to implement it by blocking access to all MIME types that they cannot parse.

Note that the privacy aspect of the proposed API is even worse. The user has no expectation that pasting a single line of a text from a native app would expose privacy sensitive information whereas the user generally understands the idea that any information included in a file is exposed to a website if the user uploads the file to the website.

I think we'll have to simply disagree here. All native applications have unrestricted access to the clipboard. As a user, I (should) expect that the data I place on the clipboard is completely accessible to the application that I paste it in. From a different angle, the bug reports that we are receiving indicate that our users expect that clipboard data is accessible to sites, and are upset & frustrated when pasting does not result in a full-fidelity copy.

[dway123]

Thank you again for voicing your concerns. @rniwa, @pwnall, @garykac, myself, and many others met and discussed this API at W3C TPAC last week.

Feel free to correct me, but I think we had a productive conversation about this API. I believe Webkit continues to find the capability v. security/privacy tradeoffs to be unacceptable (too dangerous), and Chrome continues to find them acceptable, with security/privacy concerns often mitigate-able, and capabilities provided as essential to improving the web platform.

As it seems Webkit and Chrome may continue to disagree on this, we have agreed that a minimal implementation of auto-rejecting on raw clipboard access attempts may be acceptable for Webkit, in order to avoid user agent sniffing and simplify fallback logic for web application implementations. I've added this information to the explainer here.

Following up on the issue of tagging web-originated clipboard content, I have also drafted an explainer on Clipboard Mark of the Web, which seemed to have generally positive reception, but questions regarding whether this should be a browser or OS-level feature.

@sspi Many other folks have also echoed suggestions of some pickling format. I've expanded on why we chose not to allow this here.

I'm happy to continue these conversations, but if we wish to continue discussing the minimal implementation or pickling, please file separate issues to discuss them in. (I put this message in this thread as it seemed the most appropriate place in this repo to mention the discussions at TPAC) That way, this thread can mostly focus on the privacy/security ramifications of this API. Thanks! :)

[hober]

@rniwa, @pwnall, @garykac, myself, and many others met and discussed this API at W3C TPAC last week.

I'm sorry I missed this; I had an unavoidable conflict.

I believe Webkit continues to find the capability v. security/privacy tradeoffs to be unacceptable (too dangerous), and Chrome continues to find them acceptable[...] As it seems Webkit and Chrome may continue to disagree on this[...]

My understanding from the minutes of your F2F is that Mozilla joined WebKit in finding the security / privacy tradeoffs to be unacceptable:

@smaug----: this is exposing too many security bugs, we can't do this

[othermaciej]

we have agreed that a minimal implementation of auto-rejecting on raw clipboard access attempts may be acceptable for Webkit

To be clear, we are not committing to implementing this in any form, even auto-rejecting. It would not make sense to put work into implementation and testing for a feature that we think should not be part of the web platform (because there's no plausible way to make it safe enough).

[dway123]

My understanding from the minutes of your F2F is that Mozilla joined WebKit in finding the security / privacy tradeoffs to be unacceptable

Yes, this seems to be the case, but I see that you've asked Mozilla for an official position here. Thank you for filing the request.

To be clear, we are not committing to implementing this in any form, even auto-rejecting.

Thank you for the clarification. I understand that no commitments to prioritization or implementing were made.

This feature detection alternative via auto-rejecting was simply agreed to be a positive alternative to user agent detection / browser sniffing by web applications, a concern that already exists in the wild. This auto-rejecting implementation should not exhibit any security or privacy concerns (besides aiding in identification of the user agent, which is already possible via user agent detection).

That said, I understand if you decide not to implement auto-rejecting, due to a concern of auto-rejecting supporting a feature that Webkit doesn't believe should be part of the web platform.

[rniwa]

As far as I could recall, the latest discussion in TPAC was to fallback automatically to sanitized mode and let the client know after the fact. This would prevent websites from relying on this API ever existing any shape or form.

Having said that, this was a concession based on the idea that Blink may ship this feature regardless of whether Apple & Mozilla support this feature or not.

Our primary feedback is that we shouldn’t do this in the first place because the user wouldn’t understand the intricacy and the implication of what it means to allow raw clipboard access. Blink browsers on macOS implementing this API won’t be great even if WebKit didn’t because it would threaten macOS user’s privacy and security and we care about users of macOS in general.

[dway123]

Thank you all for the insight and discussion.

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

I'll close this issue for now, and likely ask for your thoughts after we come up with an amended API proposal that will offer more protections.

[othermaciej]

Since the Explainer is still there and still has the same problems, I don't think it's valid to close this issue. You're closing a valid issue on the currently published explainer due to internal plans, and that doesn't seem right. If you archive the repo, or update the explainer with a prominent notice that it will be redone entirely, then it would be fine. Or better yet, wait until there is a new explainer that attempts to resolve these issues.

This is different from the TAG issue, which was a request for review from you. This is feedback from others that is not yet addressed.

(I don't have the power to reopen personally.)

[dway123]

Fair. I'll re-open this, and may archive or update this explainer in order to resolve this issue. Thanks for the explanation.

[marcoscaceres]

@dway123 thanks for reopening the issue. Cc'ing @WICG/chairs to se we can follow along. Give us a shout if you need anything.

[proac50]

How to re-allowing raw clipboard access？thanks.