Re: Chrome Remote Desktop Support for GNOME/Wayland

--===============9074742150135375882==
Content-Type: multipart/alternative; boundary="=-B1NZ1JAOlSmTCrFWQc3u"

--=-B1NZ1JAOlSmTCrFWQc3u
Content-Type: text/plain; charset=us-ascii; format=flowed

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 +0000, S . via desktop-devel-list 
<[email protected]> 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 
> <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 
> <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
> 
> 


--=-B1NZ1JAOlSmTCrFWQc3u
Content-Type: text/html; charset=us-ascii

<div id="geary-body" dir="auto">Hello Salman,<div><br></div><div>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.</div><div><br></div><div>Our Discourse instance is hosted at&nbsp;<a href="https://discourse.gnome.org/">https://discourse.gnome.org/</a></div><div><br></div><div>Regards,</div><div>Christopher Davis</div></div><div id="geary-quote" dir="auto"><br>On Tue, Jan 25 2022 at 04:30:26 PM +0000, S . via desktop-devel-list &lt;[email protected]&gt; wrote:<br><blockquote type="cite">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>


<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
Hi All,</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
<br>
</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
(Please feel free to advise of appropriate mailing list if you think this doesn't fit here)</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
<br>
</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
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: <a href="https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/screencast.c#L345-349" id="LPNoLPOWALinkPreview">
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/screencast.c#L345-349</a>) 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).</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
<br>
</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
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:
<a href="https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/14" id="LPNoLPOWALinkPreview_1">
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/14</a> but remembering streams for remote desktop session is explicitly disallowed in the portal frontend (<a href="https://github.com/flatpak/xdg-desktop-portal/blob/master/src/screen-cast.c#L589-L594" id="LPNoLPOWALinkPreview_2">https://github.com/flatpak/xdg-desktop-portal/blob/master/src/screen-cast.c#L589-L594</a>
 -- 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?</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
<br>
</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
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 (<a href="https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/xdg-desktop-portal-wlr.5.scd#description" id="LPNoLPOWALinkPreview_1">https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/xdg-desktop-portal-wlr.5.scd#description</a>).
 I believe Windows.Graphics.Capture APIs can also allow Win32 apps to capture a window/screen without user interaction.</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
<br>
</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
Would love to hear thoughts from the community about the best way forward.</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
<br>
</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
Thanks,</div>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
Salman<br>
</div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview_1 _EReadonly_1"></div>
<br>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: rgb(54, 96, 146);">
<br>
</div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>


</blockquote></div>
--=-B1NZ1JAOlSmTCrFWQc3u--


--===============9074742150135375882==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============9074742150135375882==--