Re: Chrome Remote Desktop Support for GNOME/Wayland

On Tue, Jan 25, 2022 at 06:51:20PM +0000, S . via desktop-devel-list wrote:
> > If you visite the screenshare configuration panel, you have two choices,
> > interactive or password driven. The second is non-interactive. The visu=
al
> > addition telling the user that the display/screen/window is share does =
not seems
> > like a problem to me, but indeed possibly make a bit less sense outside=
 of
> > remote support kind of use case.
> =

> Thanks. I wasn't aware of the non-interactive option and I didn't see one=
 when I interacted with the screencast. Is this a new addition? Please see =
the attached screenshot on the following system config:

These options (prompt vs password) are specific to GNOME Remote
Desktop's VNC support, which sits on the same level as the GNOME
platform, thus isn't really relevant to what you are looking for I
suspect. The prompt is just a notification query that GNOME Remote
Desktop sends and then listens to and nothing else.


Jonas

> =

> $ gnome-shell --version
> GNOME Shell 41.1
> =

> ~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description: Debian GNU/Linux bookworm/sid
> Release: 11-updates
> Codename: n/a
> =

> Thanks,
> Salman
> ________________________________
> From: Nicolas Dufresne <[email protected]>
> Sent: Tuesday, January 25, 2022 10:24 AM
> To: S . <[email protected]>; [email protected] <desktop-devel-=
[email protected]>
> Subject: Re: Chrome Remote Desktop Support for GNOME/Wayland
> =

> Le mardi 25 janvier 2022 =E0 16:30 +0000, S . via desktop-devel-list a =
=E9crit :
> > Hi All,
> >
> > (Please feel free to advise of appropriate mailing list if you think th=
is
> > doesn't fit here)
> >
> > I am looking into supporting CRD for GNOME/wayland. CRD would be levera=
ging
> > remote desktop APIs (along with screencast) as exposed by xdg-desktop-
> > portal{,-gnome}. While experimenting with remote desktop APIs, I see th=
at for
> > enhanced security, an interactive dialog (relevant code:
> > https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src=
/screencast.c#L345-349
> > ) is always presented to the user to select sources/devices they want t=
o allow
> > to be remote controlled. Though this workflow would make perfect sense =
when a
> > user is directly connected to the machine and is allowing someone remot=
e to
> > take control (e.g. to get help from IT) but it is less than ideal for a=
 user
> > who is trying to access their own machine remotely (e.g. accessing thei=
r work
> > computer from home).
> =

> If you visite the screenshare configuration panel, you have two choices,
> interactive or password driven. The second is non-interactive. The visual
> addition telling the user that the display/screen/window is share does no=
t seems
> like a problem to me, but indeed possibly make a bit less sense outside of
> remote support kind of use case.
> =

> >
> > I would like to hear ideas from the GNOME community about how to best s=
upport
> > the latter use case for remote desktop. Is there a secure way to bypass=
 the
> > dialog/prompt selectively for apps? There seems to be recent support for
> =

> Note that VNC/password in that context is not very secure, should likely =
be used
> in local and controlled network. But this is specific to VNC and might no=
t be
> relevant what you suggest.
> =

> > restoring the capture streams (if persistence was demanded previously b=
y the
> > user) using flatpak permission
> > store:https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_r=
equests
> > /14 but remembering streams for remote desktop session is explicitly
> > disallowed in the portal frontend
> > (https://github.com/flatpak/xdg-desktop-portal/blob/master/src/screen-c=
ast.c#L
> > 589-L594 -- though this doesn't seem to be GNOME specific). Is it reaso=
nable
> > to extend the stream restoration support to work for remote desktop ses=
sions
> > as well as pre-populating the permission store to allow remote desktop =
session
> > (so that user intervention can be avoided)? Also, would pre-populating =
the
> > permission store work for system installation of CRD or would only work=
 for
> > flatpak/sandboxed version of the app?
> >
> > Looking at how other software/systems are supporting screen capture/rem=
ote
> > desktop, we see wlroots/sway allows for configuring the output screen to
> > capture in a config file
> > (https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/xdg-des=
ktop-po
> > rtal-wlr.5.scd#description). I believe Windows.Graphics.Capture APIs ca=
n also
> > allow Win32 apps to capture a window/screen without user interaction.
> >
> > Would love to hear thoughts from the community about the best way forwa=
rd.
> >
> > Thanks,
> > Salman
> >
> >
> > _______________________________________________
> > desktop-devel-list mailing list
> > [email protected]
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> =



> _______________________________________________
> desktop-devel-list mailing list
> [email protected]
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list