Project

General

Profile

Feature #10970

Feature #5684: Screen locker

Document screen locker

Added by sajolida over 2 years ago. Updated 6 months ago.

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

100%

QA Check:
Pass
Feature Branch:
doc/10970-screen-locker
Type of work:
End-user documentation
Blueprint:
Starter:
Affected tool:

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 #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


Related issues

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

Associated revisions

Revision 6cc6ac42 (diff)
Added by sajolida 7 months ago

Document the screen locker (Will-fix: #10970)

Revision 21af2973 (diff)
Added by sajolida 7 months ago

Document the screen locker (Will-fix: #10970)

Revision 859d1843
Added by bertagaz 7 months ago

Merge remote-tracking branch 'origin/doc/10970-screen-locker' into testing

Fix-committed: #10970

History

#1 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

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 over 2 years ago

  • Description updated (diff)

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 over 2 years ago

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 over 2 years ago

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 about 2 years ago

  • Description updated (diff)
  • Assignee set to sajolida
  • Target version set to 2016

#7 Updated by sajolida about 2 years ago

  • Target version changed from 2016 to Tails_2.6

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

#8 Updated by sajolida about 2 years ago

  • 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 about 2 years ago

  • Target version set to Tails_2.6

Actually it will :(

#10 Updated by sajolida about 2 years ago

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

#11 Updated by intrigeri about 2 years ago

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

#12 Updated by nukk about 2 years ago

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 about 2 years ago

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 almost 2 years ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#15 Updated by anonym almost 2 years ago

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 almost 2 years ago

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 over 1 year ago

  • Assignee deleted (sajolida)

#18 Updated by intrigeri over 1 year ago

  • Target version changed from Tails 2.10 to Tails_2.12

#19 Updated by sajolida over 1 year ago

  • Assignee set to sajolida

#20 Updated by sajolida over 1 year ago

#21 Updated by sajolida over 1 year ago

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

This won't happen in 2.12 again.

#22 Updated by intrigeri over 1 year ago

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

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

#23 Updated by sajolida over 1 year ago

#24 Updated by BitingBird about 1 year ago

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

#25 Updated by anonym 9 months ago

  • 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 8 months ago

  • QA Check deleted (Info Needed)

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

#27 Updated by anonym 7 months ago

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 7 months ago

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 7 months ago

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 7 months ago

  • Status changed from Confirmed to In Progress

#31 Updated by sajolida 7 months ago

  • 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 #15369 will be merged as such. If it's not I'll make another one :)

#32 Updated by sajolida 7 months ago

  • Status changed from Confirmed to In Progress

#33 Updated by sajolida 7 months ago

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

#34 Updated by cbrownstein 7 months ago

  • 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 7 months ago

  • % 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 (#15372); 2. we can plausibly merge it for 3.6 :)

#37 Updated by sajolida 7 months ago

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

I updated the screenshot after #15369.

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

#38 Updated by bertagaz 7 months ago

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

#39 Updated by bertagaz 6 months ago

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

#40 Updated by bertagaz 6 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF