Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature-Policy: clipboard-read and clipboard-write #322

Open
bershanskiy opened this issue Jun 19, 2019 · 9 comments
Open

Feature-Policy: clipboard-read and clipboard-write #322

bershanskiy opened this issue Jun 19, 2019 · 9 comments

Comments

@bershanskiy
Copy link

@bershanskiy bershanskiy commented Jun 19, 2019

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
Copy link

@tomayac tomayac commented Mar 20, 2020

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
Copy link

@NicholasHallman NicholasHallman commented Apr 17, 2020

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

@eduxdream
Copy link

@eduxdream eduxdream commented Apr 21, 2020

any news about the issue or workaround?

@NicholasHallman
Copy link

@NicholasHallman NicholasHallman commented Apr 22, 2020

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
Copy link

@jondcoleman jondcoleman commented Apr 24, 2020

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

@bershanskiy
Copy link
Author

@bershanskiy bershanskiy commented Apr 24, 2020

@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
Copy link

@jondcoleman jondcoleman commented Apr 24, 2020

Hmm, ok. Thanks for the reply @bershanskiy

@dway123
Copy link

@dway123 dway123 commented Apr 24, 2020

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

@bershanskiy
Copy link
Author

@bershanskiy bershanskiy commented Apr 24, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants