Open Bug 546187 Opened 14 years ago Updated 2 years ago

Websites can hijack text copying

Categories

(Core :: DOM: Events, defect, P5)

x86
Windows Server 2003
defect

Tracking

()

UNCONFIRMED

People

(Reporter: glenn, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

Webpages are hijacking clipboard copy events to insert ads in copied text, by catching oncopy (as well as keystroke events for other browsers) and temporarily inserting a text node after the selection.

Reproducible: Always

Steps to Reproduce:
Select the text "Climategate U-turn as scientist at centre of row admits: There has been no global warming since 1995", and copy it to the clipboard.

Actual Results:  
This text is copied:

"Climategate U-turn as scientist at centre of row admits: There has been no global warming since 1995

Read more: http://www.dailymail.co.uk/news/article-1250872/Climategate-U-turn-Astonishment-scientist-centre-global-warming-email-row-admits-data-organised.html#ixzz0fZfZPsJL"

Expected Results:  
"Climategate U-turn as scientist at centre of row admits: There has been no global warming since 1995" is copied.  The browser should copy exactly what I told it to copy, and no more.


The actual copy should happen *before* firing copy, keystroke, etc. events, so webpages aren't able to hijack or prevent copying.
Do you have an example that displays your case, because the actual result and the expected result in your case are the same.
No, it's not.  The expected result is the single sentence I selected.  The actual result is that sentence, followed by the advertisement "Read more:\n(url)".
Sorry, misinterpreted your case.
I've tried to reproduce it, but can't seem to reproduce it, so it looks to be solved in Mozilla/5.0 (Windows; U; Windows NT 6.0; nl; rv:1.9.2) Gecko/20100115 Firefox/3.6 - Build ID: 20100115144158
I had someone confirm that this still happens in 3.6 before submitting.

Do you have ABP enabled?  It may block some scripts that do this.
(In reply to comment #4)
> I had someone confirm that this still happens in 3.6 before submitting.
> 
> Do you have ABP enabled?  It may block some scripts that do this.

I disabled ABP and even renamed my hostsfile so all ads are allowed. Ghostery also isn't running.
It just reproduced for me in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6.

Note that, at least on this site, it only happens if a certain amount of text has been copied.  Copying just a few words won't trigger it; copying the entire headline will.

The script on this site is in http://tcr.tynt.com/javascripts/Tracer.js.  An un-crushed version is at http://www.huffingtonpost.com/include/lib/copy_paste.js?v=1.02.
Reproduced in:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Isn't this the whole point of the oncopy event?  To fire before the copy operation occurs?
Indeed. copy event is dispatched before copying anything.
IE has also setData method to specify data explicitly on the selection.
I don't know what the intended *use* of oncopy is, but when I select text in my browser and press ^C, the browser should copy the text I told it to copy.  Websites should not be able to override what I explicitly told it to do by injecting ads.  This is nothing but inviting abuse.  I first saw this script a month or so ago, and now it's popping up everywhere; it's maddening.

I'm having trouble thinking of a legitimate use of oncopy (the only other use I can think of off-hand is spying on what the user is copying), so I can't make any use case analysis, but in any case I'd recommend again that the actual copying happen before any events are fired, making oncopy a notification that a copy has occurred.

This should apply to all events; you shouldn't be able to spam my clipboard via keydown, either (which these scripts use as a fallback in other browsers).
I can't think of an advantage to allowing a page to view/modify my clipboard.  I can think of multiple ways to exploit it, though.

If the intent is to allow JavaScript to view/modify the clipboard the least that could be done is an additional check-box in the "Advanced JavaScript Settings" (Tools -> Options -> Content -> Advanced -> "Allow scripts to:") so that this behavior can be suppressed.

Despite whatever valid reasons there might be for doing this it's not something I ever want a Web page to be able to do.
Reproduced in the following:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
There are various legitimate reasons to want to adjust what gets put onto the clipboard, for instance, when a mail message is selected, one may want to specify the format of the html, or some alternate more readable text. Or, when copying a shape in an image editing tool, to specify the form of the data.

While the cut and copy events can be abused, note that I can think of a number of ways of creating similar abuse without using either the cut/copy events or the key events, but that wouldn't be possible to prevent.
Reproducable on Forefox 10.0 / Windows XP

http://www.gmx.net/themen/sport/sportmix/228ng4q-deutsches-trio-ist-weiter

I find it extremely annoying
Copy & Paste in the browser window should follow the WYSISWYG principle. For other cases you have "Copy Link" in the context menu.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.