Chrome Remote Desktop Support for GNOME/Wayland
"S . via desktop-devel-list" <[email protected]> Tue, 25 Jan 2022 16:30:26 +0000
| Newsgroups | gmane.comp.gnome.desktop |
|---|---|
| Message-ID | <BY3PR19MB48503186F96AF772287A4CD0B95F9@BY3PR19MB4850.namprd19.prod.outlook.com> |
--===============6191310157486441754==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_BY3PR19MB48503186F96AF772287A4CD0B95F9BY3PR19MB4850namp_"
--_000_BY3PR19MB48503186F96AF772287A4CD0B95F9BY3PR19MB4850namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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_BY3PR19MB48503186F96AF772287A4CD0B95F9BY3PR19MB4850namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<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);">
Hi All,</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);">
(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; 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);">
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; 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);">
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; 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);">
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; 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);">
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; 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);">
Thanks,</div>
<div style=3D"font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; col=
or: rgb(54, 96, 146);">
Salman<br>
</div>
<div class=3D"_Entity _EType_OWALinkPreview _EId_OWALinkPreview_1 _EReadonl=
y_1"></div>
<br>
<div style=3D"font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; col=
or: rgb(54, 96, 146);">
<br>
</div>
<div class=3D"_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_=
1"></div>
</body>
</html>
--_000_BY3PR19MB48503186F96AF772287A4CD0B95F9BY3PR19MB4850namp_--
--===============6191310157486441754==
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
--===============6191310157486441754==--