New windows stealing focus -- and passwords?

We all survived for many years with window managers which allowed applications to steal focus, and most other window managers still work that way, so I don't consider this a serious vulnerability.

That said, the focus stealing prevention in metacity is working fine for me in both dapper and edgy.

Not always.

Steps to reproduce it not happening:

1) Open a window in some program.

2) Open a window in some other program by clicking on a toolbar launch script or something.

3) Move you mouse back over the first window.

4) Note that the second window does *not* take focus.

I suppose you're suggesting that the right thing to do is only give focus to the new window if it was requested by the user?

By the way, Windows has had this same "vulnerability" for years. When you start talking to somebody on AIM, sometimes they send you part of a message they started typing to somebody else.

So your argument is that if a vulnerability has been there for long enough (or affects another OS), it's OK to leave it there? If a user want to be affected by that, it's his/her choice, but the sane behaviour should be the default. Or, in the minimal case, applications that can be "controlled" remotely (e.g. IM, web browser, IRC client) should *never* grab focus by default. It's just asking for (remotely exploitable) trouble.

As to whether it's a good idea to automatically give focus to a window that was explicitly requested by the user, I guess it's debatable. I personally think it's dangerous, especially when your machine is slow because you can open a terminal, not seeing it come up for several seconds (I've seen minutes for a machine swapping heavily) and then go back to another terminal. When the terminal you tried opening shows up, it'll get whatever text you were typing at the moment. Technically, that part wouldn't be a security issue because the worst you can do is deleting your home directory ("rm -rf" ending up in the wrong terminal window) but nodoby can remotely get you to do that.

BTW, I tried:
gconftool-2 --set /apps/metacity/general/focus_new_windows --type string strict
as suggested by another user and it didn't change anything. Any new window I open still grabs the focus.

Things have been done this way for many, many years. This attack vector, such as it is, has been obvious since day one. Have you ever heard about it being exploited?

Ubuntu needs to be secure, yes, but secure against real threats, not movie plots.

Have you ever typed your password in clear in another window that just opened? I have -- several times. Usually, it just goes into a "local" window and only the people around me could see it (which is bad already), but I don't see why it couldn't happen accidently or deliberately through IM or a web browser. We're not talking movie plots -- accidents are bound to happen and I'm sure have happened in the past because of that. In terms of "remote exploit", it sure wouldn't be that hard to have a script automatically IM when they attempt to log in. Still requires knowing the person, but it's certainly not a good thing. The chances of succes would probably be in the order of 1-5%: small, but significant if you try several times. Put another way, would you feel safe telling me what your IM nick is and giving me an account on a machine you often ssh to with a password (not ssh key)?

It's not like I'm advocating removing a feature or drastically changing anything, just changing the default to something a bit more sane. Stealing focus by default is just plain stupid. It's also totally counter-intuitive when you have the "focus follows mouse" or "sloppy" focus policy because you end up with the focus not going to the window that has the mouse in it. So even if it weren't a general hazard, it would still be the wrong behaviour for sloopy/follows mouse focus.

So basically, I see many reasons for fixing it and not many for leaving it is (except for "everybody else is doing it").

Metacity tries to avoid focus stealing, and usually it is quite successful in that, at least for me. However, one offender that I notice is gaim. When I receive a message, the gaim window pushes itself to the foreground and grabs the focus, regardless of what I am doing (this even happens if I play a movie fullscreen).

What I am trying to say is, that this doesn't seem to be a general nautilus issue, but rather an application-specifig bug (like one in gaim)? Which particular application does not work correctly for you?

> that this doesn't seem to be a general nautilus issue

I assume you meant "metacity issue" here. I think there must be some soft of confusion in here. On all three Dapper machines I have, I have yet to see a *single* case of a window opening *without* getting focus. Click on the panel to open a terminal? New terminal opens with the focus. I type "xterm" in an existing terminal, a new xterm opens with focus. Start any application, either from the panel of from a terminal command line? It comes up with focus. Gaim does that too, so does firefox, *everything*. Even if I try setting metacity to "strict" focus. It seems like I am not the only why seeing that (see bug #51242), so the only thing I don't understand is why you don't seem to see that. Comes down to two options: 1) we're talking about something different or 2) somehow the problem is triggered by some combination of config options.

Hi,

jmspeex [2006-08-01 5:18 -0000]:
> > that this doesn't seem to be a general nautilus issue
>
> I assume you meant "metacity issue" here.

*blush* of course, sorry.

> I think there must be some
> soft of confusion in here. On all three Dapper machines I have, I have
> yet to see a *single* case of a window opening *without* getting focus.

Maybe we do talk about different issues here. If you are currently
typing, then new windows do not get the focus. However, they do get
the focus if you didn't type anything in the last second or so. I. e.
the behaviour tries to avoid suddenly typing stuff into another
window, but if you merely use the mouse to start an application, the
new window will have the focus. I just tried it again (with something
like 'sleep 5; nautilus' and typing (or not) in another terminal).

Can you please confirm that this doesn't work for you?

For the record, I do not consider this as an 'Oh my god, the sky has
fallen' bug, but focus stealing is annoying and dangerous enough to
make sure it gets eventually fixed. If there is a problem in dapper,
we need to judge the patch complexity whether or not we will fix it in
dapper.

Funny, doing the 'sleep 5; nautilus' *and* typing in another window is the first case of things (sort of) behaving correctly. Any process other than nautilus steals the focus. If I try the same with xterm, gnome-terminal, konsole, gimp, ... the new window steals the focus. Clearly, it should be the WM's responsability to enforce sane focus policies, or else we'll end up filing thousands of upstream bugs. Even if it worked, one second timeout isn't very useful because it typically takes more than that between the time you type "ssh remote.machine.net" and the time you type your password.

One thing I would like to point out. A new "feature" in Dapper is that when starting up an config tool that requires the admin password (e.g. update manager), then the screen goes dark to prevent other windows from opening (and steeling focus) at the same time. Why is it considered that the admin password is worth protecting, but not my ssh password, or my gpg password, ...?

Because your admin password can be immediately used to compromize your computer, whereas your ssh or gpg passwords may or may not be used that way.

However, if you type 'sudo' in the shell, it does not protect your admin password in such a way.

I still think this isn't a bug. It might be a feature request, but I would never support it as one either.

> Because your admin password can be immediately used to compromize
> your computer, whereas your ssh or gpg passwords may or may not
> be used that way.

I would argue the opposite. The sudo password is *by default* useless because ubuntu doesn't install a local ssh server by default. Your outgoing ssh password (on the remote machine) on the other hand can almost always be exploited.

> However, if you type 'sudo' in the shell, it does not protect your admin
> password in such a way.

So by this argument we should go for consistency and make sure that all apps support the "password can be stolen" feature in the same way, i.e. remove the shading/blocking of the display when config tools ask for the admin password?

> I still think this isn't a bug. It might be a feature request, but I would
> never support it as one either.

No matter how you look at it, it *is* a bug. Even if you don't care about sensitive info being released, the fact remains that:
1) giving focus to a new window breaks the "focus follows mouse" rule if you have it selected (the focus is given to a window that isn't under the mouse pointer).
2) The gconf option to disable the auto-stealing has no effect, so I'm stuck with that bad behaviour even if I'm willing to dig up gconf-editor.

Last thing, may I ask what would be so bad with metacity doing the right thing and not letting any new window steal the focus?

when you open a new folder with nautilus spatial or an application from the panel menu you probably want them taking the focus instead of having the previous nautilus window of the panel keeping it

The consistency issue is a a bug but that's a different topic of the one discussion initially here so please use a new bug for it so the discussion can be kept on track

> when you open a new folder with nautilus spatial or an application
> from the panel menu you probably want them taking the focus
> instead of having the previous nautilus window of the panel keeping it

This may (or may not) be handled as an exception to the "don't steal focus" rule. Even then, it would be wrong when the user selects "focus follows mouse". It's called "focus follows mouse", not "focus follows mouse, except what a window feels like it should get focus".

But at this point, nautilus is actually the only app that (in some circumstances) doesn't steal focus. Still, I see no reason justifying that a window opening unpredictably (e.g. error message, web popup, IM popup) automatically gains focus.

> The consistency issue is a a bug but that's a different topic of the one
> discussion initially here so please use a new bug for it so the discussion
> can be kept on track

The consisteny issue is about having consistent *security* behaviour. I can't see why some passwords are deemed more important than others.

Le mercredi 09 août 2006 à 16:01 +0000, jmspeex a écrit :

> The consisteny issue is about having consistent *security* behaviour. I
> can't see why some passwords are deemed more important than others.

I didn't they that was not a bug, I just wrote that is was not the same
issue than the focus issue initially described so it could use a
different bug, any issue with that?

 unsubscribe ubuntu-security

Personally, I'm less concerned about the potential security issue than with the general user-interface problems the lack of strict mouse-focus produces. Examples I've experienced:

* I have a data analysis package that creates about a dozen windows, at a rate of around one every 2 seconds. The focus-stealing by these output windows (which display plots of data) means that the input is effectively disabled (e.g., I can't be typing in a terminal) for an extended period of time while this happens. Ugh.

* If I'm typing in some app, e.g., a text editor, and a dialog box (e.g,. a mail notification, battery status, calendar event, etc.,) pops up and gets focus, there is a strong chance that the dialog will be dismissed before I even realize it was there, let alone decide what the appropriate choice is. Oops! This is especially true since most dialogs have a default choice which is activated when the spacebar is pressed. In typical typing, every ~6th character is a spacebar.

* Sometimes I want to close a bunch of windows by pointing the mouse at them and hitting Alt-F4. I've more or less given up on doing this, though, because sometimes when one window is closed, the focus switches to some window other than the one under the mouse, and if I don't notice immediately I close that window instead of the one I wanted to. Oops!

* Sometimes I'm running a commandline app that generates output windows. Typically these output windows do not process keystrokes or mouse events. However, the do get the focus when they are created, so every time I create one from the terminal, I need to wave the mouse off the terminal and back onto it before I can continue working. Yuck.

Generally, it's simpler and more intuitive to tell a new user, "point the mouse at a window and type into it" than "point the mouse at a window and type into it, unless a new window has been created, in which case your typing will go to that one, unless the window manager has decided not to move the focus for some reason, so really you need to wave the mouse around and then point it into the window you want to be typing into every time the window manager does something". Yes, it's sometimes convenient to have the focus go to a newly-created dialog ***which is a child of the app that currently has focus*** , but the cost of that minor convenience seems excessive if it means the focus will go to (almost) every newly-created window.

Many of the Metacity themes use only subtle visual indicators of window focus, e.g., the colors of the titlebar buttons or text. This makes it especially important not to surprise the user by changing the focus without being explicitly requested to. (As it stands, I always pick window frame themes that make large, obvious changes to the titlebar and border colors to partly work around the Metacity behavior).

I totally agree. What I don't get is that there's simply no logical justification to the current behaviour (at least when "focus follows mouse" is selected), yet they still don't want to change it. Sure, maybe Windows does it like that, but Windows doesn't have "focus follows mouse" either. Two minutes ago, I again accidently typed my ssh password in a newly open window. Fortunately, that window was from a "local" application (thunderbird), but it's only a matter of time before I get screwed by that. Would anyone who disagrees with fixing the problem care answering these simple questions:
1) Why would anyone want newly open windows to take focus?
2) Why would anyone want that to happen when "focus follows mouse" is selected?
3) Why should that even be enabled by default?
4) Why should there be no way to even disable the "feature"?

>> The consisteny issue is about having consistent *security* behaviour. I
>> can't see why some passwords are deemed more important than others.
>I didn't they that was not a bug, I just wrote that is was not the same
> issue than the focus issue initially described so it could use a
> different bug, any issue with that?

OK, so I've followed your advice and filed Bug #62893 to have the password security feature of the update-notifier applet removed for consistency reasons (because metacity stealing my ssh password seems to be considered as an important feature).

I agree with Koresko's points. Especially with the part where you accidentally close unread dialogs by continue typing whatever you were about to type without noticing the dialog in the first place. This has happened to me a lot of times before. The same holds for typing ssh-passwords into newly created windows.

I really like the sleep 5;xterm example. This is a thing that should definitely be addressed by the window manager. I see no situation where it would be desirable to steal focus while the user is typing. I think that one second should be enough for most cases when not using "focus follows mouse".

I agree with the others that focus should never be stolen when "focus follows mouse" is enabled, though.

Well actually, that depends. I would like modal dialogs to steal focus from the application I'm working on even if focus follows mouse.

But other applications' dialogs shouldn't steal focus.

Yes, that would make sense because if it's a modal dialog, you can't type in the main application window anyway. That's the only case I see where "stealing" the focus is OK, and it's not really stealing because that's what a modal dialog does *by definition*.

The only question remaining is what would make sense when a new window opens right where the mouse is currently located (assuming focus follows mouse). My best guess would be to not give it focus until the mouse moves.

[Expired for metacity (Ubuntu) because there has been no activity for 60 days.]