Voluntary window switching inside VM

[v6ak]

steps to reproduce

1. Let's have geany and some terminal installed. (Reproducible with many other apps, though.)
2. Start geany.
3. Switch to terminal.
4. Run geany some-file.
5. Try to interact with the current window. (e.g. Alt+F for File menu or mouse right-cllick)

expected results

I would expect one of those scenarios:

a. At step 3, window is correctly switched. At step 4, user interacts with Geany.
b. At step 3, window is not switched. At step 4, user interacts with Terminal. Maybe the Geany window is trying to get attention, which is reflected in the UI in some way.

actual results

At step 3, window is not switched. At step 4, user interacts with Geany, despite the fact that Geany is seemingly not the current window. The Geany window is not trying to get the attention.

thoughts on UX and focus-stealing-related security

From user perspective, I would prefer switching the window in such case.

From security perspective, I see little or no drawbacks:

• In the scenario above, the window switch is between windows of the same VM.
• Even for inter-VM window switch (i.e. VM foo decides to switch to its window when user is interacting with bar's window), there is usually no new attack surface. The VM can simulate this by opening a completely new window (which seems to be hard to prevent without some significant drawbacks).
• The little exception: When user allows one window to use fullscreen and the window is brought to background, the voluntary window switching could be abused for some UI forgery when user does not expect it. This can be mitigated by automatic removing of the fullscreen flag at the voluntary switch.

[marmarek]

I've seen this few times, but haven't investigated details. Thanks!

Generally focus stealing prevention is a hard task - see #1166 for details. But I don't think we should abandon it completely. So in case of the same VM, the task is easy (in theory). In case of inter-VM, it isn't so obvious. Maybe it should be left for window manager decision? If no other arguments there, I think the safe default would be to deny such inter-VM switch (maybe configurable option).

I'm assigning milestone R3.1, but in practice I think we will not manage to implement this before R3.1-rc1 (so final R3.1, as it requires protocol modification).

[v6ak]

BTW, do you know the cause? I hope I know it, but I don't want to explain you my hypothesis about something you already know.

I hope it might be implemented without protocol change in some lighter version. The behavior described in expected behavior under letter b seems not to require any protocol change. It is also less considerably less confusing than the current state (at least for users who don't know the background of the issue).

---

The inter-VM case is harder than it might look, because any launching any application from dom0 (or from some domU through some RPC) will inherently look like an attempt of focus stealing. This could be prevented by some policy, which temporarily allows any focus stealing (either by opening a new window or by focusing an existing window) until at least one of following conditions becomes true:

• some timeout (30s?) elapsed (hmm, already running VM and a halted VM are maybe slightly different cases)
• the AppVM has created or focused a window
• the user has focused some other window (of some other VM?)

These three rules could be probably simplified while achieving a very similar (or even slightly better) result. The idea behind that lies in using some WIP indicator for app start. That is, when the user attempts to start an application, dom0 would immediately open a window informing about WIP. The window would be closed after first window is opened by the application. Despite being opened from dom0, the window would be considered as a window belonging to that AppVM. (Maybe it would get the same window class in order to have the same WM's rules applied.) This would have multiple benefits:

• More clear process for the user.
• No need of a timeout for temporary focus stealing permission.
• No need to cancel the temporary permission for focus stealing when user switches to another window.
• Well, no inter-VM focus stealing permission would be needed at all (because the VM would steal the focus from progress window, which is treated as a window of that VM), which seems to be a huge simplification. (=> easier implementation and lower likelihood of bugs)

There are some potential issues or tunable things (sorted by perceived importance):

• Multiple apps of the same VM starting simultaneously – in this case, it might be hard to assign what app has been started. But this seems to have been solved by Ubuntu Unity through bamfdaemon. This also seems to have been solved by Windows 7.
  • Even if not 100% correctly implemented (e.g. if any new window would close all the WIP windows for the same VM), it might be just a minor issue.
• When some app uses „close then open“ approach for windows, it would not be very nice, as the app would effectively minimize itself. However, when any attempt for inter-VM focus switch would be replaced by attention request (which is significantly less intrusive), it should be a minor issue.
• I have considered only dom0->domU application starting. But the same might be applied for domU->domU application starting.

Of course, I mention dom0, but it might be a separate UIVM in a future release.

BTW, should I discuss inter-VM focus stealing there, or move this part of discussion to another issue?

[marmarek]

On Wed, Nov 25, 2015 at 02:34:15PM -0800, Vít Šesták wrote:

BTW, do you know the cause? I hope I know it, but I don't want to explain you my hypothesis about something you already know.

I think you've already named it. VM have no (direct) control over focus in dom0. But key/mouse events are passed to the VM as a whole (as qubesdev input device in VM), while trying to keep input focus at the same window in both dom0 and VM.

If, for any reason, focus in VM is switched to some other window without explicit dom0 request (which in most cases matches what VM applications wants) - that may lead to entering keys/mouse events to a wrong window.

Hmm, actually there was some code to send events specifically to window which received the event at dom0 side (each event carry this information), even if it isn't currently focused window. I'm not sure why it was disabled - that was on some early days of Qubes.

I hope it might be implemented without protocol change in some lighter version. The behavior described in expected behavior under letter b seems not to require any protocol change. It is also less considerably less confusing than the current state (at least for users who don't know the background of the issue).

Theoretically you're right. But in practice there are few problems with it:

1. Popup windows generally disappear when you switch focus. Forcing focus to be the same as in dom0 will probably mean focus switch, so some popup windows will become unreachable in practice, especially with settings like "focus follows mouse". In theory such applications use
   input grab for that (grab the focus wherever keyboard/mouse is and release it when that application think the user want it - click outside of window, some keys like ESC etc). But in practice it doesn't matter in Qubes, because we doesn't pass such operation to dom0 (for
   obvious reasons, I think).
2. Exactly your steps - without some UI notification would look like that program not working at all.

[v6ak]

Hmm, actually there was some code to send events specifically to window which received the event at dom0 side (each event carry this information), even if it isn't currently focused window. I'm not sure why it was disabled - that was on some early days of Qubes.

Hmm, interesting. I guess this will not be so wasy to just enable it…

Popup windows generally disappear when you switch focus. Forcing focus to be the same as in dom0 will probably mean focus switch, so some popup windows will become unreachable in practice

Theoretically yes. However, I've seen such cases rather for newly opened popups generated by user interaction.

• In short term (without any protocol change), I assume there will be no change for newly opened windows, so these problems will unlikely happen.
• In long term (when we can consider protocol change), there will not be any change for newly opened windows from the same VM, so the problem will unlikely happen.