Bug #12093

Feature #5464: Revamp Greeter interface

Feature #8230: Greeter revamp: Phase 1

Missing "Read only" option for persistence in new Greeter

Added by intrigeri 3 months ago. Updated 10 days ago.

Status:RejectedStart date:12/28/2016
Priority:ElevatedDue date:
Assignee:-% Done:

0%

Category:Persistence
Target version:Tails_3.0
QA Check: Blueprint:
Feature Branch: Easy:
Type of work:Communicate Affected tool:Greeter

Description

As the attached video shows, the new Greeter doesn't seem to allow unlocking a persistent volume in read-only mode. Is that by design and on purpose?


Related issues

Related to Tails - Feature #12055: Update test suite for Greeter revamp, phase 1 Resolved 12/21/2016
Related to Tails - Feature #12361: Document the removal of read-only persistence Confirmed 03/17/2017

Associated revisions

Revision 90b8b989
Added by anonym about 2 months ago

Test suite: drop usage and tests of read-only persistence.

We won't have it in Tails 3.0~beta1 since the Greeter doesn't have
that option, and it's not even sure we'll reintroduce it since it's
apparently quite buggy and not widely used.

Will-fix: #12055
Refs: #12093

History

#1 Updated by intrigeri 3 months ago

  • Blocks Feature #12055: Update test suite for Greeter revamp, phase 1 added

#2 Updated by alant 3 months ago

intrigeri wrote:

As the attached video shows, the new Greeter doesn't seem to allow unlocking a persistent volume in read-only mode. Is that by design and on purpose?

That's a good question... and I think that the answer is unclear. Read-only persistence was not in the final mockups that were agreed for implementation (https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/#index2h3):

But it was not totally removed by design. The clearest messages I found about it are a Tails-UX discussion of september 2014 (https://mailman.boum.org/pipermail/tails-ux/2014-September/002231.html):

And I suggest again to move the "Read only" option elsewhere (in
advanced options). I don't know anybody using it.

We already dismissed that option because there are real usecases (e.g.
needing to have access to its keyrings but wanting to keep the option
to shutdown Tails by removing the USB stick without loosing data).

Having "real usecases" for some option is not a good argument for having
it on the first screen. There are serious use cases for all the options
in the advanced screen as well. The question here is rather a question
of priority: we need to find a balance between having as little things
on the first screen as possible, but still cover the vast majority of
use cases.

I'm pretty sure that the "read-only" option is less popular than the
"Windows camouflage" for example, or the "Tor bridge mode".

And regarding "prioritizing the best impact", I think that the read-only
option fits in the category of "few users frequently" at most. And for
me that goes on the "advanced" screen.

My only doubt is that it would be an option related to persistence that
would appear in other place than the "Enable persistence" options... But
I believe that this slight argument against this proposal is
counterbalanced by the advantage of getting a more straightforward
screen for the vast majority of uses.

So we could add this to advanced options in case there is persistence in the media, something like "Read-only encrypted storage : When encrypted storage is unlocken, only allow read-only access to it" or something like that...

What do you think?

#3 Updated by intrigeri 3 months ago

Read-only persistence was not in the final mockups that were agreed for implementation

OK, good to know.

But it was not totally removed by design.

"Interesting".

So we could add this to advanced options in case there is persistence in the media, something like "Read-only encrypted storage : When encrypted storage is unlocken, only allow read-only access to it" or something like that...

What do you think?

I'm not going to engage in this UX discussion here, so I'm going to raise the question on tails-ux@.

#4 Updated by intrigeri 3 months ago

  • Assignee changed from alant to intrigeri
  • Type of work changed from Code to Communicate

#5 Updated by intrigeri about 2 months ago

  • Blocks deleted (Feature #12055: Update test suite for Greeter revamp, phase 1)

#6 Updated by intrigeri about 2 months ago

  • Related to Feature #12055: Update test suite for Greeter revamp, phase 1 added

#7 Updated by intrigeri about 2 months ago

Given https://mailman.boum.org/pipermail/tails-ux/2017-January/003331.html we won't block on this for #12055 as far as 3.0~beta1 is concerned. Deadline for a final decision (+ consensus on mockups if applicable) is March 16.

#8 Updated by intrigeri about 2 months ago

  • Priority changed from High to Normal

#9 Updated by intrigeri 11 days ago

  • Priority changed from Normal to Elevated

#10 Updated by alant 10 days ago

  • Status changed from Confirmed to Rejected
  • Assignee deleted (intrigeri)

sajolida wrote on tails-ux mailing list:

My gut feeling was that we could remove it and focus on issues that are affecting better identified scenarios and more users.

Still, I did some stats on the WhisperBack reports received in 2016:

  • 515 had persistence read-write (98%)
  • 11 had persistence read-only ( 2%)
  • 857 had no persistence

4 reports were from m...@r...:

  • a0e7629b892236bfc0e07feafaa78211_-_2016-08-20_1756.asc
    Explaining that she uses read-only persistence because some months ago she lost some text in Writer with a read-write persistence and is now scared about loosing text again.
    Later on in the thread she reaches the conclusion that she probably had a faulty SD card or messed up with her setup.
  • 1518328556a7d2ae059327d7dc168c4c_-_2016-08-20_1823.asc
    Asking for how to download files from the Unsafe Browser.
  • 8496e75d58d87aeb165c6da9607e5a42_-_2016-08-20_1830.asc
    Reporting that Icedove does not work with accents in passwords.
    I wouldn't be surprised if Icedove behaved in a weird way when it's file system is read-only. The user stopped answering the thread and didn't lead the ticket to resolution.
  • b25ef0f1966d689be776707676f1978b_-_2016-08-20_1807.asc
    Reporting that the upgrade check files with read-only persistence. I couldn't find an answer from help desk.

2 reports were from l...@y...:

  • 74c7c757a98619acb087fd1166cb6299_-_2016-01-13_1524.asc
    Reporting an error while upgrading to 2.0 RC1
  • bee48a231db757dd227fc65f235a8f61_-_2016-02-13_1555.asc
    Reporting about failed upgrade checks. Unclear if it was related to read-only persistence.

And the 5 other reports:

  • 2627ef58e07c8eacbb72712169491ddd_-_2016-11-25_1238.asc
    Someone reporting a bug with the Places menu when in read-only.
  • 45198ebbf40252424053e17e52a867a7_-_2016-05-31_0847.asc
    Someone asking about how to save the timezone.
  • 6ccf89b9a2fedcce0f6395ccc6dfeda_-_2016-05-22_0113.asc
    Someone reporting that KeePassX is not read by Orca.
  • 9fdb35786b54572887b2698bc05801a5_-_2016-11-23_0304.asc
    Someone reporting about the absence of on-screen keyboard in Greeter.
  • f94fb83dd61f7f191b4d0b4995327c82_-_2016-03-25_0621.asc
    Reporting problems with super custom persistence: ~/.config, ~/.cache.

So from these 11 reports, 4 were from someone using read-only when she really shouldn't (m...@r...), 3 were about stuff that otherwise work well with read-write persistence (74c7c75, bee48a2, 2627ef5), 1 was from someone who's trying hard to shoot herself in the foot (f94fb83).

We're left with 3 reports that would otherwise come from people who might have a good reason to be in read-only and are not complaining about its malfunctioning. I didn't take the time to sanitize as well the number of reports from people with read-write persistence, so we cannot compare this number of 3 with anything else to judge the portion of users relying on read-only for good reasons. But seeing that:

  • The most vocal user was actually using read-only while she actually shouldn't have and ran into other problems as a consequence.
  • The absolute number of 3 is extremely small.
  • We don't have solid user scenarios ourselves to defend this feature.

I'm also in favor of removing it for the time being.

intrigeri, spencer and me seems to aggre with this. I'm thus rejecting this issue.

#11 Updated by alant 10 days ago

  • Related to Feature #12361: Document the removal of read-only persistence added

Also available in: Atom PDF