plasma2 and ToolTipManager

[Martin Gräßlin]

On Monday 01 October 2012 15:51:20 Aaron J. Seigo wrote:
> On Monday, October 1, 2012 15:15:23 Martin Gräßlin wrote:
> > Am 01.10.2012 14:46, schrieb Aaron J. Seigo:
> > > the GL texture would be generated and updated by the window manager
> > > but used b
> > > other applications (e.g.the desktop shell). how to address such
> > > textures is
> > > platform specific (windows, mac, x11, etc) but it is a broadly
> > > available
> > > functionality and one _we_ only need to care about on a very select #
> > > of
> > > platforms.
> > 
> > sharing OpenGL textures for the windows is an absolute no-go from the
> > security point of view in Wayland. See also
> > http://community.kde.org/KWin/Wayland_Development with some notes about
> > security I did during XDC.
> 
> btw, the untenability of this "restrict all the accesses by pushing it all
> into the windowmanager because of security" can perhaps be most easily seen
> with this entry on that page:
> 
> "Screenshots need to be restricted to KWin. Solution: move KSnapshot to
> KWin, remove D-Bus interface for Screenshots"
> 
> and gimp? and krita? and .. (IT help desks with existing software solutions
> are going to love this, too)
Please note that this was a quick note and a quick idea taking during a 
presentation about security on windowing systems.

Why does it not mention krita or gimp? Because I did not think about them. I 
don't use such applications, did not know that they allow taking screenshots 
and only thought of ksnapshot. Later on during the discussion the gimp usecase 
was mentioned and the solution to that is probably having a standardized way 
to ask the compositor for a screenshot.

This interface between applications and compositors would probably require 
from the compositor to ask the user whether he really wants to have the 
screenshot passed to the application: "Krita is requesting a screenshot of 
window foo. Do you agree? (link to userbase explaining the security)"

That is something I personally consider as very annoying, but if we want to 
have the security that malware can not take screenshots of the application and 
fake a user interface, we have to go that way.

It's a solution I consider as sufficient for applications like Krita or gimp, 
but not for something like KSnapshot. There a nag-dialog is extremely stupid 
considering that the user used a global shortcut to trigger the interface.

When I wrote down that note I considered that the handling of global shortcuts 
is anyway moved to KWin (has to be like that in Wayland to prevent keyloggers, 
most likely will have a common architecture splitted out of Weston), that 
currently all the screenshot taking for a window is already done by KWin and 
that actually all that remains in ksnapshot is the UI and saving to 
file/export.

It just seemed logical to me, that we take that as a service into the 
compositor to simplify the code in both KWin and KSnapshot. If you look at the 
fact that KWin currently contains 300 lines of code just for KSnapshot and 
KSnaphot even more to handle the cases:
* X11 no KWin support
* X11 KWin support
* Wayland support
it just seemed more logical to me to properly simplify it by having a unified 
codebase.

Of course if there is a screenshot interface (again the note that this was 
mentioned after I had written down the note) it's as fine to start ksnapshot 
and make it a recognized process.

But overall with my current knowledge of the system I would say that it's most 
useful to move KSnapshot into KWin.
> 
> try explaining to the owner of a laptop that they can no longer take
> screenshots except through the Desktop Environment Approved and Mandated
> user interface. "It's for your own good, security after all..."
note: it might be possible to have a screenshot interface.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121001/a5ed9a28/attachment-0001.sig>