Feature #10970

Document screen locker

Added by sajolida 2016-01-18 15:18:25 . Updated 2018-03-14 11:12:10 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.6
Start date:
2016-01-18
Due date:
% Done:

100%

Feature Branch:
doc/10970-screen-locker
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

It’s now possible to lock the screen in Tails 2.0 from the keyboard shortcut Super+L. But not yet from the system menu, see Feature #5878.

We should document this. The first step would be to draft a plan. From the top of my head:

  • Where would this go?
  • Shall we document the limitation (no UI)?
  • Is there any other way to lock the screen than the keyboard shortcut?
  • Do we want to mention the security limitations of screen locking?

team: sajolida, spriver

Subtasks

Related issues

Blocked by Tails - Feature #15369: Improve buttons of tails-screen-locker Resolved 2018-03-02

History

#1 Updated by intrigeri 2016-01-18 16:54:41

> * Do we want to mention the security limitations of screen locking?

FTR, having clear warnings about it was a part I found important in the proposal you made and that was agreed on -dev@.

#2 Updated by nukk 2016-02-04 19:20:22

I’d be happy to test and document this (with the appropriate risks known), but the keyboard shortcut mechanism (Control-Alt-L) does NOT work (it does nothing). Is this feature completely disbabled in 2.0 now?

#3 Updated by sajolida 2016-02-05 13:28:43

  • Description updated

Sorry for being unclead in the description of the ticket. The shortcut in 2.0 is Super+L (Super is the GNOME name for the Windows key).

#4 Updated by nukk 2016-02-09 20:07:58

Good. Super-L is working. But what it’s not doing is actually locking the screen. It just goes into a full screen window that I can just scroll out of the way. How do you actually lock the screen?

Sorry for the n00b sounding questions.

#5 Updated by intrigeri 2016-02-09 20:28:04

> Good. Super-L is working. But what it’s not doing is actually locking the screen. It just goes into a full screen window that I can just scroll out of the way. How do you actually lock the screen?

You need to set an administration password in the Greeter.

> Sorry for the n00b sounding questions.

This is exactly why we have a ticket titled “Document screen locking in Tails Jessie”..

#6 Updated by Dr_Whax 2016-08-20 13:24:16

  • Description updated
  • Assignee set to sajolida
  • Target version set to 2016

#7 Updated by sajolida 2016-08-30 03:56:30

  • Target version changed from 2016 to Tails_2.6

We’ll try to do this for 2.6, right?

#8 Updated by sajolida 2016-09-02 07:27:26

  • Target version deleted (Tails_2.6)

The freeze is passed now, so the feature will most probably not be ready for 2.6 and I don’t have to rush to write this documentation \o/

#9 Updated by sajolida 2016-09-02 07:40:06

  • Target version set to Tails_2.6

Actually it will :(

#10 Updated by sajolida 2016-09-04 01:54:37

  • Subject changed from Document screen locking in Tails Jessie to Document screen locker

#11 Updated by intrigeri 2016-09-09 14:47:16

  • Target version changed from Tails_2.6 to Tails_2.9.1

(See Feature #5684#note-54 and Feature #5684#note-55.)

#12 Updated by nukk 2016-09-21 10:13:56

I’m willing to write the documentation if it got into 2.6 (i’m not running it yet, but will shortly), just need a pointer to what to do.

#13 Updated by sajolida 2016-09-22 03:04:26

Thanks for the offer. This didn’t go in 2.6 and will have to wait until 2.8 (2016-12-13) so we have plenty of time :)

If you want to work on this, I recommend:

  1. Get an ISO image that has this feature implemented. Maybe from http://nightly.tails.boum.org/build_Tails_ISO_feature-5684-screen-locker/lastSuccessful/archive/.
  2. Test all of its aspects and take notes (and screenshots) about:
    • The interactions involved.
    • If other things have changed as a consequence of this feature.
  3. Come up with a list of everything that needs to be said or explained about this feature.
  4. See where all this could fit in our documentation.
  5. Share this draft plan with us.

Then I’ll be happy to review it and once we agree on a plan, you can start writing the actual stuff. The preparatory work is the most important part and also the easy, technically speaking, because it doesn’t involve learning ikiwiki, building the website, dealing with Git, etc.

I like this article which talks about a similar process: http://idratherbewriting.com/2015/01/29/writing-is-like-sorting-laundry-practical-advice-for-tackling-documentation-projects/.

#14 Updated by sajolida 2016-11-25 16:56:39

  • Target version changed from Tails_2.9.1 to Tails 2.10

#15 Updated by anonym 2016-11-28 18:38:06

sajolida, do you think it would still be an improvement to potentially ship the screen locker without user documentation? I’m mostly asking because I’m wondering if I should block the merge on this happening.

#16 Updated by sajolida 2016-11-28 20:20:56

> sajolida, do you think it would still be an improvement to
> potentially ship the screen locker without user documentation?

Yes. Undocumented improvements are still improvements. The problem
rather lies on whether we are fine with building up a technical writing
debts by adding undocumented features (though we haven’t been that bad
in the past about slight delays).

> I’m mostly asking because I’m wondering if I should block the merge on
> this happening.

If I understand correctly, the screen locker is planned to be in 2.10
(freeze beginning of January), so we still have plenty of time to
document this. Last time I tried (for 2.6) it ended up being unclear to
me whether the feature was 100% ready and I think I waisted some time on
testing and trying to understand something that wasn’t.

So please tell me when it’s 100% ready, where I can test it, and I’ll be
happy to document it in the for 2.10.

#17 Updated by sajolida 2017-01-12 15:52:38

  • Assignee deleted (sajolida)

#18 Updated by intrigeri 2017-01-19 19:06:40

  • Target version changed from Tails 2.10 to Tails_2.12

#19 Updated by sajolida 2017-02-13 17:52:44

  • Assignee set to sajolida

#20 Updated by sajolida 2017-04-07 15:12:45

#21 Updated by sajolida 2017-04-14 15:18:06

  • Assignee deleted (sajolida)
  • Target version deleted (Tails_2.12)

This won’t happen in 2.12 again.

#22 Updated by intrigeri 2017-04-14 15:40:36

  • Assignee set to segfault
  • QA Check set to Info Needed

Looks like next step is Feature #10970#note-16.

#23 Updated by sajolida 2017-05-02 09:34:02

  • blocked by deleted (Feature #12432: Technical writing core work 2017Q2)

#24 Updated by BitingBird 2017-08-28 20:41:12

  • Assignee changed from segfault to spriver
  • Target version set to 2017

#25 Updated by anonym 2017-12-20 20:17:42

  • Assignee changed from spriver to sajolida
  • Target version changed from 2017 to Tails_3.6

It seems we’ll have the screen locker feature in the next major release, Tails 3.6 on 2018-03-13, so the user docs must be ready for translation by the time bertagaz prepares the RC. There’s no date set for that yet, but we know it will be ~two weeks before that, so let’s say 2018-03-01 (or possibly a few days before that).

Per a private discussion, spriver will try to write the docs until 2018-02-01 and then a backup takes over if needed (with a full month to go). sajolida, can that backup be you? Otherwise, can you find one?

#26 Updated by sajolida 2018-02-01 21:58:49

  • QA Check deleted (Info Needed)

I’ll be excited to write that piece of doc as core work!

#27 Updated by anonym 2018-02-20 12:46:20

In other words, these docs should go into Tails 3.6~rc1 (i.e. merge before 2018-03-01 noon CET). Does this sound possible?

If not, IMHO, the code can be merged without the docs. This feature is pretty self-explanatory and harmless, so the lack of docs does not feel like a strict blocker.

#28 Updated by sajolida 2018-02-20 16:55:05

I want to wait until the code is “Fix committed” before writing the documentation. Right now it’s still “Ready for QA”. Otherwise, yes, I plan to do that before RC1.

#29 Updated by bertagaz 2018-02-24 20:11:43

sajolida wrote:
> I want to wait until the code is “Fix committed” before writing the documentation. Right now it’s still “Ready for QA”. Otherwise, yes, I plan to do that before RC1.

It is now. Is it too late to start documenting this feature? OTOH it’s quite intuitive:

  • if people have not set an administrator password, there’s only a new icon in the main menu (with the shutdown, reboot, settings, bla ones).
    • if they click on that icon, they are asked for an unlocking password, and can refuse (yeah!)
  • if they have set an admin password, they’ll get their screen locked automatically after some inactivity, and if so will just have to type this password.

#30 Updated by sajolida 2018-03-02 19:12:40

  • Status changed from Confirmed to In Progress

Applied in changeset commit:6cc6ac422e6c61ff336e08da1d69ce37c6908763.

#31 Updated by sajolida 2018-03-02 19:15:48

  • Tracker changed from Bug to Feature
  • Status changed from In Progress to Confirmed
  • Assignee changed from sajolida to cbrownstein
  • QA Check set to Ready for QA
  • Feature Branch set to doc/10970-screen-locker

Cody: Do you want to have a look? This is an upcoming feature from 3.6 so the work is based on the devel branch.

My screenshot takes into account that Feature #15369 will be merged as such. If it’s not I’ll make another one :)

#32 Updated by sajolida 2018-03-02 19:16:05

  • Status changed from Confirmed to In Progress

#33 Updated by sajolida 2018-03-02 19:16:22

  • blocked by Feature #15369: Improve buttons of tails-screen-locker added

#34 Updated by cbrownstein 2018-03-04 08:11:01

  • Assignee changed from cbrownstein to sajolida
  • QA Check changed from Ready for QA to Pass

Language looks good. I imagine it’ll stay the same even if a different screenshot is used.

Ref: https://labs.riseup.net/code/issues/15369#note-3

#35 Updated by intrigeri 2018-03-06 14:59:46

  • % Done changed from 0 to 70
  • QA Check changed from Pass to Dev Needed

Please rebase this branch on testing (it’s currently based on devel) so that 1. it builds on Jenkins (Bug #15372); 2. we can plausibly merge it for 3.6 :)

#37 Updated by sajolida 2018-03-08 11:18:06

  • Assignee changed from sajolida to bertagaz
  • QA Check changed from Dev Needed to Ready for QA

I updated the screenshot after Feature #15369.

bertagaz: Can you merge this branch into testing if you are happy with Feature #15369? Otherwise I might have to change the screenshot again…

#38 Updated by bertagaz 2018-03-11 19:51:26

  • Status changed from In Progress to Fix committed
  • % Done changed from 70 to 100

Applied in changeset commit:859d1843c69f649c3e4c287be5107946365813e0.

#39 Updated by bertagaz 2018-03-12 18:39:42

  • Assignee deleted (bertagaz)
  • QA Check changed from Ready for QA to Pass

#40 Updated by bertagaz 2018-03-14 11:12:10

  • Status changed from Fix committed to Resolved