Project

General

Profile

Feature #9554

Explain how to set an administration password instead of asking for one when none is set

Added by tailor over 4 years ago. Updated over 1 year ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
06/10/2015
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

When the user tries to perform an administration task (mounting internal disks, installing packages, etc.) she is asked for the administration password which might not have been set.

So she's asked a question that has no possible answer. She needs to go find in the the documentation the relevant section to understand what this weird behavior is about.

We shouldn't ask for a password that doesn't exist.

Instead of displaying a password prompt, we could display a message explaining that this feature is not available unless you set up an administration password when starting Tails (and this for security reasons). This would:

- Allow for learnability of what the administration is used for and how to set it.
- Fix this problem for all administration tasks
- Match the mental model of advanced users

We now need to investigate how this is possible to do.


For example, in the case of mounting local disks. Here is the discussion which lead to this idea:

I am using Tails DVD burnt on a DVDRW without administrator privileges.

Even though I have no access by default, it seems to the local hard drive its presence is shown in both Nautilus file manager and Disk Utility.

From the point of view of security (should there ever be a successful, malicious hacking attack) is it possible and advisable to hide their presence under Devices in file manager and thence eliminate the need for the superuser authentication dialog box?

In Disk Utility the hard drive is also shown under Local Storage with many disk functions such as Mount, Format Volume, Check Filesystem, Edit Filesystem Label, Edit Partition, Delete Partition shown. Not sure if these are available without the disk being mounted and have not been game to click on them to see. The buttons do however change when highlighted with the mouse giving the impression that they are active and accessible. Only tried Mount Volume with the expected authentication window being shown.

For the same reason as above (safety, security and reassurance) is it possible to hide the hard drive whilst in non admin boot since if the functions are not activated in this mode and only available when booting as an administrator with the local drive/s mounted there seems little sense and logic in displaying them. If a user wanted to view the status of their local hard drives and use these functions then it is simple enough for him/her to reboot with admin privileges to have access to them.


Related issues

Related to Tails - Bug #11013: Consider removing applications that require administration password from menu if no password is set Resolved 01/27/2016
Related to Tails - Bug #15830: Use a username that makes more sense to our users Confirmed 08/21/2018

History

#1 Updated by BitingBird over 4 years ago

  • Status changed from New to Rejected

Hiding the disks would be a really bad user interface, and we would get many questions from users that would be lost.

We have a good documentation that explains why and how to access (or not) the hard disk: https://tails.boum.org/doc/encryption_and_privacy/your_data_wont_be_saved_unless_explicitly_asked

They are shown, but can't be mounted if you're not root, so I don't see the risk there. I, however, see the risk in forcing people to boot with admin password just to see things: it's always bad to use increased privileges.

#2 Updated by tailor over 4 years ago

Hello again BitingBird

"Hiding the disks would be a really bad user interface, and we would get many questions from users that would be lost."

Really don't see the problem there. LPS does it (or something similar) with no adverse effect on their user interface and it probably is one of their major "selling points". To my way of thinking as a user I don't need superfluous facilities that have no use to me, that have no objective and having the local drives shown in "safe mode" contrary to your opinion is a sign of bad design and usability. Redundancy is the key concept here.

As far as users are concerned it would simply be a question of re-educating them by placing the emphasis in your documentation on the safety aspects of using the DVD in the default "safe mode". I see no reason why the document you refer to could not be renamed "Tails live system by default boots in safe mode" which to me seems more descriptive and to the point while actively promoting the "safe" aspects in its use without root privileges and as the preferred and recommended boot option.

Then to go on and explain what "safe mode" means and give reasons as to why allowing access to hard drives is not a good idea, is forbidden, disabled and therefore not displayed and then as you do offer the alternative should a need arise for it.

I for one in the past probably because I failed to read and understand the documentation erroneously and mistakenly thought that signing on with an admin password offered me more security and protection when in fact the opposite probably applies and possibly led to unscrupulous operators gaining access to my private data. And I would venture to say that I probably may not be the only one to have done so.


"They are shown, but can't be mounted if you're not root, so I don't see the risk there."

Apologies in advance if you choose to consider the following as insulting. You don't make sense and your argument is illogical.

It's not a question of risk but of consistency. If there is no risk and no availibity, why offer the choice if by default the facility is not available? IMO it makes no sense at all. I would go further and argue that hiding the internal drives to be more consistent with your goals and objectives than to show them.


"I, however, see the risk in forcing people to boot with admin password just to see things: it's always bad to use increased privileges."

To see what things precisely? But you're revealing information that has nothing to do with the operation and use of the system in "safe mode" with the Disk Utility which I think is what you are referring to.

It states in the article you refer to "Tails doesn't need to use your hard disk during the whole session. Be your hard disk absent or damaged, it wouldn't prevent your computer to start Tails." - so why even offer users information about it? It's irrelevant, extraneous and inappropriate.

IMO the Disk Utility is a dangerous tool that should only be made available to root particularly in view of the potential harmful and damaging effects the use of its functions offer to the untrained, inexperienced and adventurous user.

Furthermore IMO, I would consider it even worse practice to have these functions seemingly available as I stated before by being highlighted when the mouse goes over the buttons. Far better and consistent with good practice interface design, if you still choose to make the local drives thing shown (in safe mode) is to have them greyed out so that there is no ambiguity about their availability.

Better still IMO would be to withdraw as with the file manager any reference to hard drives since access to them is impossible and redundant.

BTW I am offended and insulted that you chose to REJECT my suggestions as opposed to opening them to discussion. (only joking)

#3 Updated by intrigeri over 4 years ago

It's not a question of risk but of consistency. If there is no risk and no availibity, why offer the choice if by default the facility is not available? IMO it makes no sense at all. I would go further and argue that hiding the internal drives to be more consistent with your goals and objectives than to show them.

I can see your consistency point, that I would rephrase in my own words as "one should not even see what they won't be able to access anyway"; when I zoom in on it, it totally makes sense to me -- thanks for clarifying.

On the other hand:

  1. there's this nice thing called discoverability, that's a pretty useful UX feature:
    1. as a user, if I want to access my internal hard drive, and when I try to do so in GNOME Disks I'm asked a password that I don't know, then I have chances to try and learn how to set an admin password;
    2. if, on the contrary, I don't see my hard drive at all, then I may believe that accessing them from Tails is totally impossible, and in turn I may choose to use a more dangerous solution to achieve my initial goals;
  2. keeping on displaying internal drives is free (we already have it); hiding them requires development and long-term maintenance time.

So, it seems to be that we first have to make a UX decision here, regarding the discoverability vs. consistency topic. Feel free to raise this topic on the mailing-list. If someone takes care of leading this discussion there, then I'll adjust this ticket's properties accordingly.

And then, if (and only if) that decision says "we should hide internal drives when no admin password has been entered", then this will become yet another coding task on the todo list; IMO this would be a low priority one (aka. "would be nice to have, patches are welcome but note that nobody on the current team has plans to implement it any time soon") => be prepared to find someone to implement and maintain this feature.

#4 Updated by tailor over 4 years ago

Thanks intrigeri.

Feel free to raise this topic on the mailing-list

Done. It should appear under the heading "Hide internal drives when no admin password has been entered". Never done it before, hope it's OK.

there's this nice thing called discoverability, that's a pretty useful UX feature

Ignorant as to how this works, searched Disconnect.me for example to no effect.

I'm asked a password that I don't know, then I have chances to try and learn how to set an admin password

Presumably in the dialog box that comes up the user would be given an explanation and a link furnished that leads you to the relevant help pages.

May be complicating things.

if, on the contrary, I don't see my hard drive at all, then I may believe that accessing them from Tails is totally impossible, and in turn I may choose to use a more dangerous solution to achieve my initial goals;

Easily resolved as a commentator, not sure though for programmers how easy to implement. This an communications and marketing issue - use the KISS principle and lead people to make sensible decisions based of fact - make sure that your users (specially new ones) are aware of the flexible options accompanied with due precaution. No exaggeration, untruths or meaningless jargon.

In my reckoning protection from intrusions by hackers and other malevolent entities is as important an issue for users if not more so than preserving their privacy and anonymity. It's one of your strong points so make it prominent.

Your home page says Privacy for anyone anywhere - add Safety, Choice and Flexibility

leave no trace on the computer you are using unless you ask it explicitly;

As suggested before something like this may work - The Tails live system provides the best possible protection when booted without administrator privileges since it has no need to access your local hard drives to work - your precious data is safe.

The Tails live system is flexible to your needs. (For experienced users) Logging in as root (/as an administrator) allows you access to your local hard drives to perform a range of administrative tasks - use this with caution.

Hope that helps along with the other suggestions made previously.

#5 Updated by sajolida about 4 years ago

  • Subject changed from Local storage devices displayed- Tails DVD no admin to Do not ask for an administration password when none is set
  • Description updated (diff)
  • Status changed from Rejected to Confirmed
  • Type of work changed from User interface design to Research

#6 Updated by sajolida over 3 years ago

  • Related to Bug #11013: Consider removing applications that require administration password from menu if no password is set added

#7 Updated by sajolida over 1 year ago

  • Subject changed from Do not ask for an administration password when none is set to Explain how to set an administration password instead of asking for one when none is setDo not ask for an administration password when none is set
  • Parent task set to #14568

Renaming to explain better the intention here.

  • As tailor said, we shouldn't ask for a password when none is set and instead explain how to set it.
  • As intrigeri said, for discoverability, it's better to let people see everything that's possible in Tails, even if they can access them and explain how to set a password if they need access.

Alan will investigate a bit further how we could do this as part of #14568.

#8 Updated by sajolida over 1 year ago

  • Related to deleted (Bug #11013: Consider removing applications that require administration password from menu if no password is set)

#9 Updated by sajolida over 1 year ago

  • Blocks Bug #11013: Consider removing applications that require administration password from menu if no password is set added

#11 Updated by sajolida over 1 year ago

  • Subject changed from Explain how to set an administration password instead of asking for one when none is setDo not ask for an administration password when none is set to Explain how to set an administration password instead of asking for one when none is set
  • Assignee set to alant

Alan: Do you want to investigate how this could be possible in GNOME? Without spending too much time, at least check whether that's possible without patching Gtk or something.

If so, then please set a target version. If not, then I think we should remove this from the scope of Additional Software.

#12 Updated by alant over 1 year ago

  • Priority changed from Normal to Low

sajolida wrote:

Alan: Do you want to investigate how this could be possible in GNOME? Without spending too much time, at least check whether that's possible without patching Gtk or something.

I'm gonna do that if I have extra time after the basics are implemented.

#13 Updated by sajolida over 1 year ago

  • Assignee deleted (alant)
  • Priority changed from Low to Normal
  • Parent task deleted (#14568)

We won't do that as part of the first implementation of Additional Software.

#14 Updated by u about 1 year ago

  • Blocks deleted (Bug #11013: Consider removing applications that require administration password from menu if no password is set)

#15 Updated by u about 1 year ago

  • Related to Bug #11013: Consider removing applications that require administration password from menu if no password is set added

#16 Updated by sajolida about 1 year ago

  • Related to Bug #15830: Use a username that makes more sense to our users added

Also available in: Atom PDF