Re: Chrome Remote Desktop Support for GNOME/Wayland

[Jonas Ådahl via desktop-devel-list]

On Tue, Jan 25, 2022 at 06:51:20PM +, 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 visual
> > 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 
> Sent: Tuesday, January 25, 2022 10:24 AM
> To: S . ; desktop-devel-list@gnome.org 
> 
> Subject: Re: Chrome Remote Desktop Support for GNOME/Wayland
> 
> Le mardi 25 janvier 2022 à 16:30 +, S . via desktop-devel-list a écrit :
> > Hi All,
> >
> > (Please feel free to advise of appropriate mailing list if you think this
> > doesn't fit here)
> >
> > I am looking into supporting CRD for GNOME/wayland. CRD would be leveraging
> > remote desktop APIs (along with screencast) as exposed by xdg-desktop-
> > portal{,-gnome}. While experimenting with remote desktop APIs, I see that 
> > 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 to 
> > 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 remote 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 their 
> > 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 not 
> 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 
> > support
> > 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 not be
> relevant what you suggest.
> 
> > restoring the capture streams (if persistence was demanded previously by the
> > user) using flatpak permission
> > store:https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests
> > /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-cast.c#L
> > 589-L594 -- though this doesn't seem to be GNOME specific). Is it reasonable
> > to extend the stream restoration support to work for remote desktop sessions
> > 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/remote
> > 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-desktop-po
> > rtal-wlr.5.scd#description). I believe Windows.Graphics.Capture APIs can 
> > also
> > allow Win32 apps to capture a window/scr

Re: Chrome Remote Desktop Support for GNOME/Wayland

[S . via desktop-devel-list]

Thank you, Christopher! I will post the original message on discourse now.



From: Christopher Davis 
Sent: Tuesday, January 25, 2022 10:27 AM
To: S . 
Cc: desktop-devel-list@gnome.org 
Subject: Re: Chrome Remote Desktop Support for GNOME/Wayland

Hello Salman,

You might want to share this on the GNOME Discourse. Generally the community 
has moved away from mailing lists, and instead questions like these are posted 
to Discourse. This has the benefit of being easier to use and preserving 
conversation history in a nicer format.

Our Discourse instance is hosted at https://discourse.gnome.org/

Regards,
Christopher Davis

On Tue, Jan 25 2022 at 04:30:26 PM +, S . via desktop-devel-list 
 wrote:
Hi All,

(Please feel free to advise of appropriate mailing list if you think this 
doesn't fit here)

I am looking into supporting CRD for GNOME/wayland. CRD would be leveraging 
remote desktop APIs (along with screencast) as exposed by 
xdg-desktop-portal{,-gnome}. While experimenting with remote desktop APIs, I 
see that 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 to 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 remote 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 their work 
computer from home).

I would like to hear ideas from the GNOME community about how to best support 
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 
restoring the capture streams (if persistence was demanded previously by the 
user) using flatpak permission store: 
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/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-cast.c#L589-L594
 -- though this doesn't seem to be GNOME specific). Is it reasonable to extend 
the stream restoration support to work for remote desktop sessions 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/remote 
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-desktop-portal-wlr.5.scd#description).
 I believe Windows.Graphics.Capture APIs can also allow Win32 apps to capture a 
window/screen without user interaction.

Would love to hear thoughts from the community about the best way forward.

Thanks,
Salman


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Chrome Remote Desktop Support for GNOME/Wayland

[Christopher Davis]

Hello Salman,

You might want to share this on the GNOME Discourse. Generally the 
community has moved away from mailing lists, and instead questions like 
these are posted to Discourse. This has the benefit of being easier to 
use and preserving conversation history in a nicer format.


Our Discourse instance is hosted at 

Regards,
Christopher Davis

On Tue, Jan 25 2022 at 04:30:26 PM +, S . via desktop-devel-list 
 wrote:

Hi All,

(Please feel free to advise of appropriate mailing list if you think 
this doesn't fit here)


I am looking into supporting CRD for GNOME/wayland. CRD would be 
leveraging remote desktop APIs (along with screencast) as exposed by 
xdg-desktop-portal{,-gnome}. While experimenting with remote desktop 
APIs, I see that 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 
to 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 remote 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 their work computer from home).


I would like to hear ideas from the GNOME community about how to best 
support 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 restoring the capture streams (if persistence was 
demanded previously by the user) using flatpak permission store: 
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/14 
 
but remembering streams for remote desktop session is explicitly 
disallowed in the portal frontend 
( 
-- though this doesn't seem to be GNOME specific). Is it reasonable 
to extend the stream restoration support to work for remote desktop 
sessions 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/remote desktop, we see wlroots/sway allows for configuring 
the output screen to capture in a config file 
(). 
I believe Windows.Graphics.Capture APIs can also allow Win32 apps to 
capture a window/screen without user interaction.


Would love to hear thoughts from the community about the best way 
forward.


Thanks,
Salman




___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Chrome Remote Desktop Support for GNOME/Wayland

[Nicolas Dufresne]

Le mardi 25 janvier 2022 à 16:30 +, S . via desktop-devel-list a écrit :
> Hi All,
> 
> (Please feel free to advise of appropriate mailing list if you think this
> doesn't fit here)
> 
> I am looking into supporting CRD for GNOME/wayland. CRD would be leveraging
> remote desktop APIs (along with screencast) as exposed by xdg-desktop-
> portal{,-gnome}. While experimenting with remote desktop APIs, I see that 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 to 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 remote 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 their 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 not 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 support
> 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 not be
relevant what you suggest.

> restoring the capture streams (if persistence was demanded previously by the
> user) using flatpak permission
> store:https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests
> /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-cast.c#L
> 589-L594 -- though this doesn't seem to be GNOME specific). Is it reasonable
> to extend the stream restoration support to work for remote desktop sessions
> 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/remote
> 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-desktop-po
> rtal-wlr.5.scd#description). I believe Windows.Graphics.Capture APIs can also
> allow Win32 apps to capture a window/screen without user interaction.
> 
> Would love to hear thoughts from the community about the best way forward.
> 
> Thanks,
> Salman
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list