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

We've seen people who abused hidden style to smuggle evil shell
commands into seemingly innocuous shell instructions.

When pasting text into a word processor, one generally gets a
functional preview of the results. When pasting into a shell, things
are typically executed immediately sans preview.

Now, there are solutions, kinda. Instead of copying directly to the
clipboard, you can provide a number of "flavors" on the clipboard,
with the default being WYSIWYG and another being "what the tool
offered". Office apps and web browsers could let users select the
alternate flavor. "Simple" apps should get the WYSIWYG flavor. We only
recently fixed the css hidden clipboard bugs.

On 9/5/11, Glenn Maynard <glenn@zewt.org> wrote:
> 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.
>
> 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
>

-- 
Sent from my mobile device

Received on Wednesday, 7 September 2011 07:36:02 UTC