Re: CfC: new WD of Clipboard API and Events; deadline April 5

Le 7 sept. 2011 à 09:43, Hallvord R. M. Steen a écrit :
> What helps "average" users is IMO mostly a UI question ;-)
> 
> I'd predict that this will be handled much like popup windows. They became a nuisance for users, so UAs evolved to develop popup blocking, various types of UI for opt-in enabling et cetera. If clipboard event abuse becomes a severe enough problem, UAs will respond. Also, nothing stops UAs from giving the user opt-in measures before enabling this functionality in the first place, and some UAs already have opt-in mechanisms when scripts want to use the OS clipboard that could or should be extended to also enable/disable clipboard events. Doing this in a user-friendly way is a fair playing field for UAs to compete on, and not something we should figure out now and put in the spec.

I'd like to agree but we have to be a bit more nuanced.
I think we should avoid the historical errors of MSIE. Though I may have a biassed view of history, here's how I see that.

The MSIE API for clipboard has been there since IE 6, long long long ago. But it was very quickly pointed to as a very evil feature (allowing web-pages to read clipboard without asking) and became limited to "trusted sites"; it was not really made useful.

By now, we know how to avoid the aforementioned problem but there are suspicions of other problems.

If we do not convince someone like Glenn, we run the risk of the same failure, so we have an interest to do so.

Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit :
> 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 said earlier, the "fiddle" is expected to be useful... we can't remove it.

To the risk of an annoying clipboard service of the web page, I would propose the solution of Jonas Sicking: a "copy text command" (CTRL-SHIFT-C maybe?) that would ignore the scripts.
I note that it's not the spec's job to specify such.  It's the job of informal material around the spec, such as this list, to suggest workarounds to recognized risks.

paul