Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)

Thomas Lübking thomas.luebking at gmail.com
Wed Oct 12 19:43:41 BST 2011


Am Tue, 11 Oct 2011 21:46:40 -0400
schrieb Michael Pyne <mpyne at kde.org>:
> Yes. KDE asciiquarium (feel free to look at the copyright headers for
> that in kdeartwork someday... ;)
Errr... rather not. The author, *cough* who ever he might be *cough*
has apparently so far not found the time to implement the resize event,
so basically it's the only screensaver hack which can *not* simply be
run in fullscreen mode for sheer entertainment only.
If you happen to meet him and he should actually require guidance in how
to fix that, he may just call back. *cough*

> Yes I do. It's nice to be able to walk away from the computer and let
> my [...] son move the mouse around or watch the
> fish move and know that there's at least a half-decent chance he
> hasn't deleted all my files by the time I got back.
I think we've a fundamental misunderstanding about "screensavers" here.

The thread span off because Torgny questioned "no screensaver w/o
locking" and i replied there's no point in that (since protecting the
screen isn't required and you can just trigger the show yourself to see
it w/o any locking facilities)


What you however describe is
a) locking the account
b) entertaining your son

Both are perfectly reasonable (and just! ;-) demands, but they're
actually orthogonal and esp. different from a screensaver, because
they're triggered explicitly.

You do not walk away and just hope your child won't do any s...tuff
until the screensaver kicks in and -as a side effect- locks the screen,
do you? No. You lock the screen (what as a side effect launches the
undersea show), ensure your son has a good seat and sight and then
leave, right?

Now, the "clean" approach to this would actually be to lock and launch
a new session, but i of course do see the point of a QnD solution that
doesn't require a full new session but just launches sth. on top of the
locker (without /any/ session abilities)
 
This has not been and can not be reasonably questioned (eg. think
of public interfaces showing some information yet provide restricted
access to the system)

The worst thing that actually *could* happen (i don't think so, but the
tech details of a final solution are still discussed in the parenting
thread) is that the locking visuals (w/ compositing, security reasons)
only work as kwin plugin, ie. the asciiquarium would have to be ported
once more.

Cheers,
Thomas




More information about the kde-core-devel mailing list