Re: Global shortkeys and keyboard focus
On Tue, 8 Jul 2014 22:26:07 + Dodier-Lazaro, Steve s.dodier-lazaro...@ucl.ac.uk wrote: A couple of notes on the previous emails, Fabrice, so long as your app ensures that no third-party code can programmatically grab a shortcut without user agreement, it would make sense to let it have a privilege. Quite obviously a compo should have the last word and be able to refuse a request to grab a certain shortcut. If this happens, compo developers please do provide the requesting app a displayable/translatable explanation that your end-users would understand ;) I don't quite like the idea of a permission prompt from the compo for setting up keyboard shortcuts. In the vast majority of cases the user is already using a specific GUI for that and possibly setting up more than one shortcut (e.g. shortcuts to newly installed media app), so it'd be awkward for them to receive a permission prompt. I think privileges work much better here (or User-Driven Access Control with a button that when clicked displays a compositor-owned dialog inviting the user to select a global shortcut). A wild thought in passing, which likely borrows from things I've heard from others before... What if applications would install config file snippets, a la configdir design, which specify a semantic action by identifier string, and the default suggested hotkey, gesture, or whatever. Or maybe they would be in the app's .desktop file, whatever The compositor would watch this directory, and when files there change, it would read them and notice that e.g. now there is a new hotkey action available. However, all that would do is light up a marker somewhere in the desktop UI saying you have new hotkey actions available, click here to set up all your hotkeys. So the new hotkey would *not* work simply by the app's actions or by installing the app. The user can go into the hotkey config dialog in his DE UI, there see as highlighted the new things, and have the option to accept the default key binding, choose another key, or just leave the action unbound. The idea being that they are all under the DE (compositor) control, that is under the user's control, and all in one place. When the app is actually started, it will register for the semantic action by its identifier string, and then it may or may not get it triggered. No privileges needed so far as I can see. Also nothing above says it must be Wayland protocol. It could as well be dbus. And it could as well apply to X11-based DEs! Or maybe existing DEs already have a hotkey registration system, and we have to do nothing more on Wayland standardization specifically?... So it might not even be a Wayland thing at all. If a hotkey action needs to do something that is most of the time not allowed, like raise a window to the top (using a hypothetical protocol I'm not sure exists yet), I suppose the simplest thing would be for the hotkey action event to carry a serial like input events do, so the app can use that as a ticket to allow the raise the window request to be accepted. This would need integration in the Wayland protocol. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Global shortkeys and keyboard focus
A couple of notes on the previous emails, Fabrice, so long as your app ensures that no third-party code can programmatically grab a shortcut without user agreement, it would make sense to let it have a privilege. Quite obviously a compo should have the last word and be able to refuse a request to grab a certain shortcut. If this happens, compo developers please do provide the requesting app a displayable/translatable explanation that your end-users would understand ;) I don't quite like the idea of a permission prompt from the compo for setting up keyboard shortcuts. In the vast majority of cases the user is already using a specific GUI for that and possibly setting up more than one shortcut (e.g. shortcuts to newly installed media app), so it'd be awkward for them to receive a permission prompt. I think privileges work much better here (or User-Driven Access Control with a button that when clicked displays a compositor-owned dialog inviting the user to select a global shortcut). ??-- Steve ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
On Thu, 3 Jul 2014 22:38:34 +0200 Fabrice Rey faboune...@gmail.com wrote: Hi all, This topic came up in my previous one about window placement, and I'd like to go further. So currently there is no such thing as Global shortkeys and keyboard focus, Have you tried searching for the wayland-devel mailing list archives for hotkeys/shortcuts? I think there was a pretty decent plan, IIRC based on a conference presentation on something about security and global hotkeys, where clients register or subscribe to actions and compositors map global keys to them or such. We just haven't heard from it on the list since. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Global shortkeys and keyboard focus
Hi Fabrice, Hi all, This topic came up in my previous one about window placement, and I'd like to go further. So currently there is no such thing as Global shortkeys and keyboard focus, however let me present a typical real use-case: [...] Now, I've read some vague things about privileged clients, is it still being considered ? Note that most of the formalisation that occurred was done by Martin Peres from Nouveau (and to a lesser extent myself; I'm not a Wayland dev at all though). We're hoping to have a number of PoC demos of privileged clients for XDC but are both really really busy with our research (both PhD students). It's not clear if we will have implemented stuff to demonstrate... If you want/need to work on global shortcuts in the next weeks I can make an effort to make our latest discussions and plans available in a concise form. Would it be some Android-like capabilities that the user validates on installation or the first time they are required by the application ? What are the plans for these 2 key features ? We only discussed what the privileges are. Intercepting global shortcuts is a privilege so your app would need to either: - have a capability to register a global shortcut itself - be entitled by a trusted third party to using a specific global shortcut A capability should be granted to a package by a distributor, most likely. This means distros who care about security would setup a process to verify why app devs/packagers want a capability for their app (whilst allowing core projects such as DEs/distro apps to have privileges and be deployable right away). The second point is a bit fuzzier, especially for global shortcuts. For some privileged interfaces once apps can be sandboxed on Linux, [and once I've written a decently secure UI embedding protocol *], they can be given widgets from a trusted third-party that the user can interact with to organically grant privileges. Apps should also have some nice APIs for opening and exporting resources in a secure way. You can tell that it's hard to find out how to provide a global shortcut UI abstraction that is unambiguous to users, especially since I understand your app will be GUI-less. Xfce has a GUI for assigning global shortcuts to commands, and I believe other DEs do as well. This utility will typically be the one holding a capability for intercepting any global shortcut. Your app should normally not qualify for such a privilege, so make your event triggerable via a CLI call and get users to assign the shortcut to your app. If DEs are willing to grant you full global shortcut privileges without assessing who you are, what your app does and in what ways your app can be compromised, they will probably have security issues in the future. Feel free to work with distrubotrs to sketch out a process for granting and revoking capabilities to third-party apps, etc. but I think this problem goes well beyond the scope of Wayland privileged interfaces! PS: you were the person proposing to let apps know or adjust their position on the screen? This, typically, creates vulnerabilities and makes trusted UI embedding much harder if not compromised. If you have specific use-cases that need to be supported, please come discuss them with us (#wayland-security on Freenode or this ML, I guess) so we can think of secure ways to support your needs without compromising the separation between clients and trusted UIs. Thanks,?? -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
Le 04/07/2014 09:58, Pekka Paalanen a écrit : On Thu, 3 Jul 2014 22:38:34 +0200 Fabrice Rey faboune...@gmail.com wrote: Hi all, This topic came up in my previous one about window placement, and I'd like to go further. So currently there is no such thing as Global shortkeys and keyboard focus, Have you tried searching for the wayland-devel mailing list archives for hotkeys/shortcuts? I think there was a pretty decent plan, IIRC based on a conference presentation on something about security and global hotkeys, where clients register or subscribe to actions and compositors map global keys to them or such. We just haven't heard from it on the list since. You have a good memory Pekka! You are referring to [0]. Peter Hutterer proposed a semantic approach to global shortcuts which could partially address the issue. I have not addressed the issue of global shortcuts in my blog article about how to handle privileged clients [1] mostly because I haven't made up my mind with it just yet. However, I was looking into a KDE-like solution where a compositor-exported application centralizes the global shortcuts. Any application running could listen to semantic events such as play/pause. Applications may register new semantic actions. In this case, application would request to add a semantic action + a default shortcut for it. The compositor would then prompt the user to ask if the application is allowed to add a semantic event with the default shortcut proposed by the application. If no conflict exist, the user could press Add the shortcut, Cancel, Customize the shortcut. If a conflict exists, only the last two would be allowed. If the user presses the Customize the shortcut button, the compositor would launch the global keyboard center to let the user add the shortcut he/she wants. If the user wants to update the shortcuts, the application should send a request for the compositor to launch the shortcut application (this should be part of a semantic way of launching applications, like: launch the default camera application, or launch the calculator). Some applications may actually want to be launched at a particular event (run kcalc when pressing the CALC button on the keyboard). For those, I'm not sure if the package manager should ask the compositor to add the shortcut or add a file containing the new shortcuts defined and their definition. In the latter case, the shortcut manager could detect the added file and if there is a conflict, ask the user to deal with it. These are my current thoughts on the matter, I would love to hear from what you would like to have but as Steve said, I'm very busy at the moment as I am writing my PhD thesis :s Cheers, Martin [0] https://www.youtube.com/watch?v=hJpiJii44oolist=UUYhzLcUuRRyyhPqGxqr9E3A#t=2102 [1] http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.07.2014 12:53, Dodier-Lazaro, Steve wrote: Hi Fabrice, Hi all, This topic came up in my previous one about window placement, and I'd like to go further. So currently there is no such thing as Global shortkeys and keyboard focus, however let me present a typical real use-case: [...] Now, I've read some vague things about privileged clients, is it still being considered ? Note that most of the formalisation that occurred was done by Martin Peres from Nouveau (and to a lesser extent myself; I'm not a Wayland dev at all though). We're hoping to have a number of PoC demos of privileged clients for XDC but are both really really busy with our research (both PhD students). It's not clear if we will have implemented stuff to demonstrate... If you want/need to work on global shortcuts in the next weeks I can make an effort to make our latest discussions and plans available in a concise form. Would it be some Android-like capabilities that the user validates on installation or the first time they are required by the application ? What are the plans for these 2 key features ? We only discussed what the privileges are. Intercepting global shortcuts is a privilege so your app would need to either: - have a capability to register a global shortcut itself - be entitled by a trusted third party to using a specific global shortcut Is there any reason global shortcuts should lie with an application? Wouldn't it make more sense to provide an interface on the compositor side, where clients can register a global shortcut and the compositor sends an event back in case of the shortcut being pressed. In that case the compositor could follow predefined rules switching focus etc. Best wishes Michael A capability should be granted to a package by a distributor, most likely. This means distros who care about security would setup a process to verify why app devs/packagers want a capability for their app (whilst allowing core projects such as DEs/distro apps to have privileges and be deployable right away). The second point is a bit fuzzier, especially for global shortcuts. For some privileged interfaces once apps can be sandboxed on Linux, [and once I've written a decently secure UI embedding protocol *], they can be given widgets from a trusted third-party that the user can interact with to organically grant privileges. Apps should also have some nice APIs for opening and exporting resources in a secure way. You can tell that it's hard to find out how to provide a global shortcut UI abstraction that is unambiguous to users, especially since I understand your app will be GUI-less. Xfce has a GUI for assigning global shortcuts to commands, and I believe other DEs do as well. This utility will typically be the one holding a capability for intercepting any global shortcut. Your app should normally not qualify for such a privilege, so make your event triggerable via a CLI call and get users to assign the shortcut to your app. If DEs are willing to grant you full global shortcut privileges without assessing who you are, what your app does and in what ways your app can be compromised, they will probably have security issues in the future. Feel free to work with distrubotrs to sketch out a process for granting and revoking capabilities to third-party apps, etc. but I think this problem goes well beyond the scope of Wayland privileged interfaces! PS: you were the person proposing to let apps know or adjust their position on the screen? This, typically, creates vulnerabilities and makes trusted UI embedding much harder if not compromised. If you have specific use-cases that need to be supported, please come discuss them with us (#wayland-security on Freenode or this ML, I guess) so we can think of secure ways to support your needs without compromising the separation between clients and trusted UIs. Thanks,?? -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTtqnMAAoJECfkpCAi2eFKDHYH/il5ooHSHfwPHlElbOB3SbxI isa5PZ16kBcf5heh9Sjdg/SCfkLHjt9eSECuF8AnqRi5F1ykG0U4bej53cDm13t+ WLFvYlWyxa2esgPk83kMA8PmPOmTWMshhuZrGwcgMl5BXxt/fu44GH77ULXl3GLI 6GxGN2E/BWwjrF7IANRfbob4DGeesK5w24U84GDrp3u1KBpnASbz1/yUj7q8KSYW Pq5RgORUpLJ0nboV2551rgebbbttm3jFqQUgT53OLpEsb8P6MOb2K8+Z/IauE/hv JPDaSYzPRixhne68nyptE4BjJHOd63Ac0iElIN8JdGtVTR3TAuNSYZRiGenWzXQ= =JQ80 -END PGP SIGNATURE- ___ wayland-devel mailing list wayland-devel
RE: Global shortkeys and keyboard focus
Hi Michael, Is there any reason global shortcuts should lie with an application? Wouldn't it make more sense to provide an interface on the compositor side, where clients can register a global shortcut and the compositor sends an event back in case of the shortcut being pressed. In that case the compositor could follow predefined rules switching focus etc. The problem is: what are the allowed global shortcuts leaking about users? If it's any key that can be listened to, then we've just gotten ourselves an API for implementing keyloggers. If it's any key + some modifier (Ctrl, Alt, etc) then we need to see DE by DE what listening to all available key combinations lets me learn about the user: - Can I listen to Alt+Tab or to the shortcut used to maximise windows? If so can I learn the window layout of the user (or at least whether a window is being displayed or not)? For instance Martin proposed to use an Expose like view of the desktop as a background for modal authentication dialogs, so that the user knows it's a compositor (that is capable of moving windows around) that is asking for your password. If I know that no windows are being displayed because the user hasn't Alt+Tab'd for a while and just Alt+F4'd then I can spoof that UI directly and steal your password. - Can I learn if you're playing music? If you're browsing the Web? If you're typing some document? Is that information alone useful to profile your activities? - Can listening to Ctrl+C allow me to know when you're using the clipboard despite it being a privileged interface? If I'm sniffing your network traffic I may know that you've just landed on a site's authentication page, and you're using the clipboard. You're probably one of those users who have a password file that they use to copy credentials from. I may now serve you an exploit on the clipboard API or an exploit allowing me to scan your FS as I know there's something that can be monetized. Generally speaking, there'll always be someone smarter and more motivated than us to figure out how to build composite attacks from seemingly innocuous APIs. So I'd rather lock down what is not strictly necessary. How many apps need global shortcuts other than the ones that have a semantic attached to them? How are the GUIs for handling custom global shortcuts and Preferred handlers for those semantic keys not enough? If we can cater for all common needs without exposing all your keyboard shortcuts to potential malware, then we've done a great job. Regards, -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
I think the user should be in control here. I have a custom setup just because it's something I did 10 years ago and it's engrained into my muscle memory. Ctrl+Shift+X is pause/play music Ctrl+Shift+C is play music (which also means rewinding the current track to the beginning) Ctrl+Shift+D is next track Ctrl+Shift+Alt+D is previous track I understand this is a custom setup, so I'm OK with going to the Control Panel and explicitly marking that these shortcuts do these features in my media player. The rest of everything is just UI. How do you expose these actions to the user and allow them to set up global shortcuts for it? OS X makes you type some complicated path to the menu item to trigger: http://support.apple.com/kb/ph6889 With DBus and the new Actions available inside applications [0] , maybe we can build a UI to allow you to hook up keyboard shortcuts to application actions, or to shell commands, or whatever. I don't ever want an application to be able to request a global shortcut without my permission, and I speak as both a user and a DE developer here. That's a support and security nightmare. The settings you create might be DE-specific, because certain DEs might have different features and limitations about global keyboard shortcuts. I don't think there's any need for a Wayland protocol here. Just UI and design. [0] http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions On Fri, Jul 4, 2014 at 10:58 AM, Michael Schellenberger Costa schellenber...@inb.uni-luebeck.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04/07/2014 16:04, schrieb Dodier-Lazaro, Steve: Hi Michael, Is there any reason global shortcuts should lie with an application? Wouldn't it make more sense to provide an interface on the compositor side, where clients can register a global shortcut and the compositor sends an event back in case of the shortcut being pressed. In that case the compositor could follow predefined rules switching focus etc. The problem is: what are the allowed global shortcuts leaking about users? If it's any key that can be listened to, then we've just gotten ourselves an API for implementing keyloggers. If it's any key + some modifier (Ctrl, Alt, etc) then we need to see DE by DE what listening to all available key combinations lets me learn about the user: I did not meant it in the way of a client listening to keys, but to events sent from the compositor. In no way an application should be allowed to listen to certain key combinations without focus. I thought more about a compositor plugin an application can register to (Authenticated through user) and only if the user allowed the application to receive a special shortcut, then the compositor sends an *event* to the application if that and only that shortcut was used. So the compositor acts as a middleman denieing some rogue application to listen to ctrl+c Best wishes - Can I listen to Alt+Tab or to the shortcut used to maximise windows? If so can I learn the window layout of the user (or at least whether a window is being displayed or not)? For instance Martin proposed to use an Expose like view of the desktop as a background for modal authentication dialogs, so that the user knows it's a compositor (that is capable of moving windows around) that is asking for your password. If I know that no windows are being displayed because the user hasn't Alt+Tab'd for a while and just Alt+F4'd then I can spoof that UI directly and steal your password. - Can I learn if you're playing music? If you're browsing the Web? If you're typing some document? Is that information alone useful to profile your activities? - Can listening to Ctrl+C allow me to know when you're using the clipboard despite it being a privileged interface? If I'm sniffing your network traffic I may know that you've just landed on a site's authentication page, and you're using the clipboard. You're probably one of those users who have a password file that they use to copy credentials from. I may now serve you an exploit on the clipboard API or an exploit allowing me to scan your FS as I know there's something that can be monetized. Generally speaking, there'll always be someone smarter and more motivated than us to figure out how to build composite attacks from seemingly innocuous APIs. So I'd rather lock down what is not strictly necessary. How many apps need global shortcuts other than the ones that have a semantic attached to them? How are the GUIs for handling custom global shortcuts and Preferred handlers for those semantic keys not enough? If we can cater for all common needs without exposing all your keyboard shortcuts to potential malware, then we've done a great job. Regards, -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place
Re: Global shortkeys and keyboard focus
On Friday 04 July 2014 14:04:03 Dodier-Lazaro, Steve wrote: The problem is: what are the allowed global shortcuts leaking about users? If it's any key that can be listened to, then we've just gotten ourselves an API for implementing keyloggers. Just because the API and standard allow any key to be requested does not mean that the compositor will honour that request. It can have a rule that limits which shortcut combinations will be allowed. And obviously it should refuse any that conflict with its own shortcuts. But we should have a recommendation to applications as to what modifiers are most likely to be accepted, which in turn means applications should avoid using those key combinations as non- global shortcuts in their UXs. The compositor can also ask the user if it's unsure: confirm you want this application to use this global shortcut. The compositor should remember which applications requested what, so as to avoid conflicts or at least inform the user when that happens. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
The shortkeys I'm referring to are typically modifier1modifier2...key so superz, ctrlshiftf1, etc. Currently, in the application each applet registers a shortkey with a description, its icon, and a callback. So all shortkeys are configurable from a single place in the UI. The user can double-click on a shortkey to enter a new one, so any shortkey that is already used will not work (because it will just trigger the action and be intercepted); however ctrlc would still reach the UI and be accepted, at least currently it is. Then, when a shortkey is pressed, the application receives an X event, find the associated callback and calls it. So it's similar to the idea of having an UI in the DE's configuration that lists all available shortkeys registered by all applications. It's also similar to the idea of having the compositor acting as a man-in-the-middle (dispatching signals to applications that registered shortkeys). It remains to see how secure it could be. If you let an application registers only empty shortkeys (so it only adds a new description+icon in the list of triggerable actions but by default it's not linked to any shortkey) then there is no risk a malicious application could listen for any keyboard events; because the user would have to manually define a shortkey first. It also means that by default an application will not have any shortkey, the user will have to go to the UI and define the shortkeys after installing an application that have triggerable actions. That cold be seen as a flaw, but you could argue that the newly installed application has no way to know if its default shortkeys will be available or will be effectively accepted by the compositor, so maybe it's not so bad to force the user to define its shortkeys. Another way is to let the application register an actual shortkey, and then on first trigger, ask the user if he's ok. Or let the packagers authorize an application to register any shortkey (by installing some policyKit-like files); this could also be for several other priviledged actions. In any ways, the compositor would always be the one that accepts/refuses a shortkey and calls the application. 2014-07-04 18:57 GMT+02:00 Thiago Macieira thi...@kde.org: On Friday 04 July 2014 14:04:03 Dodier-Lazaro, Steve wrote: The problem is: what are the allowed global shortcuts leaking about users? If it's any key that can be listened to, then we've just gotten ourselves an API for implementing keyloggers. Just because the API and standard allow any key to be requested does not mean that the compositor will honour that request. It can have a rule that limits which shortcut combinations will be allowed. And obviously it should refuse any that conflict with its own shortcuts. But we should have a recommendation to applications as to what modifiers are most likely to be accepted, which in turn means applications should avoid using those key combinations as non- global shortcuts in their UXs. The compositor can also ask the user if it's unsure: confirm you want this application to use this global shortcut. The compositor should remember which applications requested what, so as to avoid conflicts or at least inform the user when that happens. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Global shortkeys and keyboard focus
Hi all, This topic came up in my previous one about window placement, and I'd like to go further. So currently there is no such thing as Global shortkeys and keyboard focus, however let me present a typical real use-case: I have a dock which is most of the time hidden (because a window is overlaps it) and some applets inside. Using the keyboard is therefore a very convenient a fast way to access the items inside. For instance, ctrl+F1 pops the Applications Menu, which has a text entry inside; the entry takes the focus so I can immediately type some letters, and the menu will only display the relative applications. Down arrow + Enter let select the desired one if it's not already on the first row. I could also pop up the translation dialog with another shortkey, immediately type the word I want to translate, press Enter, and see the result. Now, I've read some vague things about privileged clients, is it still being considered ? Would it be some Android-like capabilities that the user validates on installation or the first time they are required by the application ? What are the plans for these 2 key features ? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
