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

[Anne van Kesteren]

On Tue, Feb 18, 2014 at 1:12 PM, Hallvord R. M. Steen
 wrote:
> So, the story so far is that the spec has added something it labels 
> "semi-trusted events" - that is an event triggered from a trusted event of a 
> whitelisted type. The precedence here is popup blocking - browsers already 
> have rules for which events are "more trusted than others" in terms of likely 
> expressing user intent. (An example makes this clearer: scripts are typically 
> allowed to call window.open() from a click event listener, but are typically 
> not allowed to call window.open() from an load or mouseover listener.)

Those rules are part of a standard these days:
http://www.whatwg.org/specs/web-apps/current-work/#allowed-to-show-a-popup

You might want to file a bug to extend the list of trusted event types there.


-- 
http://annevankesteren.nl/

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

[Hallvord R. M. Steen]

So, the story so far is that the spec has added something it labels 
"semi-trusted events" - that is an event triggered from a trusted event of a 
whitelisted type. The precedence here is popup blocking - browsers already have 
rules for which events are "more trusted than others" in terms of likely 
expressing user intent. (An example makes this clearer: scripts are typically 
allowed to call window.open() from a click event listener, but are typically 
not allowed to call window.open() from an load or mouseover listener.)

However..

> Also, will there be any way for us to feature detect when this is available?

I've still not really been able to come up with a nice way to feature detect 
these "semi-trusted events".

Good ideas requested and appreciated..

> I'm thinking that just using `document.queryCommandSupported("copy")` and
> `document.queryCommandEnabled("copy")` could return some false positives
> (i.e. the feature is not yet implemented but returns `true` anyway) when
> the user is working within a "contenteditable" element, right?

No idea what the current implementation state of these calls are..
-Hallvord

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

[James Greene]

Also, will there be any way for us to feature detect when this is available?

I'm thinking that just using `document.queryCommandSupported("copy")` and
`document.queryCommandEnabled("copy")` could return some false positives
(i.e. the feature is not yet implemented but returns `true` anyway) when
the user is working within a "contenteditable" element, right?

Sincerely,
James Greene



On Fri, Sep 13, 2013 at 10:10 AM, James Greene wrote:

> Excellent.  Thank you!
>
> Should we be including touch device events, too?  e.g. "touchend",
> "pointerup", etc.
>
> Sincerely,
> James Greene
>
>
>
> On Fri, Sep 13, 2013 at 4:12 AM, Hallvord Steen wrote:
>
>> >> AFAIK Flash shipped with a more liberal model first, but the abuse
>> problem
>> >> was considered significant enough to tighten the model and make it more
>> >> restrictive.
>>
>> > That's correct:
>> >   - In Flash 9, you could use the
>> > `System.setClipboard<
>> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system
>> > /System.html#setClipboard()>`
>>
>> Thanks for outlining the history and documentation. I think we should
>> give authors (at least) the same convenience as Flash does. Reported here:
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
>>
>> -Hallvord (in "I will try to get around to actually updating the spec
>> too"-mode)
>>
>
>

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

[James Greene]

Excellent.  Thank you!

Should we be including touch device events, too?  e.g. "touchend",
"pointerup", etc.

Sincerely,
James Greene



On Fri, Sep 13, 2013 at 4:12 AM, Hallvord Steen  wrote:

> >> AFAIK Flash shipped with a more liberal model first, but the abuse
> problem
> >> was considered significant enough to tighten the model and make it more
> >> restrictive.
>
> > That's correct:
> >   - In Flash 9, you could use the
> > `System.setClipboard<
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system
> > /System.html#setClipboard()>`
>
> Thanks for outlining the history and documentation. I think we should give
> authors (at least) the same convenience as Flash does. Reported here:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
>
> -Hallvord (in "I will try to get around to actually updating the spec
> too"-mode)
>

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

[Hallvord Steen]

>> AFAIK Flash shipped with a more liberal model first, but the abuse problem
>> was considered significant enough to tighten the model and make it more
>> restrictive.

> That's correct:
>   - In Flash 9, you could use the
> `System.setClipboard /System.html#setClipboard()>`

Thanks for outlining the history and documentation. I think we should give 
authors (at least) the same convenience as Flash does. Reported here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235

-Hallvord (in "I will try to get around to actually updating the spec too"-mode)

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

[Hallvord Steen]

[Replying to Paul's mail but it's really a response to James - sorry, 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

Correct.

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

Well, with my spec editor's hat on: Nothing really prevents UAs from 
implementing this already. They could hook up document.execCommand('Copy') to 
whatever that UA's convention for a security permission prompt is. I'd like to 
see this, actually.

That said, this functionality doesn't really have privacy implications (as long 
as it is about programmatically *writing to*, not *reading from* the clipboard) 
so it's mostly just about preventing nuisance, plus some slightly far-fetched 
security threats (which aren't all that credible if they are not already 
exploited with Flash's clipboard implementation). Our intentions as 
implementors has sort of moved towards enabling all the cool stuff apps and 
sites might do, and away from trying to control nuisance. It's quite possible 
to argue that writing to the clipboard should be enabled by default.
-Hallvord

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

[James Greene]

>
> AFAIK Flash shipped with a more liberal model first, but the abuse problem
> was considered significant enough to tighten the model and make it more
> restrictive.


That's correct:

   - In Flash 9, you could use the
`System.setClipboard`
   method to write to the user's clipboard without *ANY* user interaction
   whatsoever.
  - This led to some security uproar about malicious clipboard
poisoning,
  especially since many of the SWFs that people created passed the text to
  inject via URL params, thus allowing XSS attacks to easily inject into
  someone's clipboard just by requesting their SWF resource with the right
  URL params.
  - Unsurprisingly, the uptake in Flash-based ads were a huge
  contributor to the problem back then.

  - In Flash 10+, Adobe locked
downthe
`System.setClipboard` method and the [then] new `
   
flash.desktop.Clipboard`
   class a bit more such that clipboard interactions (including settings and
   clearing) could *ONLY* be performed as a *synchronous *operation
   immediately following a user's click or keyboard event.
  - This also means that you cannot use async XHRs for fetching the
  data to inject; while it is unfortunate to have to use sync XHRs instead,
  the synchronous flow is obviously very important for the security of the
  user's clipboard.


If you look at the Flash docs I've linked to, it's important to notice when
they differentiate between when the context of Adobe AIR (where there are
no such clipboard restrictions) and Adobe Flash Player (where there are).



Sincerely,
James Greene



On Fri, Jul 26, 2013 at 9:37 AM, Hallvord Steen  wrote:

> > leaving it up to the browser vendors WITHOUT an agreed upon
> > standard (or at least "marching direction") means zero progress.
>
> I'd argue that the spec gives a "marching direction", but I'd like to pass
> a simple question on to the implementors and the security/privacy experts
> around here:
>
> Should we allow document.execCommand('copy') on all sites by default?
>
> Pro arguments include: web apps and sites can offer "copy to clipboard"
> functionality without Flash hacks. We avoid reliance on yellow warnings,
> which seem destined to be used for so many APIs over time that the user
> will be annoyed and maybe start automatically clicking yes. It's probably
> good in general to reduce the number of separate privileges web authors
> need to worry about having or not having, by omitting privilege
> requirements for the less risky actions.
>
> Contra arguments include: being able to write to clipboard can be abused
> to cause nuisance, in that every page you load can overwrite what's on your
> clipboard. Such behaviour could and should be self-defeating for a web site
> that wants to have return visitors, but in this case it may be hard to
> figure out exactly which website caused the issue, since clipboard entry
> meta data like "originating URL" is normally not available to users. (One
> might imagine a site placing ad copy for some service on your clipboard,
> but the perceived nuisance, data loss and annoyance would make it a very
> poor ad channel indeed). AFAIK Flash shipped with a more liberal model
> first, but the abuse problem was considered significant enough to tighten
> the model and make it more restrictive.
>
>
> -Hallvord
>

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

[James Greene]

*Correction:*
leaving it up to the browser vendors WITHOUT an agreed upon standard (or at
least "marching direction") means zero progress.


Sincerely,
James Greene



On Wed, Jul 24, 2013 at 8:11 PM, James Greene wrote:

> Ryosuke & Anne —
> Agreed with Anne, leaving it up to the browser vendors an agreed upon
> standard (or at least "marching direction") means zero progress.
>
>
> Sincerely,
> James Greene
>
>
>
> On Wed, Jul 24, 2013 at 7:32 PM, Anne van Kesteren wrote:
>
>> On Jul 12, 2013, at 12:57 PM, 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
>>
>> On Wed, Jul 24, 2013 at 5:18 PM, Ryosuke Niwa  wrote:
>> > I don't want the clipboard API specification to mandate one behavior or
>> > another.  It's something each browser vendor should be able to decide.
>>
>> That's the situation we are in now and it sucks for developers. We
>> should be able to do better.
>>
>>
>> --
>> http://annevankesteren.nl/
>>
>
>

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

[James Greene]

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 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  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  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 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
>>  after
>> a user's click or keypress.  :(
>>
>> Thoughts?
>>
>>
>> Sincerely,
>> James Greene
>> http://jamesgreene.net/
>>
>>
>>
>

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

[James Greene]

Ryosuke & Anne —
Agreed with Anne, leaving it up to the browser vendors an agreed upon
standard (or at least "marching direction") means zero progress.


Sincerely,
James Greene



On Wed, Jul 24, 2013 at 7:32 PM, Anne van Kesteren  wrote:

> On Jul 12, 2013, at 12:57 PM, 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
>
> On Wed, Jul 24, 2013 at 5:18 PM, Ryosuke Niwa  wrote:
> > I don't want the clipboard API specification to mandate one behavior or
> > another.  It's something each browser vendor should be able to decide.
>
> That's the situation we are in now and it sucks for developers. We
> should be able to do better.
>
>
> --
> http://annevankesteren.nl/
>

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

[James Greene]

Hallvord —
I have also long agreed that clipboard poisoning is rarely that big of an
issue so long as we're not enabling programmatic reading of the clipboard
during a copy event (which I would agree is completely unnecessary).  As
you said, since Flash is already an available option to do this today (and
can thus only be prevented by disabling Flash, or enforcing specialized
clipboard sandboxing at a system level), moving it into the DOM world isn't
a big stretch by any means.

I also agree that making this ability the default is not unreasonable
anymore but I thought that might be a bit of a stretch... happy to see that
I am wrong. :)


Sincerely,
James Greene



On Wed, Jul 24, 2013 at 5:34 PM, Hallvord Steen  wrote:

> [Replying to Paul's mail but it's really a response to James - sorry,
> 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
>
> Correct.
>
> > 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)?
>
> Well, with my spec editor's hat on: Nothing really prevents UAs from
> implementing this already. They could hook up document.execCommand('Copy')
> to whatever that UA's convention for a security permission prompt is. I'd
> like to see this, actually.
>
> That said, this functionality doesn't really have privacy implications (as
> long as it is about programmatically *writing to*, not *reading from* the
> clipboard) so it's mostly just about preventing nuisance, plus some
> slightly far-fetched security threats (which aren't all that credible if
> they are not already exploited with Flash's clipboard implementation). Our
> intentions as implementors has sort of moved towards enabling all the cool
> stuff apps and sites might do, and away from trying to control nuisance.
> It's quite possible to argue that writing to the clipboard should be
> enabled by default.
> -Hallvord
>

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

[James Greene]

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  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 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 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
>  after
> a user's click or keypress.  :(
>
> Thoughts?
>
>
> Sincerely,
> James Greene
> http://jamesgreene.net/
>
>
>

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

[Anne van Kesteren]

On Jul 12, 2013, at 12:57 PM, 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

On Wed, Jul 24, 2013 at 5:18 PM, Ryosuke Niwa  wrote:
> I don't want the clipboard API specification to mandate one behavior or
> another.  It's something each browser vendor should be able to decide.

That's the situation we are in now and it sucks for developers. We
should be able to do better.


-- 
http://annevankesteren.nl/

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

[Ryosuke Niwa]

On Jul 12, 2013, at 12:57 PM, 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 don't want the clipboard API specification to mandate one behavior or 
another.  It's something each browser vendor should be able to decide.

- R. Niwa

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

[Paul Libbrecht]

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 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 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 
> after a user's click or keypress.  :(
> 
> Thoughts?
> 
> 
> Sincerely,
> James Greene
> http://jamesgreene.net/

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

[James Greene]

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 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 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
after
a user's click or keypress.  :(

Thoughts?


Sincerely,
James Greene
http://jamesgreene.net/