Re: Global shortkeys and keyboard focus

2014-07-09 Thread Pekka Paalanen
On Tue, 8 Jul 2014 22:26:07 +
"Dodier-Lazaro, Steve"  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

2014-07-08 Thread Dodier-Lazaro, Steve
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

2014-07-04 Thread Fabrice Rey
The shortkeys I'm referring to are typically ...
so z, f1, 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 ctrl 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 :

> 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


Re: Global shortkeys and keyboard focus

2014-07-04 Thread Thiago Macieira
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

2014-07-04 Thread Jasper St. Pierre
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

Re: Global shortkeys and keyboard focus

2014-07-04 Thread Michael Schellenberger Costa
-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 Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP :
> 1B6B1670
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTtsEtAAoJECfkpCAi2eFKzFcIAKkKdUIAlbZ9MK7bjxsLllob
EpsJgoS35PlcOvSPQj7Qnvzcx+B059pt9OAhknt8TID28l/M6S8pdGrKwAJ66mo8
g2bHkiVYckR1viJ5EAv5ECyYNdF8hdmiWOQmGN0sJgtBcUhkqXK8drF1EwSevrtm
faD/8srG8YYIj6Ke2X7O7FldosIv/Rc/V+V2fMEAJ3yx8O5QUDOUTgcy1cnDF4XE
rKHAkqiOJhhstcxInGYSDR1/DxNY3nY4QXU8odUbWmJs1hdjL5LC7T6pRmi9oVFI
ciekFyVOiNuAOhxhSBIQzKOfeFxKoMtN/ZVEsxmSHuT7NAGMqO5vCSC3aTj4MVw=
=QvR2
-END PGP SIGNATURE-


0x22D9E14A.asc
Description: application/pgp-keys


0x22D9E14A.asc.sig
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


RE: Global shortkeys and keyboard focus

2014-07-04 Thread 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:

- 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

2014-07-04 Thread Michael Schellenberger Costa
-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-
___

Re: Global shortkeys and keyboard focus

2014-07-04 Thread Martin Peres

Le 04/07/2014 09:58, Pekka Paalanen a écrit :

On Thu, 3 Jul 2014 22:38:34 +0200
Fabrice Rey  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=hJpiJii44oo&list=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

2014-07-04 Thread Dodier-Lazaro, Steve
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

2014-07-04 Thread Pekka Paalanen
On Thu, 3 Jul 2014 22:38:34 +0200
Fabrice Rey  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