Authorized clients

[Jasper St. Pierre]

As Stef Walters explains in his excellent GUADEC talk from last year, never
prompt the user to make a security decision while they're trying to do
something. You will get worse results than random chance. [0]

UAC is fairly unpopular with people. If I'm launching something like SSR or
OBS to stream a video game I'm playing to Twitch.TV, prompting me that yes,
I *really* meant to stream this game, is annoying to the user. The intent
is to stream the game, since I launched the application.

Same for other applications: I already clicked "Share Screen" in my
Hangouts, my intent is to Share my Screen. A second prompt will just be
seen as annoying.

I think the idea here is to make sure that some apps have the "privilege"
to capture my screen, similar to how Android works, and others don't. SSR
or OBS will have this privilege, and the Weather app won't.

Note that in none of these cases will the app be launched by the
compositor. Google Hangouts is also an interesting case, as the screen
capture feature in Google Hangouts is provided by a browser plugin. I'd
imagine that the plugin would have to install a .desktop file for "Google
Hangouts" so that it could show up as an application that could request
access.

[0] http://www.superlectures.com/guadec2013/more-secure-with-less-security


On Wed, Jan 8, 2014 at 2:34 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 7 Jan 2014 15:00:31 -0500
> "Jasper St. Pierre" <jstpierre at mecheye.net> wrote:
>
> > On Tue, Jan 7, 2014 at 2:43 PM, Pekka Paalanen <ppaalanen at gmail.com>
> > wrote:
> >
> > > On Tue, 7 Jan 2014 14:26:36 -0500
> > > "Jasper St. Pierre" <jstpierre at mecheye.net> wrote:
> > >
> > > > On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres
> > > > <martin.peres at free.fr> wrote:
> > > >
> > > > > Would it be ok for you if the compositor asked the user to
> > > > > agree for the program to
> > > > > do the operation? If so, we can guarantee that this is really
> > > > > the user's intent and
> > > > > allow the application. We can also add a security warning with
> > > > > a "Do not ask again"
> > > > > checkbox. Would it be satisfactory to you?
> > > > >
> > > >
> > > > The user opened up a screen recording app. The user's intent is
> > > > very much to record the screen. We don't need to ask the user
> > > > again with a prompt.
> > >
> > > For just screenshooting and recording, how about a simple setting
> > > "allow all programs capture the screen? yes/no" in the compositor's
> > > configuration dialog? Since it sounds like any automatic
> > > authentication/authorization scheme is going to hit cornercases.
> > >
> >
> > Because I don't want my weather app broadcasting my porn preferences
> > to Twitch.tv. Android solves this by telling the user up-front what
> > the app is requesting access to, and (experimentally) allowing the
> > user to turn off fine-grained access for any component.
>
> Then you just never poke the button to "enabled", no? Poke it only when
> you actually need it, that's why I wrote "dynamic enable/disable". The
> GUI could be as simple as a context menu from the desktop.
>
> I mean that you'd poke it as needed, not just once when you install
> some particular app.
>
> > I think we need some way to request permissions, but it's up to the
> > compositor to determine how these are granted. If it's a modal
> > "yes/no" dialog, or if it's a lookup based on the application ID, or
> > a blanket policy doesn't matter, the client just gets back a "go
> > ahead" or a "nope" in response.
> >
> > This is very similar to PolicyKit, so talking with David Zeuthen
> > might be useful here if he has any work in the area to make PolicyKit
> > more like an Android model.
>
> If people actually can figure out a good and clever way to do it, that
> would be great. I was just proposing something simple that allows screen
> recording/broadcasting software developers to continue their work in the
> mean time. Or do you think such a quick'n'dirty solution then becomes
> the standard and no-one bothers to develop a proper method?
>
> I did accidentally hit "send" in the middle of writing that
> previous email...
>
>
> Thanks,
> pq
>
>
> > > With that, write a screenshooting protocol interface, that is
> > > bindable for all clients, and informs the client whether capturing
> > > at will is allowed or not. When not, the client can show an
> > > informational message "Screen capturing is disabled in your
> > > compositor preferences."
> > >
> > > Make that support dynamic enable/disable and make access denied a
> > > non-fatal error.
> > >
> >
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140108/1cfea243/attachment-0001.html>