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

>
> 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()>`
   method to write to the user's clipboard without *ANY* user interaction
   whatsoever.
      - This led to some security uproar about malicious clipboard
poisoning<https://www.google.com/search?q=flash+9+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
down<http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes.html#head31>the
`System.setClipboard` method and the [then] new `
   flash.desktop.Clipboard<http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html>`
   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 <hsteen@mozilla.com> 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
>