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

Reply via email to