Not really a big issue...

Story: Old tricks are new again: Dangerous copy & pasteTotal Replies: 24
Author Content
AwesomeTux

Apr 17, 2013
2:20 AM EDT
Just check what actually got pasted before hitting enter.
Ridcully

Apr 17, 2013
2:35 AM EDT
Fine......I nearly got suckered yesterday though. I use a Telstra connection and received an email which was built to look exactly, and I mean EXACTLY, like the email Telstra sends out to notify you of your monthly bill. I opened the link and saw it required me to put in my sign in details and instantly closed the web site....Then I went back and took a closer look at the email........Ye very clever phishing attempt.......Telstra NEVER requests such information; why should they ? They already have it....

But one does wonder how many other unthinking innocents, who weren't astute enough to realise what was going on, got suckered. If you could catch this person, put me in line to have my go at flogging their backside with six of the best.....I feel rather "physical" over these rotten mongrels.....pardon my language, but I get angry.
Bob_Robertson

Apr 17, 2013
10:55 AM EDT
I've noticed this used "benignly" when I copy quotations. Some of the quotes sites add their name and URL to the pasted text.

Yuck.
Bob_Robertson

Apr 17, 2013
11:32 AM EDT
The H demo of it is very interesting:

http://www.h-online.com/security/services/Copy-Paste-Tricks-...
rnturn

Apr 17, 2013
11:54 AM EDT
When I receive an email from a site that contains links that I can follow, I always hover the mouse over the link to see where it'll take me. But... that's only for the emails that I haven't already Ctrl-clicked into a list that I then delete without even viewing. Like emails supposedly coming from a site that I have no current business relationship with (like emails from "shipping companies" requesting personal information when I haven't ordered anything online in months) or entities that would never send me emails (like the IRS).
Fettoosh

Apr 17, 2013
12:14 PM EDT
Quoting:Just check what actually got pasted before hitting enter.


I don't know if this would always work since a hidden text/commands could included line break as indicated in the article.

Quoting:The command sequence also includes line breaks which the command-line shell interprets as if the user had entered a confirming return key


It would be better to inspect the source using right click => Inspect-Element in Chrome or similar tool in other browsers.

gus3

Apr 17, 2013
12:46 PM EDT
Or NoScript.

BTW, you've disabled "set arbitrary status bar text" in your JavaScript permissions, right?
notbob

Apr 17, 2013
2:53 PM EDT
gus3 wrote:BTW, you've disabled "set arbitrary status bar text" in your JavaScript permissions, right?


I'm running NoScript. I'm also running Seamonkey 2.1b3 and all I see referencing "status bar text" in my javascript permissions is "change status bar text" . Should I leave it unchecked?

The help page for this feature reads:

Change status bar text: Allows status bar text to be changed, such as in scrolling text in the status bar.
BernardSwiss

Apr 17, 2013
8:32 PM EDT
Quoting: Just check what actually got pasted before hitting enter.


That's already too late (and you might not even see any sign that something unexpected has happened)

But pasting into a text-editor first should give you a good look.

Try the link posted by Bob_Robertson http://www.h-online.com/security/services/Copy-Paste-Tricks-... That gives a simple (but harmless) example. Which will confirm what I'm saying, so you needn't take anybody's word for it.
AwesomeTux

Apr 17, 2013
11:18 PM EDT
Quoting:I don't know if this would always work since a hidden text/commands could included line break as indicated in the article.
Quoting:That's already too late (and you might not even see any sign that something unexpected has happened)

But pasting into a text-editor first should give you a good look.

Try the link posted by Bob_Robertson http://www.h-online.com/security/services/Copy-Paste-Tricks-... That gives a simple (but harmless) example. Which will confirm what I'm saying, so you needn't take anybody's word for it.


Hmm, yes, pasting in the terminal would already be too late. Checking what gets pasted in a text editor first would be best.

Sounds to me like Mozilla (and Google?) need to change how text is copied, or rather how hidden/off-screen text shouldn't get copied. I really don't see any reason why essentially hidden elements should get copied.
Bob_Robertson

Apr 18, 2013
8:43 AM EDT
> Sounds to me like Mozilla (and Google?) need to change how text is copied, or rather how hidden/off-screen text shouldn't get copied.

So in the X environment, is it the application itself that handles the "copy to clipboard" function, or is it X?

I miss my three-button mouse, the "highlight then middle-click" copy-paste function is wonderful.
jdixon

Apr 18, 2013
8:45 AM EDT
> I miss my three-button mouse, the "highlight then middle-click" copy-paste function is wonderful.

One of the things I really miss when I'm stuck on a Windows machine at work. It's also nice that the highlight buffer isn't the same as the copy/paste buffer (at least not on Slackware), so you can have two things to be pasted at once.
AwesomeTux

Apr 18, 2013
11:08 PM EDT
Quoting:So in the X environment, is it the application itself that handles the "copy to clipboard" function, or is it X?


I couldn't tell you.

If I had to guess, I'd say it's handled by X via the application using X's API, and options like "Input Methods" are handled by whatever desktop environment you're using. Once upon a time, Firefox had an annoying bug that caused clipboard contents copied from within Firefox to be lost after closing Firefox. So I know Firefox has a role in how copying text works.
mrider

Apr 19, 2013
9:40 AM EDT
Quoting:So in the X environment, is it the application itself that handles the "copy to clipboard" function, or is it X?
In X, an application tells the X server that it "owns" the selection (aka clipboard) based on some action (e.g. Ctrl+c). This ownership is timestamped. When another application says "I want the contents of the clipboard", X asks the program with the newest time stamp to provide that data. The selection owner provides a list of the types of data the selection can be - e.g. text, image binary, etc., and if the requester and owner agree on a type, the owner provides the data to the requester. X does nothing more than arbitrate. (This is somewhat paraphrased and simplified)

An easy way to see this in action is to use X in an environment which has no clipboard manager. Select and copy something to the clipboard, and then immediately close that application. Now try to paste the data into another application. It won't work. It only works if you have a clipboard manager program of some sort. That's because the clipboard manager monitors the clipboard queue and jumps in immediately after any program claims the selection. It asks for the data, and then sets it as it's own selection so that the original program is no longer part of the equation.

Quoting:If I had to guess, I'd say it's handled by X via the application using X's API, and options like "Input Methods" are handled by whatever desktop environment you're using. Once upon a time, Firefox had an annoying bug that caused clipboard contents copied from within Firefox to be lost after closing Firefox. So I know Firefox has a role in how copying text works.
That's not a Firefox bug. That's X working the way it works. If you no longer have that problem, then either a) Firefox spawns a separate invisible window for the clipboard contents (which is how I always do it), or b) you have a clipboard manager now and didn't before.



Back to the original post - the thing I find interesting is that I never really knew about this particular "vulnerability", but it's never mattered to me. I don't see how people can be so precise with their mouse selections :) . I've ALWAYS pasted to a text editor first, for the simple reason that I almost always have problems getting all the text I want and only the text I want. Far too frequently I get the trailing line end, or I don't get the first few characters, or whatever.
Bob_Robertson

Apr 19, 2013
11:11 AM EDT
> (This is somewhat paraphrased and simplified)

Many thanks! Fascinating.

mrider

Apr 19, 2013
11:44 AM EDT
Quoting:I miss my three-button mouse, the "highlight then middle-click" copy-paste function is wonderful.
Most mice have the middle-click function attached to the scroll wheel. Try pushing straight down with the scroll wheel - assuming you have one of course.



Going back to what I said about the clipboard: That points out a trade-off one makes when making an X program clipboard aware, namely what to do when the program closes. I don't know of an easy way to tell if there's a clipboard manager, so I always assume there isn't one. So now I have two choices:

1) Lose the contents of the selection when the main program closes. Most people would see this as a bug as did AwesomeTux, and most people find this behavior surprising. I don't do this, but lots of programs do.

2) Don't hold the contents of the selection in the main window. Instead, fork a thread that has a life of its own. Put the contents of the selection there, and run the thread in a tight loop that supplies the contents of the selection when requested, and exits when another program claims ownership of the selection.

The advantage to the second version of course is that it acts less surprising to those that expect the selection to live past the program closing. But the disadvantage is that users often think the program has a resource leak. "I closed your program, but it's still running! What's wrong?" The answer of course is that the program still owns the selection. To fully close the program you need to put something else on the clipboard. Depending on the size of the clipboard contents and how it's stored (i.e. is it spooled off to disk), it can look as if the program is holding a large amount of memory open.



So next time you see this behavior, you'll understand why. :)
Bob_Robertson

Apr 19, 2013
11:54 AM EDT
> Most mice have the middle-click function attached to the scroll wheel

I'm aware of that. The wheel tends to get turned, however, ruining the paste point.

Thus, "I miss my three button mouse" which had no annoying scroll wheel.
mrider

Apr 19, 2013
11:58 AM EDT
Quoting:I'm aware of that. The wheel tends to get turned, however, ruining the paste point.

Thus, "I miss my three button mouse" which had no annoying scroll wheel.
Ah yes. Agreed.

BernardSwiss

Apr 19, 2013
12:34 PM EDT
Shall we talk about laptops and touchpads, now?
jdixon

Apr 19, 2013
12:54 PM EDT
> Thus, "I miss my three button mouse" which had no annoying scroll wheel.

It's somewhat of an acquired taste, but this is my favorite mouse: http://www.newegg.com/Product/Product.aspx?Item=N82E16826104...

Yeah, it's really a trackball, not a mouse, but Logitech insists...

> Shall we talk about laptops and touchpads, now?

It's a family friendly forum. We'd probably best not. :)
CFWhitman

Apr 19, 2013
2:08 PM EDT
@jdixon: I have one of those Marble Mouse trackballs. I use it for playing games on my laptops. I think for the desktop I might miss the scroll function (on my laptops I use the touchpad to scroll even when I'm using the Marble Mouse for everything else).
AwesomeTux

Apr 19, 2013
11:29 PM EDT
Quoting:That's not a Firefox bug. That's X working the way it works. If you no longer have that problem, then either a) Firefox spawns a separate invisible window for the clipboard contents (which is how I always do it), or b) you have a clipboard manager now and didn't before.


It had to have been a Firefox bug, since every other program worked just fine during that time. I often open Leafpad to write something and once I need to add HTML or PHP or something I copy everything, close Leafpad, open gEdit and paste, that worked. While opening Firefox to look up an HTML tag or PHP function, copying such, closing Firefox and pasting to gEdit never did.
notbob

Apr 20, 2013
7:03 AM EDT
Fettoosh wrote:It would be better to inspect the source using right click => Inspect-Element in Chrome or similar tool in other browsers.


In Mozilla-based browsers, highlight text, then cursor-menu (right click) "View selection source".

Thank for that tip, Fettoosh.
mrider

Apr 20, 2013
10:43 AM EDT
Quoting:It had to have been a Firefox bug, since every other program worked just fine during that time. I often open Leafpad to write something and once I need to add HTML or PHP or something I copy everything, close Leafpad, open gEdit and paste, that worked. While opening Firefox to look up an HTML tag or PHP function, copying such, closing Firefox and pasting to gEdit never did.
I don't wish to be argumentative, that's not my style, so I won't go any further with this - but again, that's the way X works. No doubt the problem was one of interaction in your environment. There was probably something about Firefox at that time that's different now such that you no longer have that problem. But X definitely does not store the content.



I'm running XFCE on Debian stable (soon to be legacy w00t). I have no clipboard manager. My Iceweasel version is 20.0 since I have a backports repository, which means I'm slightly behind the curve, but not much.

Right now, today, if I select text in Iceweasel and copy it to the clipboard and then paste into Mousepad without closing Iceweasel, all is well. If I select text in Iceweasel and copy it to the clipboard and then close Iceweasel, then I get nothing in Mousepad when I try to paste.

I know that you're saying Firefox and I'm saying Iceweasel, but I don't imagine that Iceweasel and Firefox are that different.

I don't know what your environment is like. What GUI you use, whether or not you have a clipboard manager, or what. But again, X does not store the information. It may very well be that there's something different in Firefox now from then such that it no longer works that way for you. Maybe Firefox didn't interact well with whatever is managing your clipboard in your environment. I can't say.
AwesomeTux

Apr 21, 2013
5:17 AM EDT
Quoting:I don't wish to be argumentative, that's not my style, so I won't go any further with this - but again, that's the way X works. No doubt the problem was one of interaction in your environment. There was probably something about Firefox at that time that's different now such that you no longer have that problem. But X definitely does not store the content.


Oh, I didn't mean to be arguing against you. I'll just end on this: It would be likely that Firefox was merely unable to interact correctly with the available clipboard manager before, meaning either Firefox had a bug, or the clipboard manager did.

Quoting:I'm running XFCE on Debian stable (soon to be legacy w00t). I have no clipboard manager. My Iceweasel version is 20.0 since I have a backports repository, which means I'm slightly behind the curve, but not much.

Right now, today, if I select text in Iceweasel and copy it to the clipboard and then paste into Mousepad without closing Iceweasel, all is well. If I select text in Iceweasel and copy it to the clipboard and then close Iceweasel, then I get nothing in Mousepad when I try to paste.

I know that you're saying Firefox and I'm saying Iceweasel, but I don't imagine that Iceweasel and Firefox are that different.

I don't know what your environment is like. What GUI you use, whether or not you have a clipboard manager, or what. But again, X does not store the information. It may very well be that there's something different in Firefox now from then such that it no longer works that way for you. Maybe Firefox didn't interact well with whatever is managing your clipboard in your environment. I can't say.


I use Debian and GNOME. And if I had to guess, the problem stopped when I upgraded to GNOME 3 as it became available in the Testing repository. But I don't know for sure.

However, whether X stores the clipboard information or not really doesn't have much to do with what I was saying about Firefox having a role in how text is copied.

For example, the fact that Firefox has its weird multi-selection feature (select text, hold Ctrl and select more text somewhere else on the page), proves that -- too some extent -- they already control how text may be selected. Firefox should behave in a way that hidden or off-screen elements aren't ever sent to the clipboard or X or whatever, by simply not allowing them to get selected unless visible on page.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!