Authorized clients

[Pekka Paalanen]

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.
> >
>