Enable X11 event buffering in Whonix by default

[ArrayBolt3]

The problem you're addressing (if any)

Now that QubesOS/qubes-gui-daemon#149 is merged, any VM in Qubes OS that supports a GUI daemon can have Kloak-like features (keyboard and mouse event delay) enabled on them. While most VMs probably would probably have their usability degraded if this feature was enabled on them by default, Whonix benefits greatly from having this feature because it directly helps it to accomplish its goal of providing additional anonymity to users.

Right now a user has to explicitly set the gui-ebuf-max-delay feature to a non-zero value on a VM in order to enable event buffering. This is not something the average user should have to do, Whonix-Workstation should have this enabled by default. (Whonix-Gateway should potentially leave this disabled since the user won't be interacting with websites in Whonix-Gateway if used as designed.)

The solution you'd like

• Modify https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/main/qubeswhonix/__init__.py so that it responds to a feature request from a Whonix VM to set gui-ebuf-max-delay. Requests should only be honored if they fall between reasonable thresholds so that malware can't disable the delay entirely or set it to be so high as to render the VM unusable.
• Add a script to Whonix's anon-ws-base-files package to request the feature and set it to a sensible value.

This strategy will allow Whonix to adjust the delay in the future if it is desirable to do so.

Alternatively, since the gui-ebuf-max-delay relies entirely on dom0 and doesn't require any domU-side code at all,
we could just modify https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/main/qubeswhonix/__init__.py to set the feature all by itself one time, and that's it. This does mean that setting the delay is a "one shot" operation and if it turns out to be bad, another change to qubes-core-admin-addon-whonix will be needed. This would have the advantage of not allowing malware to even try to adjust the delay however.

The value to a user and who that user might be

Applications (especially websites) should have a harder time tracking the user via keyboard biometrics. (Mouse movements may also be obfuscated enough to make fingerprinting difficult through that method, though I'm not sure any concrete tests have been done on the mouse beyond "now it's laggy".)

Completion criteria checklist

No response

[alimirjamali]

For the alternative solution, the salt formulas for whonix (here, here & here) could include the desired event_max_delay feature preset (good for new installations). So it should work as desired right out of the box.

[Atrate]

@ArrayBolt3 How would a user enable this for a qube themselves? Either I can't find it or there is no documentation.

Do I understand correctly that this should work with any qube without additional configuration except typing

qvm-features QUBENAME gui-ebuf-max-delay 100

in dom0?

That does not work (as tested by setting the delay very high). I've also tried the event_max_delay feature, events-max-delay, events_max_delay, gui-events-max-delay (all found in different issues). None of those work.

I've also tried

qvm-service QUBENAME gui-agent-virtual-input-device  --enable

in dom0 and rebooting the qube but that also seems to do nothing.

[alimirjamali]

Either I can't find it or there is literally no documentation.

Please take note that it is a recent addition and still in testing repositories. Are you using the stable repository or testing?

[marmarek]

This feature is available only in Qubes OS R4.3

[Atrate]

This feature is available only in Qubes OS R4.3

That explains why it wasn't working. I'll just assume I was doing it correctly and wait for the feature to make it to stable.

[ArrayBolt3]

How would a user enable this for a qube themselves? Either I can't find it or there is no documentation.

@Atrate What you were doing is correct, but yeah, it's an R4.3-only thing, and it's not yet exposed to the end user in a meaningful way. It is documented in the /etc/qubes/guid.conf file (which is a deprecated config file that seems to have basically morphed into documentation for the Qubes GUI daemon's settings), but that's it.

Should this be exposed to the end-user somehow? I was going to just go with it being an internal thing that was managed without user intervention, but maybe giving the user the ability to set this in some way would be nifty. (Maybe all of the GUI daemon settings could be similarly customizable...)

[Atrate]

Should this be exposed to the end-user somehow?

I think it's a great idea to expose it to the end-user. I run a couple of qubes for less trusted apps that have a history of being privacy-invasive and that could be another layer of protection I could apply to those qubes.

[ArrayBolt3]

@Atrate If you could file a new feature request for that, potentially with an idea of where in the UI to put it, I may be able to spend some cycles implementing that.

[adrelanos]

If using salt: Please keep in mind that we'd like to:

• Automatically enable this feature by default for existing users during upgrades.
• Should be enabled for all VM clones based on Whonix-Workstation.

(Whonix-Gateway should potentially leave this disabled since the user won't be interacting with websites in Whonix-Gateway if used as designed.)

Correct.

Requests should only be honored if they fall between reasonable thresholds so that malware can't disable the delay entirely or set it to be so high as to render the VM unusable.

This could be simplified to honor only a reasonable default value set by developers. (Users would be free to modify this setting by editing a file in dom0.)

Alternatively, since the gui-ebuf-max-delay relies entirely on dom0 and doesn't require any domU-side code at all,
we could just modify https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/main/qubeswhonix/__init__.py to set the feature all by itself one time, and that's it.

Better.

This does mean that setting the delay is a "one shot" operation and if it turns out to be bad, another change to qubes-core-admin-addon-whonix will be needed.

This is acceptable.

I think it's a great idea to expose it to the end-user. I run a couple of qubes for less trusted apps that have a history of being privacy-invasive and that could be another layer of protection I could apply to those qubes.

Does this need to be exposed to the user irrespective of this becoming the default for Whonix-Workstation App Qubes?

I guess this could be somewhat optional. It's a nice to have since this would be a way of letting the user know that such a feature exist and reduce confusion about keystroke delays.

[Atrate]

@Atrate If you could file a new feature request for that, potentially with an idea of where in the UI to put it, I may be able to spend some cycles implementing that.

Maybe it could be placed in the Qube Manager in the settings dialog for a Qube, under some new tab?

This way, "advanced" features like this could all be found in one place. Other features to consider include:
#7316
#4986
#9785
#4986
#9763