Passive and active attacks via X11. Is Wayland any better?

[Michael Hasselmann]

On Fri, 2012-02-17 at 12:05 -0800, Bill Spitzak wrote:
> Kristian Høgsberg wrote:
> 
> >> 1) Are you planning to support on-screen keyboard apps? If so, how this
> >> is going to be implemented, so that a malicious/compromised app couldn't
> >> act as such "on-screen keyboard" and inject keystrokes to other apps?
> > 
> > We can restrict access to functionality on a per-application basis.
> > An on-screen keyboard would be part of the core ui and launched by the
> > compositor in a way that gives it access to the "input event
> > injecting" interface.
> 
> I think a much easier way is that clients directly talk to the on-screen 
> keyboard application.

Exposing the virtual keyboard to the applications means you have to
patch all toolkits that run on your platform, in order to support.
Desktops usually allow all kind of toolkits. So having the virtual
keyboard in the compositor allows it to support applications that use
different toolkits. It also allows the compositor to restrict access to
the active application, as Kristian mentioned.

On top of that, the virtual keyboard (and possibly other input methods)
only need to be launched once, if running inside the compositor. This
can affect application start up time significantly (think of
dictionaries and word engines that need to be initialized).

Giving applications too much control over the virtual keyboard also
makes it too easy for applications to simply provide their own, and then
any form of platform consistency is gone. I think it's better to have a
policy where toolkits need to implement the virtual keyboard support for
Wayland and the applications don't have to do anything at all.

That being said, there are a few use-cases where on-screen keyboard
inside the application makes sense, but for the majority of use-cases,
it's more beneficial to have it in the compositor (or even as a
dedicated process, but still protected from direct application access).

regards,
Michael