Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

Oh, and for the record, the analytics company discussed in the Tim BL's
post could've really still manage to do what they were doing without any
copy events at all, it just would've been less accurate.

For example, they could've just as easily added event handlers for
right-click (contextmenu) or Ctrl+C keypresses when there is an active text
selection and make the assumption that the user intended to copy that text.
 They might be wrong some of the time with the right-click handling but it
would still be factual that the user at least had a special interest in the
text selection.

I actually think that kind of analytics is awesome — so long as it isn't
being used for evil, of course.  :)

Sincerely,
    James Greene



On Wed, Jul 24, 2013 at 8:07 PM, James Greene <james.m.greene@gmail.com>wrote:

> Paul:
>
> Looking at TimBL's 2010 post, I feel like it's from a slightly era in the
> web's lifetime.  Looking at this problem again with today's web, I'd rather
> see the ability for clipboard injection become a standard available API and
> rather create a browser extension to *prevent* it rather than to *enable* it.
>  To me, it's reminiscent of the discussion that probably occurred when the
> ability to create popup windows was first introduced, and then AdBlock (and
> similar apps, browser extensions, etc.) were soon to follow.
>
> Hell, I'd be happy to write some of the extensions myself if it helps push
> my agenda.  ;)
>
>
> Sincerely,
>     James Greene
>
>
>
> On Wed, Jul 24, 2013 at 3:22 PM, Paul Libbrecht <paul@hoplahup.net> wrote:
>
>>
>> James,
>>
>> I personally think it would be a really good idea. But I am not a browser
>> implementor.
>>
>> Overall, I agree with you that writing to the clipboard, only within a
>> click or key event processing maybe?, is likely to be a non-concern on
>> privacy. I would love to hear others' feedback.
>>
>> Is maybe a first step something such as a browser-extension?
>> Did you hear brags about users of websites that allowing copy was not a
>> good idea?
>>
>> (I heard a brag close to it by TimBL and J Gruber about the usage of
>> "clipboard injection":
>> http://lists.w3.org/Archives/Public/www-tag/2010Jun/0007.html are we
>> close to that? I think not but maybe can such a feature get close to it?)
>>
>> Paul
>>
>> On 12 juil. 2013, at 21:57, James Greene wrote:
>>
>> It appears that the only way to trigger a `copy` event programmatically
>> is to use `document.execCommand('copy')`, which most browsers prevent:
>>
>> http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events
>>
>> What about enabling so enabling semi-restricted programmatic clipboard
>> injection on a page if the user grants their express permission via a
>> once-per-domain security prompt (similar to the Geolocation API)?  IOW,
>> given a user's express permission to the origin and following a user's
>> pointer event or keyboard interaction, I would like to be able to simulate
>> the `copy` event (and the `beforecopy` event, if practical).
>>
>> I'm not quite sure how far this will go as "clipboard poisoning" is
>> always a real concern.  In fact, I understand that better than most, since
>> my desire to get such an adaptation to the Clipboard API spec is the
>> direct result of my work as the co-maintainer of the popular
>> ZeroClipboard <https://github.com/zeroclipboard/ZeroClipboard> library
>> (used by GitHub, bit.ly, and many other sites).  Jon and I would like
>> nothing better than to eliminate ZeroClipboard's dependency on Flash<https://github.com/zeroclipboard/ZeroClipboard/issues/171> but
>> that is unattainable given the current restrictions of this spec.
>>
>> If Flash doesn't live on for anything else, it may well live on longer
>> than it should for its unmatched ability to do programmatic clipboard
>> injection<http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()> after
>> a user's click or keypress.  :(
>>
>> Thoughts?
>>
>>
>> Sincerely,
>>     James Greene
>>     http://jamesgreene.net/
>>
>>
>>
>