W3C home > Mailing lists > Public > www-tag@w3.org > June 2010

Re: Copy to Clipboard - ambush and abuse by javascript

From: Nathan <nathan@webr3.org>
Date: Wed, 02 Jun 2010 23:26:35 +0100
Message-ID: <4C06DA9B.2050000@webr3.org>
To: mike amundsen <mamund@yahoo.com>
CC: Noah Mendelsohn <nrm@arcanedomain.com>, Tim Berners-Lee <timbl@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
mike amundsen wrote:
> One possible solution is to engineer user agents in a way that will
> prevent the "copy" action unless the content/context contains the
> proper rights metadata (via Creative Commons or some other agreed
> standard(s)).

and creative commons are offering $10k grants at the minute for just 
this kind of research and work [1] - could be very interesting for 
somebody to look at.

[1] http://wiki.creativecommons.org/Grants

> I think that is compatible with the spirit of CORS, UMP, PICS/POWDER,
> etc. where it's the responsibility of the content author//host to
> explicitly "enable" the possibly "harmful" user agent action and the
> responsibility of the user agent to prevent that same action unless
> specific meta data is provided.
> 
> mca
> http://amundsen.com/blog/
> http://mamund.com/foaf.rdf#me
> 
> 
> 
> 
> On Wed, Jun 2, 2010 at 17:51, ashok malhotra <ashok.malhotra@oracle.com> wrote:
>> Let me argue the other side.  If I make my living serving copyrighted
>> content, allowing
>> unrestricted copy/paste is handing out a license to steal/plagiarize.  So,
>> how do I protect myself?
>> -- disallow copy? add a hidden watermark that can be used for legal
>> prosecution?
>> All the best, Ashok
>>
>>
>> Noah Mendelsohn wrote:
>>> Tim Berners-Lee wrote:
>>>
>>>> This I think seriously violates the function
>>>> of Copy, and the user's rights.
>>> Yes, I agree completely.  It's obnoxious, unhelpful, and contrary to the
>>> spirit of the platform specifications for copy/paste.
>>>
>>>> Should browsers ensure that Copy is always a
>>>> read-only operation, unless they have INSTALLED code to do something
>>>> different?
>>> I agree with the spirit of what you're asking for, but I'm not sure the
>>> words "read-only" capture the essence of what's needed.  Copy is, of course,
>>> an operation that identifies data for transfer, and the corresponding paste
>>> is necessarily an update operation on the target document or system.
>>>
>>> My deeper concern is that in fact certain sorts of data manipulation are
>>> expected and useful, particularly when doing format conversions as part of
>>> copy/paste.  So, for example, if I am reading an HTML document and I select
>>> multiple paragraphs of text, it might well be appropriate for a copy
>>> operation to put at least two versions on the clipboard:
>>>
>>> HTML Clipboard format:
>>> <p>Text of para1</p>
>>> <p>Text of para2</p>
>>>
>>> Text Clipboard format:
>>> Text of Para 1\n
>>> \n\n
>>> Text of Para 2
>>>
>>> I think it's important that whatever rules we set for browsers not
>>> prohibit such helpful re-expression of the same information using different
>>> formats.  We need to find a formulation that encourages such useful
>>> reformatting, but prohibits the sort of inappropriate updates that are
>>> described in the Daring Fireball posting. In any case, it doesn't seem to me
>>> that the term "read-only" quite captures what we want.  Thank you.
>>>
>>> Noah
>>>
>>>
>>>
>>>
>>>
>>> Tim Berners-Lee wrote:
>>>> Example on MSNBC:
>>>> http://today.msnbc.msn.com/id/29875493/ns/today-green/
>>>> Very frustrating -- but a violation of the user interface.
>>>>
>>>> It is discussed by John Gruber on:
>>>> http://daringfireball.net/2010/05/tynt_copy_paste_jerks
>>>>
>>>> "the site uses JavaScript to report what youíve copied to an analytics
>>>> server" when you perform a copy.
>>>> This I think seriously violates the function of Copy, and the user's
>>>> rights.
>>>>
>>>> Should browsers ensure that Copy is always a read-only operation, unless
>>>> they have INSTALLED code to do something different?
>>>>
>>>> Tim
>>>>
>>>>
>>>>
>>>>
>>>>
>>
> 
> 
> 
Received on Wednesday, 2 June 2010 22:27:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:06 UTC