[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

GitLab Migration User  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #8 from GitLab Migration User  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/wayland/wayland/issues/32.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

--- Comment #7 from Christian Stadelmann  ---
(In reply to Vladimir Stoiakin from comment #6)
> I am not a developer, so my suggestion can be naive.
> What about to use simple password authentication for apps?
> For example, some user wants to record a screencast. He sends a request to a
> compositor with a public API. The compositor allows to do it (if configured
> so), generates a one-time secret password, and draws it in the final screen
> buffer. The user reads the password on the screen, and enters it in the
> program which is going to do the job. With this password the program can
> start recording.
> In this scenario the user knows exactly which program will get access to the
> screen (he relies on the shell which starts user programs), and the process
> of recording can be fully controlled by the compositor.

In the modern world of software development, the goal is to have unobtrusive
"authentication" through implicit actions, at least for compartmentalization on
desktops. Take any application, for example a web browser. Let's assume this
application is somehow confined (e.g. using bwrap/flatpak or running under a
different user ID as on android) and is not allowed to access your files by
default. Sometimes, you want it to get access to your files, e.g. to open or
save a document. This happens through the file chooser: If you choose a file
using the file chooser it is assumed that you want this application to access
the selected document, so access is granted for that file/folder. This is
called a portal.

In case you are interested in this technology, please have a look at
https://github.com/flatpak/xdg-desktop-portal/ and also this great explanation
by Alexander Larsson:
https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/
For the example above, this portal is called FileChooser portal.

This bug report is asking to add an API to the wayland protocol so that clients
(applications) can request to take a screenshot and the compositor / desktop
shell can decide whether to grant this request. It is also (more importantly)
about adding one API for any wayland compositor so that client application
developers don't have to write separate code for every single compositor they
want to support. Btw: xdg-desktop-portal already has an API for a Screenshot
and a ScreenCast portal which may be interpreted as a fix to this bug. It also
fixes the issues raised by Pekka Paalanen in comment #1. See also the comment
#4 by Jonas Ådahl.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

--- Comment #6 from Vladimir Stoiakin  ---
I am not a developer, so my suggestion can be naive.
What about to use simple password authentication for apps?
For example, some user wants to record a screencast. He sends a request to a
compositor with a public API. The compositor allows to do it (if configured
so), generates a one-time secret password, and draws it in the final screen
buffer. The user reads the password on the screen, and enters it in the program
which is going to do the job. With this password the program can start
recording.
In this scenario the user knows exactly which program will get access to the
screen (he relies on the shell which starts user programs), and the process of
recording can be fully controlled by the compositor.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

Jonas Ådahl  changed:

   What|Removed |Added

 CC||jad...@gmail.com

--- Comment #4 from Jonas Ådahl  ---
(In reply to James Henstridge from comment #3)
> This could be detected by comparing stat() information, but that would also
> give false positives when upgrading a running application.
> 
> There's not an obvious generic solution.

There is one, except I only know of GNOME who has the screenshot part
implemented:
https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

--- Comment #3 from James Henstridge  ---
> Afaik, applications can't lie about /proc/[pid]/exe and the compositor could
> use .desktop files from /usr/share/applications for identification (with both
> name and icon).

It is pretty easy to spoof the result of readlink() on /proc/[pid]/exe though. 
With user and mount namespaces, a regular user could bind mount a different
executable over a trusted one before executing it.

This could be detected by comparing stat() information, but that would also
give false positives when upgrading a running application.

There's not an obvious generic solution.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

--- Comment #2 from Christian Stadelmann  ---
(In reply to Pekka Paalanen from comment #1)
> > * The wayland compositor should be able to decide (based on rules or user
> > decisions) whether to allow or deny the request. For this, applications need
> > to have a way to provide information about themselves (like application name
> > and icon) and why they want to take a screenshot/screencast.
> 
> This is the very problem. If an application provides identification info
> itself, it can lie. This is actually the root problem for authenticating any
> privileged actions, and I don't think there exists a commonly agreed
> solution yet.

Afaik, applications can't lie about /proc/[pid]/exe and the compositor could
use .desktop files from /usr/share/applications for identification (with both
name and icon). Also, there could be a flag e.g. in these .desktop files for
allowing screenshots / screencasts.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

--- Comment #1 from Pekka Paalanen  ---
(In reply to Christian Stadelmann from comment #0)
> * Taking screenshots and recording screencasts should be an optional feature.

Right.

> * The wayland compositor should be able to decide (based on rules or user
> decisions) whether to allow or deny the request. For this, applications need
> to have a way to provide information about themselves (like application name
> and icon) and why they want to take a screenshot/screencast.

This is the very problem. If an application provides identification info
itself, it can lie. This is actually the root problem for authenticating any
privileged actions, and I don't think there exists a commonly agreed solution
yet.

A simple solution is to have the compositor itself launch only trusted binaries
(e.g. installed to the system by root, pre-declared as safe), or verifying the
app is such a trusted binary which is somewhat more complicated. However, the
ultimate solution would probably revolve around secured containers, where the
application id is provided by the system, not the app.

Any authenticated application also needs to avoid exploitation. E.g. a command
line tool that captures the whole desktop could be simply launched by a
malicious app.

Giving the user a notification and inferring from user actions whether the
operation was really initiated and accepted by the user would probably go a
long way, but it would also be important to be able to tell the user reliably
which program and for what purpose is trying a privileged action.

> * Applications must handle being denied to take a screenshot/screencast

Definitely.

> * there should be a way to select regions of the screen(s) only. I don't
> care whether this should be implemented on client or server (compositor)
> side.

Server-side. It cannot be client-side for security reasons. The user must be
able to trust that the app is not getting anything outside of the region he
selected.

There is also the choice of per-window vs. from the composite (the whole
desktop).

Someone might also want to see a preview of the screenshot before passing it on
to the application, to verify it does not contain sensitive information by
accident.

Whether screenshooting and screencasting should be a Wayland extension is also
an open question, as you can see from the various implementations.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 98894] Add an API for taking screenshots and recording screencasts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98894

Bug ID: 98894
   Summary: Add an API for taking screenshots and recording
screencasts
   Product: Wayland
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: wayland
  Assignee: wayland-bugs@lists.freedesktop.org
  Reporter: frds...@genodeftest.de

Currently, some wayland compositors have their own screenshot and/or screencast
feature, such as weston. Others, such as gnome-shell, have an additional public
DBus API [1]. For KWin, a similar feature is in the works [2].

This situation is bad because it looks like application developers need to
write a separate implementation for their tools for every desktop shell /
environment. For the sake of simplicity, can you please add one API (probably
an extension to the wayland protocol) for all desktop environments?

[1]
https://git.gnome.org/browse/gnome-shell/tree/data/org.gnome.Shell.Screencast.xml
[2]
https://blog.martin-graesslin.com/blog/2016/11/from-window-killing-to-screenshot/

Some notes:
* Taking screenshots and recording screencasts should be an optional feature.
* The wayland compositor should be able to decide (based on rules or user
decisions) whether to allow or deny the request. For this, applications need to
have a way to provide information about themselves (like application name and
icon) and why they want to take a screenshot/screencast.
* Applications must handle being denied to take a screenshot/screencast
* there should be a way to select regions of the screen(s) only. I don't care
whether this should be implemented on client or server (compositor) side.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs