Re: [Tails-dev] screen locker tutorial

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] screen locker tutorial
Hi,

sajolida wrote (08 Dec 2015 11:59:54 GMT) :
> intrigeri:
>> sajolida wrote (07 Dec 2015 18:22:46 GMT) :
>>> Is it safe to lock the screen this way in Tails?
>>
>> Given my results on #9408, it seems that it is. Before assessing this
>> I'd like to go through #5684, its subtasks and blueprint to make sure
>> we didn't forget anything, though. I guess it's on my plate as
>> a side-effect of porting to Jessie ⇒ I'll do it and report back here.


Done, looks sane to me (modulo the "false sense of security" argument,
of course: physical access still gives an attacker a lot of power; we
have lots of good plans to improve things in this area, but some
problems simply can't be fixed by the operating system, and we often
lack manpower when it comes to hardening Tails).

> I'll have a look as well since I'm the one who volunteered for the
> "screen locker" on our roadmap for 2017.


Cool :)

> From the subtasks I think:


> - #5878 "Add a lock screen action to the shutdown button" should be
> closed as we don't have the shutdown button anymore in Jessie.


Well, it's the same problem to solve, and exactly the same solution,
technical implementation details put aside (s/shutdown button/system
menu/); it's also the place where the work already done in this area
(for GNOME Shell) is referrenced. So, instead of replacing this ticket
with a new one, I've repurposed it.

> - #6017: "Ensure that the emergency shutdown works while the screen is
> locked". I tested that and it works on Tails Jessie. Do we need anything
> else? Automated tests?


Thanks for testing. I've no idea when the problem this ticket was
referring to was current, but I suspect it dates back to Squeeze area
or similar ⇒ IMO it's not worth writing + maintaining + running
a regression test. So I think that this ticket can simply be closed.

> From the blueprint:


Meta: here I'm merely trying to make sure the current state of the
devel branch is not crazy, and to provide pointers for anyone who want
to handle the technical side of things here: #5684 still needs
developers, as this thread confirms.

> - The "How to activate it?" section should be updated to Jessie.


> - Automatically after X minutes of idle: This is not the case in Tails
> Jessie. The screen is only blanked. Shall we discuss this further?


I bet this is because we explicitly disable the lock screen in our
configuration (hence Benjamin's dconf command). Maybe one of those
would help:

    gsettings set org.gnome.desktop.lockdown disable-lock-screen false
    gsettings set org.gnome.desktop.screensaver lock-enabled true


(I did both and after N idle minutes the screen locked.)

> - When closing the lid: This doesn't work.


We have:

[org/gnome/settings-daemon/plugins/power]
lid-close-ac-action = 'blank'
lid-close-battery-action = 'blank'

... which may explain the behaviour you see.

> Shall I create a ticket?


Yes, please. Can be useful whenever someone wants to work on this :)

> - The "Which password to use?" is still relevant and I propose to create
> a ticket for that under #5684, unless you prefer creating another ticket
> for "Screen locking without administration password" as this might take
> more time to get implemented.


Isn't this what #8383 is about?

> Shall I also create a ticket to write automated tests for all this?


Sure.

>> And then it would be awesome if someone reintroduced the code we
>> removed in #8316 (display a Lock Screen button in the Shell's
>> top-right menu), after making it conditional to having an admin
>> password set.


> Shall I create a ticket for that too?


I think that #5878 should do the job just fine.

>>> My second question:
>>
>>> If gnome-screensaver remains in Tails Jessie, do we want to document
>>> this (with all the due warnings for people without an administration
>>> password) or do we think it will encourage people to set up an
>>> administration password when they don't need to and we don't want to do
>>> that?
>>
>> I think it would be great to document it, but not a blocker for 2.0 as
>> long as the only UI is a keyboard shortcut.


> Agreed.


I'll let you judge if it's worth a ticket.

>>> And the third one:
>>
>>> If gnome-screensaver remains in Tails Jessie, are we OK with the current
>>> UX for people with no password (blanking the screen but not locking it)?
>>
>> I'd rather disable it but I can live with it. See earlier discussion
>> on this topic: https://labs.riseup.net/code/issues/10403#note-3


> Meta: it's often hard for me to extract information from tickets like
> these and be sure that I sorted out correctly the relevant information
> from all the rest that I don't understand.


Got it, and I'm sorry. Merely dropping such a link sucks, even on
a development mailing-list. Since I read this a month ago, I've
started to try and be more careful, e.g. to point to the specific
excerpts I want _you_ to look at.

> I understand from this one that the automatic screen blanking (and not
> locking) is activated in Tails Jessie by default.


Right.

This, and the part of the discussion that lead us to leave it as-is:
"we should just disable screen blanking entirely, as it provides
a false belief of security" (intrigeri) → "Locking, yes, but screen
blanking is still desirable for some, I guess. E.g. to save battery or
whatever" (anonym).

> This conflicts with the current blueprint goals "activate
> automatically after X minutes of idle".


I don't understand why. Please explain if you think it's worth it.

Cheers!
--
intrigeri