Re: Copy to Clipboard - ambush and abuse by javascript

"messing with the clipboard" is not exactly what is intended, for  
sure! And messing with the clipboard did happen in some leak-full  
versions of the MSIE API, which made it quite unstable: any web page  
could read the clipboard then which is now recognized as fully wrong.

All contemporary specifications of a web-page-enhanced clipboard  
transfer, I believe, now take in account that the *standard gesture*  
is the only one expected to be used by the user to copy and only then  
could help the user by adjusting the content and the association  
between types and map before this gets written to the clipboard.

A user expecting a near-desktop experience in a web-application that  
provides many services will find it normal that his clipboard is full  
of... useful data. E.g. that a web-based SVG editor puts a PDF variant  
into it so that he can paste that into his word-processing desktop  
application.

paul

Le 15-juin-10 à 04:37, David Booth a écrit :

>>>> The ability to manipulate what a user is copying is also important
>>>> for applications on the Web.  If you're using a Web app like Google
>>>> Docs, you want copy to copy a useful representation, not the
>>>> internal representation that the editor uses.
> So perhaps the question should be rephrased as asking whether a
> *website* should be able to control copy and paste, rather than  
> whether
> *javascript* should permit it.  Just as some operations are safe and
> others are unsafe, and unprivileged websites should not be permitted  
> to
> perform unsafe javascript operations, it seems to me that the  
> ability to
> mess with the copy buffer should be considered an unsafe (privileged)
> javascript function.
> Actually, even the ability of a website to observe copy *events* seems
> to me like an invasion of privacy.