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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
