Re: riks of the new clipboard operations API (was: Re: CfC: new WD of Clipboard API and Events; deadline April 5)

Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit :

> On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht <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.
> 
> (As an aside, it would still be possible to do this sort of clipboard hijacking even if that was done, by fiddling with the selection when the selection change happens instead of waiting for the copy.  From my experiments, though, that approach is much more brittle, which is a deterrent in and of itself.)
> 
> We can't stop pages from being annoying, but we should definitely keep in mind the annoying things that are actually being done in the wild today, and be aware of the things a new API might exacerbate.
> 
> -- 
> Glenn Maynard
>