Intent to Implement and Ship: Allow JS-triggered copy/cut with a user gesture

[Daniel Cheng]

Primary eng/PM emails dch...@chromium.org Spec http://dev.w3.org/2006/webapi/clipops/clipops.html#events-that-are-allowed-to-modify-the-clipboard Summary execCommand("copy") and execCommand("cut") should be allowed to modify the system clipboard in the context of a user gesture (the spec uses the language "allowed to show a popup"). Motivation

Today, execCommand("copy"/"cut"/"paste") aren't allowed on the open web, due to concerns about clobbering the clipboard and sniffing clipboard content. However, Right now, web developers already get around this restriction by using a Flash polyfill (see https://github.com/zeroclipboard/zeroclipboard for one example).

Compatibility Risk Firefox: No public signals Internet Explorer: No public signals Safari: No public signals Web developers: Positive Describe the degree of compatibility risk you believe this change poses The main compatibility risk is feature detection. According to the Editing spec, execCommand() should return false if a command is not supported or enabled.

- Internet Explorer: pops up a dialog with "Allow" and "Don't Allow". Clicking "Don't Allow" still returns true.

- Firefox: throws an exception if DOM-triggered clipboard operations aren't enabled

- Blink and WebKit both return false if execCommand() isn't supported/enabled.

Ongoing technical constraints None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)? Yes or no.

Yes. OWP launch tracking bug https://crbug.com/437908

Entry in Chromium Dashboard https://www.chromestatus.com/features/5223997243392000 Requesting approval to ship?

Yes.

[PhistucK]

Does Flash require a user gesture for this as well?

What about users that explicitly disable Flash for this reason (and other privacy issues, like super cookies, Flash local storage)?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Palmer]

"It's safe because we nagged the user with a pop-up" doesn't convince
me. Nor does "We might as well because Flash."

What are users to think of a pop-up that says, "Do you want to let
this web site do something that seems obvious and basic?" I suspect
they will be annoyed, and not understand the issue (after all, copying
and pasting is obvious and basic, so it's surely safe...). I suspect
that the gesture will not actually protect people from malicious
clipboard-sniffers.

Obvious and basic though copy/cut/paste is, this feature reverses the
power dynamic in a way that no pop-up can make obvious.

The best user gesture to assert user intent *is the one that already
exists in the operating system*.

What actual real-world application problem does this solve? I've seen
the apps that have a "click this Flash button to copy the following
text", but that's not obviously better than just letting people use
the existing and well-understood copy/paste mechanisms. Especially
since the open web could read whatever I have in my clipboard —
passwords from my password manager!, the texts of private emails, et
c. — and especially since the mitigation is basically a fig leaf, this
feature seems to create more problems than it solves.

[Daniel Cheng]

On Mon Dec 01 2014 at 12:26:14 PM PhistucK <phis...@gmail.com> wrote:

Does Flash require a user gesture for this as well?

Flash does require an explicit user gesture.

Daniel

[Jochen Eisinger]

if you say "allowed to show a popup", do you intend to also consume the user gesture (like the popup would)?

[Daniel Cheng]

On Mon Dec 01 2014 at 12:29:43 PM Chris Palmer <pal...@google.com> wrote:

"It's safe because we nagged the user with a pop-up" doesn't convince
me. Nor does "We might as well because Flash."

What are users to think of a pop-up that says, "Do you want to let
this web site do something that seems obvious and basic?" I suspect
they will be annoyed, and not understand the issue (after all, copying
and pasting is obvious and basic, so it's surely safe...). I suspect
that the gesture will not actually protect people from malicious
clipboard-sniffers.

Note that the scope is limited to copy and cut. Paste is explicitly not included in this list, due to the possibility of clipboard sniffing.

 

Obvious and basic though copy/cut/paste is, this feature reverses the
power dynamic in a way that no pop-up can make obvious.

The best user gesture to assert user intent *is the one that already
exists in the operating system*.

What actual real-world application problem does this solve? I've seen
the apps that have a "click this Flash button to copy the following
text", but that's not obviously better than just letting people use
the existing and well-understood copy/paste mechanisms. Especially
since the open web could read whatever I have in my clipboard —
passwords from my password manager!, the texts of private emails, et
c. — and especially since the mitigation is basically a fig leaf, this
feature seems to create more problems than it solves.

I think it could be interesting to see what % of copy/cuts are triggered by the system shortcut as opposed to one of the Flash polyfills. It could also be interesting to count the number of execCommand("copy") and execCommand("cut") attempts that fail today, since that might be another signal for how widespread this sort of thing would be. Unfortunately, the discussion thread didn't have explicit examples, but I would expect it to be useful for:

- Generic rich text editors (I don't have stats to measure this, but at least some of them expose 'copy', 'cut', and 'paste' through toolbar icons or menu items). Clicking on that item does nothing other than show an alert that you have to press Ctrl/Cmd+C instead to copy.

- "Click here to get a URL you can copy to your clipboard" type things, e.g. when you share a link in Google Docs.

Daniel

 

> email to blink-dev+unsubscribe@chromium.org.

[Daniel Cheng]

I guess the idea of consuming it for popups is to prevent multiple popups from being displayed with one user gesture? It doesn't seem like one user gesture should have to trigger than more one clipboard operation so... yes? Also, is 'consuming a user gesture' explicitly covered anywhere in the specs?

Daniel

[Jochen Eisinger]

no, it's not mentioned in the specs. I just wanted to clarify what exactly you meant.

btw, what's the use case for copy if you can't paste? Can websites paste using flash?

[Daniel Cheng]

The use case is to copy stuff to your clipboard so you can paste it elsewhere--e.g. a video link (vimeo.com), a repository URL (github.com), a shortened URL (bitly.com), etc.

http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0122.html has more interesting information about one specific Flash polyfill (for example, 35k+ clicks on the polyfill on github.com / day).

[Jochen Eisinger]

makes sense.

I think I can see an attack vector where the site copies some ads or something into your clipboard, but that's less concerning than being able to read the clipboard.

lgtm to ship

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM.

[Yoav Weiss]

Late to the party, but isn't the attack vector a website that'd copy "rm -rf /" or another malicious command to the user's clipboard, with hope that the user will later paste it to his shell?

[Jeffrey Yasskin]

Yes, but most users aren't pasting in a shell anymore, and almost any other target will quickly reveal that the site is malicious.

There's also http://thejh.net/misc/website-terminal-copy-paste for people who do copy to shells...

[Yoav Weiss]

Yeah, I'm aware of that shell copy attack, and as a result, do not copy/paste from untrusted websites. I guess the safety of that feature depends on the obviousness of the user gesture that's be required to enable copying into the clipboard.

[David Benjamin]

Or this one: https://davidben.net/copy-test.html

There's already a copy event for you to muck about with the clipboard all you like on Ctrl-C in JS, so there's no need to play layout games.

[stu...@testtrack4.com]

 The UX I'd like to see around this (maybe at some point in the future, and maybe starting with CrOS) is something akin to the "Screenshot captured" pop-up seen on Android and Chrome OS, where the OS/browser notifies you when something is copied to your clipboard post-facto, with an action button the user can click to "undo".

As for pasting, maybe there should be a "Content pasted" flash generated by the browser, akin to the "example.com is now full screen" notification, so, in the event that a malicious site steals the user's clipboard whenever they scroll, at least the user is notified of it.

Of course, either (or both) of these behaviors may be added (or extended) by an extension.

[PhistucK]

For copying and cutting, I think this is very reasonable.

Pasting is disallowed, so it is irrelevant at this point.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Lucas Garron]

Copy/cut is shipping to the general web in Chrome 42; this accidentally happened without a security review. (Test it on beta.)

However, pasting is probably coming soon. The plan is to ask the user to give the origin paste permissions, like other permission APIs/content settings.

A notification (e.g. "toast") would be nice, but details are to be figured out.

»Lucas