Feature-Policy: clipboard-read and clipboard-write

[bershanskiy]

Background

There are two APIs that allows programmatic interaction with the system clipboard (see clipboard content and change it), they are Clipboard API and events (also referred to as "asynchronous clipboard API") and document.execCommand (no longer developed and partially deprecated).

Proposal

Feature-Policies directives clipboard-read and clipboard-write that to control availability of API for interacting with the system clipboard, much like the Permissions API.

Usefulness

This would be useful for embedding an untrusted third-party iframe with video/comment form/etc. on a page without giving that iframe ability to mess with the clipboard.

Clear distinction who requests clipboard-read and clipboard-write permissions

Last I checked, the Permissions API does not differentiate the top frame and an embedded frame so all permissions requested in an iframe are either automatically rejected or relayed to the user as coming from the top frame. Mostly, this is intentional, since spec authors believe user in general might not be able to distinguish the two (and I agree with this reasoning). Therefore implementers have to choose between over-extending permissions and making some use-cases impossible. Feature-Policy directive would enable top frames to not share their permissions with untrusted frames or actually endorse relaying these permissions to them.

Default allow lists

Both directives default allow lists should be either "*" or "self" to avoid breaking any existing websites. I'm still unsure which one is more appropriate to which (probably we should consult the implementers).

[tomayac]

This feature would have been nice for a clipboard demo that I wanted to embed in a blog post: https://blog.tomayac.com/2020/03/20/multi-mime-type-copying-with-the-async-clipboard-api/#demo.

[NicholasHallman]

I'm also looking for this. chrome mentions that it's blocked by feature policy but there is no policy to enable it.

[eduxdream]

any news about the issue or workaround?

[NicholasHallman]

any news about the issue or workaround?

If you control both the parent window and the iframe you can do the following.

// outside the iframe
window.addEventListener('message', data => {  
  switch(data.type){  
    case "copy-to-clipboard":  
      navigator.clipboard.writeText(data.toCopy)  
      break;
    }  
  }  
}  

// in the iframe
window.parent.postMessage({type: 'copy-to-clipboard', toCopy: 'Something to copy'}, '*')

[jondcoleman]

I'm facing this issue also. In my case, I don't control the parent window.

[bershanskiy]

@jondcoleman

I'm facing this issue also. In my case, I don't control the parent window.

You can't do much if the parent window does not cooperate with you. Even if there was a clipboard feature directive, parent would have to delegate permission to an iframe via Feature-Policy header or allow attribute on <iframe>.

[jondcoleman]

Hmm, ok. Thanks for the reply @bershanskiy

[dway123]

Regarding the Chrome issue... Sorry, I suspect this was caused by https://crbug.com/1074489, which we're working on fixing right now.

[bershanskiy]

@dway123 Thank you for the update!

FYI, @tomayac @NicholasHallman @jondcoleman @eduxdream the proposed Chromium implementation and the upcoming specification bundle read and write into a single directive called "clipboard". That is more in line with #198 filed by @lgarron all the way back in Aug. 2018.