Re: Why the clipboard API needs copy/paste event simulation as a permission option

We've discussed enabling click-to-copy in another thread (
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0061.html and
beyond) and have agreed that it is an acceptable risk.

When I started the thread, I had also mentioned requesting site-wide user
permissions as an option (e.g. like the Geolocation API) but, again, it was
deemed irrelevant as allowing click-to-copy out-of-the-box is now
considered an acceptable risk.

Generally speaking, I think what you are proposing would be so fantastic
for testing purposes but that it is generally overshooting a bit for normal
users.  Perhaps requesting side-wide permissions would be a sufficient
compromise to getting that approved, though?  I'm not positive.  One thing
that would be nicer about pursuing such a route in the HTML5 Clipboard API
world vs. the security uproar that resulted when Flash 9 allowed unprompted
clipboard injection is that this could legitimately be restricted to just
the site domains, thus avoiding having annoying ads from another domain
injecting into your clipboard.

Thoughts from others?

Sincerely,
    James Greene



On Wed, Aug 7, 2013 at 12:34 PM, James Babcock <jimrandomh@gmail.com> wrote:

> Currently, the clipboard API allows Javascript to read the clipboard
> in response to a paste event (in most UAs, that's when the user types
> Ctrl+V or picks Paste from the default context menu); and it lets JS
> write to the clipboard in response to a copy event (when the user
> types Ctrl+C or picks Copy from the default context menu). Generating
> these events with document.execCommand is disallowed for security
> reasons, because of concerns about clipboard stealing and clipboard
> poisoning: someone might write a script that watches the clipboard for
> things that look like passwords and steals them, or for things that
> look like shell commands and replaces them with something nasty. This
> is a legitimate concern, but there really needs to be a way to grant
> pages permission to access the clipboard. To see why this is
> important, observe:
>
> In Google Docs, if you pick Copy or Paste from its menu or a context
> menu, it prompts you to install a plugin.
>
> This is a particularly conspicuous example, but it's not the only one.
> Anything that wants to replace the default context menu is faced with
> a dilemma: most browsers' default context menu has cut/copy/paste
> options on it, but a replacement context menu can't. Another case
> where it's a problem is in browser-based ssh clients, where Ctrl+C is
> not available as a hotkey for "copy", but copy/pasting is nevertheless
> very important (so important, in fact, that many terminals copy to the
> clipboard on text-select without any keystroke at all). This is a
> problem for one of my side-projects (a browser-based extended
> terminal), and a fairly serious one, so I'd like to see this resolved;
> I don't want to have to include a plugin and only support one browser.
>
> (For my particular application, I would strongly prefer that the
> access permission not be limited to responding to input events,
> because I'm working in a programming model where the client page is a
> stub that sends DOM events and receives DOM mutations, so the state
> necessary to fill the clipboard, and to determine which keystrokes
> correspond to copy/paste events, all lives on the server side.
> Limiting access to times when the tab is visible and the window is
> focused is fine, though.)
>
>
>