Re: Chrome Remote Desktop Support for GNOME/Wayland
"S . via desktop-devel-list" <[email protected]> Tue, 25 Jan 2022 18:52:24 +0000
| Newsgroups | gmane.comp.gnome.desktop |
|---|---|
| Message-ID | <BY3PR19MB4850AF1D4547ACC7E65892F1B95F9@BY3PR19MB4850.namprd19.prod.outlook.com> |
--===============5353289777915696380== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BY3PR19MB4850AF1D4547ACC7E65892F1B95F9BY3PR19MB4850namp_" --_000_BY3PR19MB4850AF1D4547ACC7E65892F1B95F9BY3PR19MB4850namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, Christopher! I will post the original message on discourse now. ________________________________ From: Christopher Davis <[email protected]> Sent: Tuesday, January 25, 2022 10:27 AM To: S . <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Chrome Remote Desktop Support for GNOME/Wayland Hello Salman, You might want to share this on the GNOME Discourse. Generally the communit= y has moved away from mailing lists, and instead questions like these are p= osted to Discourse. This has the benefit of being easier to use and preserv= ing 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 <deskt= [email protected]> wrote: Hi All, (Please feel free to advise of appropriate mailing list if you think this d= oesn'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-port= al{,-gnome}. While experimenting with remote desktop APIs, I see that for e= nhanced security, an interactive dialog (relevant code: https://gitlab.gnom= e.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 all= ow to be remote controlled. Though this workflow would make perfect sense w= hen a user is directly connected to the machine and is allowing someone rem= ote to take control (e.g. to get help from IT) but it is less than ideal fo= r 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 suppo= rt 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 fo= r restoring the capture streams (if persistence was demanded previously by = the user) using flatpak permission store: https://gitlab.gnome.org/GNOME/xd= g-desktop-portal-gnome/-/merge_requests/14 but remembering streams for remo= te desktop session is explicitly disallowed in the portal frontend (https:/= /github.com/flatpak/xdg-desktop-portal/blob/master/src/screen-cast.c#L589-L= 594 -- though this doesn't seem to be GNOME specific). Is it reasonable to = extend the stream restoration support to work for remote desktop sessions a= s well as pre-populating the permission store to allow remote desktop sessi= on (so that user intervention can be avoided)? Also, would pre-populating t= he 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 ca= pture in a config file (https://github.com/emersion/xdg-desktop-portal-wlr/= blob/master/xdg-desktop-portal-wlr.5.scd#description). I believe Windows.Gr= aphics.Capture APIs can also allow Win32 apps to capture a window/screen wi= thout user interaction. Would love to hear thoughts from the community about the best way forward. Thanks, Salman --_000_BY3PR19MB4850AF1D4547ACC7E65892F1B95F9BY3PR19MB4850namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; col= or: rgb(54, 96, 146);"> Thank you, Christopher! I will post the original message on discourse now.<= br> </div> <div style=3D"font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; col= or: rgb(54, 96, 146);"> <br> </div> <div style=3D"font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; col= or: rgb(54, 96, 146);"> <br> </div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Christopher Davis <= ;[email protected]><br> <b>Sent:</b> Tuesday, January 25, 2022 10:27 AM<br> <b>To:</b> S . <[email protected]><br> <b>Cc:</b> [email protected] <[email protected]>= ;<br> <b>Subject:</b> Re: Chrome Remote Desktop Support for GNOME/Wayland</font> <div> </div> </div> <div> <div id=3D"x_geary-body" dir=3D"auto">Hello Salman, <div><br> </div> <div>You might want to share this on the GNOME Discourse. Generally the com= munity 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 pr= eserving conversation history in a nicer format.</div> <div><br> </div> <div>Our Discourse instance is hosted at <a href=3D"https://discourse.= gnome.org/">https://discourse.gnome.org/</a></div> <div><br> </div> <div>Regards,</div> <div>Christopher Davis</div> </div> <div id=3D"x_geary-quote" dir=3D"auto"><br> On Tue, Jan 25 2022 at 04:30:26 PM +0000, S . via desktop-devel-list <de= [email protected]> wrote:<br> <blockquote type=3D"cite"><style type=3D"text/css" style=3D"display:none"> <!-- p {margin-top:0; margin-bottom:0} --> </style> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> Hi All,</div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> <br> </div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> (Please feel free to advise of appropriate mailing list if you think this d= oesn't fit here)</div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> <br> </div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(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-port= al{,-gnome}. While experimenting with remote desktop APIs, I see that for e= nhanced security, an interactive dialog (relevant code: <a href=3D"https://gitlab.gnome.org/GNOME/xdg-deskt= op-portal-gnome/-/blob/main/src/screencast.c#L345-349" id=3D"LPNoLPOWALinkP= review"> https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/scr= eencast.c#L345-349</a>) is always presented to the user to select sources/d= evices they want to allow to be remote controlled. Though this workflow wou= ld make perfect sense when a user is directly connected to the machine and is allowing someone remote to tak= e control (e.g. to get help from IT) but it is less than ideal for a user w= ho is trying to access their own machine remotely (e.g. accessing their wor= k computer from home).</div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> <br> </div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> I would like to hear ideas from the GNOME community about how to best suppo= rt 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 fo= r restoring the capture streams (if persistence was demanded previously by the user) using flatpak permiss= ion store: <a href=3D"https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_= requests/14" id=3D"LPNoLPOWALinkPreview_1"> https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/14= </a> but remembering streams for remote desktop session is explicitly disal= lowed in the portal frontend (<a href=3D"https://github.com/flatpak/xdg-des= ktop-portal/blob/master/src/screen-cast.c#L589-L594" id=3D"LPNoLPOWALinkPre= view_2">https://github.com/flatpak/xdg-desktop-portal/blob/master/src/scree= n-cast.c#L589-L594</a> -- though this doesn't seem to be GNOME specific). Is it reasonable to ext= end the stream restoration support to work for remote desktop sessions as w= ell 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=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> <br> </div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(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 ca= pture in a config file (<a href=3D"https://github.com/emersion/xdg-desktop-= portal-wlr/blob/master/xdg-desktop-portal-wlr.5.scd#description" id=3D"LPNo= LPOWALinkPreview_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 captu= re a window/screen without user interaction.</div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> <br> </div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> Would love to hear thoughts from the community about the best way forward.<= /div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> <br> </div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> Thanks,</div> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> Salman<br> </div> <div class=3D"x__Entity x__EType_OWALinkPreview x__EId_OWALinkPreview_1 x__= EReadonly_1"> </div> <br> <div style=3D"font-family:Tahoma,Geneva,sans-serif; font-size:10pt; color:r= gb(54,96,146)"> <br> </div> <div class=3D"x__Entity x__EType_OWALinkPreview x__EId_OWALinkPreview x__ER= eadonly_1"> </div> </blockquote> </div> </div> </body> </html> --_000_BY3PR19MB4850AF1D4547ACC7E65892F1B95F9BY3PR19MB4850namp_-- --===============5353289777915696380== 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 --===============5353289777915696380==--