Re: riks of the new clipboard operations API

On 9/5/11 10:49 PM, Paul Libbrecht wrote:
>
> Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit :
>
>> On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht <paul@hoplahup.net 
>> <mailto:paul@hoplahup.net>> wrote:
>>
>>     Slowly, users start to see the disadvantages of a dirty web-page
>>     (e.g. flash advertisement 100% cpu) and I am confident they will
>>     not that some pages mingle with their copy ability or actually
>>     provide a service to do so.
>>
>>
>> Sorry, I'm having trouble parsing this.
>>
>> My experience so far is that people are aggravated by pages that 
>> insert ads into copied text, but not quite enough to stop them from 
>> using a page.  They grumble and delete the ad.  That's the most 
>> annoying category of abuse, in my opinion: not bad enough to strongly 
>> discourage its use, causing it to spread, but bad enough to 
>> continuously annoy users.
>
> They will provide feedback and/or prefer sites that do not do that.
> The offer is diverse enough for this.
> That's what the paragraph above says.
>
> I agree that the API indeed brings in new possibilities of abuse and 
> new utilities, they cannot be discerned except by an end user.
>
> You are are right we need to be aware of the risks.
>
> The tracker injection is, to my taste, relatively mild.
> Hidden anchors would be considerably worse.
>
> paul
>
>
>>
>>     I'd love to hear your feedback but that's how I feel things and I
>>     think we just have to accept it: new technology, new risks,
>>     positive and negative.
>>
>>
>> It's acceptable for new technologies to have negatives, of course; 
>> the positives need to balance the negatives.
>>
>> To be clear, I don't mean that this abuse is newly exposed by this 
>> API.  It's an abuse that's been spreading lately, using hacks with 
>> existing APIs.  I meant that it shows that people will broadly abuse 
>> anything that lets them fiddle with the clipboard; in other words, 
>> this isn't a theoretical problem.
>>
>> I'd hoped to see browsers adjust behavior so clipboard copying 
>> happens before anything else (before firing DOM events at all), 
>> making it more difficult for pages to fiddle with the selection 
>> before the copy occurs, but this API makes that approach useless; it 
>> officially blesses the entire category of 
>> messing-with-what-the-user-copies, so it'd never be fixable.  That's 
>> frustrating.

I've seen licensing contracts which require clipboard operations to be 
obfuscated. I think they are wrong-headed, but the licensing issue 
results in sites which need to obfuscate their source code through 
IFRAME and other such measures.

Licensees working with such a contract -may- have an argument for 
staying away from various obfuscation methods, if they can claim that 
view-source, copy/paste and print, are disabled for typical web users.

Media selectors make the disabling of print "easy". An abuse-able, 
copy/paste mechanism works for the other issue. View-source is handled 
via xml entities / the ampersand in HTML/XML.

The positive side of this, is that authors can provide their content 
using best standards: the content can be encoded in normal HTML, it can 
be read in all browsers, and the content can be read by assistive 
technologies. On the negative side, such sites will be frustrating for 
users trying to copy, print or otherwise use content in a fair manner.

-Charles