Last week I had been at the 2014 X.Org Developer’s Conference in Bordeaux, France. After Nuremberg two years ago this was my second XDC and I am very glad that I was able to attend and want to thank KDE e.V. for sponsorship. With the X.Org windowing systems (X11 and Wayland) being at the heart of KWin it is good to get an update on the latest development efforts.
Especially the talks about Wayland related topics were quite important. It was interesting to see what the Tizen developers are working on with their IVI-Shell and the discussions around the talk highlighted the need for a careful put out standardization process for the Wayland shell interfaces: if the interface does not contain enough functionality, multiple incompatible interfaces could be the result making it difficult for applications to interact with the system. On the other hand if the interfaces are too broad it will result in compositors not being able to completely implement the interface resulting again in compatability issues.
More directly touching our development were the talks concerning input handling with libinput. I already have some code prepared and expect that KWin/Wayland 5.2 will come with libinput support (more about that in a future blog post when the work is ready). The talks also showed that I need to reach out to the Krita community to get support for tablet devices. I don’t have access to such a device and even if, I would not know or understand the needs for these kind of input devices. There I will need the expertise of developers using tablet devices and I hope to find this within the Krita community.
KWin/Wayland 5.1 gained support for the fullscreen shell interface. My idea when adding this was to not have to implement DRM support in KWin, but (for the time being) leverage Weston. This simplifies development and allows us to move forward on a higher speed. Jason Ekstrand’s talk showed that the fullscreen shell provides more interesting aspects than our use case. The shell can also be used for use cases such as screen sharing: a compositor renders in addition to a fullscreen shell provided by a different compositor which can use it to e.g. capture a video stream or forward an rdp session. Very interesting and quite useful that we already support it and won’t have to add additional support for rdp into each compositor.
Last but not least I want to highlight Steve Dodier-Lazaro and Martin Peres’s talk about security in a Wayland world. They presented a solution for privileged clients which is very important for our development in the Plasma world: there will be interfaces between Plasma and KWin and nobody except Plasma should be allowed to bind to them. The library presented in this talk will solve this problem and many more. Even more the talk touched various interesting security related topics which I had never thought about in that way. For example setting a window fullscreen provides a security risk: it could fake a lock screen interface tricking the user into entering the password. On X11 the Window Manager/Compositor is unable to mitigate this risk. But on Wayland a compositor can e.g. overlay the window and explicitly ask the user whether the window is allowed to go fullscreen – compare to what browsers already do today. I’ll reach out to the VDG to come up with a good solution.
More interesting is the question on how we can trust password dialogs. This is something I already spent some thoughts about in the past. The problem right now is that a malicious application can easily trick the user into entering the password by faking a system dialog (e.g. polkit authentication or kwallet dialog). We need to find a way to show to the user that this is a trusted dialog and that the password is entered for a trusted application. A difficult task. There are many ways we can make the dialog in a way that nobody would be able to fake it: color the decoration, wobble it, put it into the Plasma’s notification area, but none of them are obvious to a user that no other process can fake it. As explained in the talk it needs an out-of-band communication channel to inform the user that this dialog is trusted. An idea which came to my mind is using KDE Connect to send a token to the connected smartphone to indicate that the dialog is secure.
Unfortunately the state of KWin/Wayland has not processed enough compared to Akademy that I could have done a talk about it. After all it was just a few weeks. So instead I decided to give a talk about what we mostly did last year: port KWin to XCB.
The Windows style for asking passwords is quite ok: put the password window on top, and make the rest of the screen unsaturated. (Kwin has an similar effect I think) Also, input is not accepted outside the password window until the user press Cancel.
It’s quite disturbing if you are working, because it interrupts whatever the user was doing. Windows solves this showing a password notification flashing on the taskbar. Until you press it, nothing happens.
Password window triggered from the window on focus? Show it blocking the rest of the desktop.
Password window triggered from an unfocused window? Show a Plasma notification.
This seems like a sensible plan, but why other applications could not do that to steal your credentials? We need a way for the user to also authenticate the window and your proposition does not handle that.
For more information (slides + video): http://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/
Old blog post: http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
A way to ‘securely’ ask for passwords is to make the password dialog visually connected to the compositor chrome. That of course requires the compositor to have chrome (e.g. Gnome Shell top bar).
Allowing applications to go full screen will allow them to fake the compositor chrome and the password dialog as well. To mitigate that we might have to keep a small overlay, say in the corner of the screen, to remind the user that this is a full screen application rather then a compositor chrome.
We’ve got plenty of tablets to test with, yiynova, wacom, huion and genius, in various models. But none of my development systems are up-to-date with wayland, plasma5 and libinput, until January, all krita development will still be Qt4-based.
I guess that would would perhaps be best if I’d find some time to have a wayland/libinput system on a usb stick for testing. Dmitry, in the meantime, has already engaged with people on the libinput mailing list about what an application like Krita needs on the tablet input side.
super that you are already in contact with the libinput developers. That’s at the current state the most important part.
I don’t expect we will reach a state in development that it matters before January. Maybe a combined GSoC next year would be a good solution (assuming that Krita has also some native code to port).