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

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

Received on Wednesday, 7 August 2013 21:15:45 UTC