Tails

#1 Updated by aboules 2014-01-17 04:20:44

good idea, my nordish friend. But thought too short.
A user friendly product rather allowed the user to change kb layout (screen resolution, …) ‘just in time’ and saved that to persistence.

#2 Updated by aboules 2014-01-17 04:39:43

@liveusb-creator
Besides that it is ridiculous to implicate a security risk for a Norwegian who has norwegian kb layout on his stick:
If you supported a /etc/rc2.d script to run /home/amnesia/Persistent/startup/startup.root (using sudo*) and /home/amnesia/Persistent/startup/startup.user
anything was encrypted.

• needs a /etc/sudoers.d/zzz_startup

#3 Updated by intrigeri 2014-01-17 06:32:28

> Besides that it is ridiculous to implicate a security risk for a Norwegian who has
> norwegian kb layout on his stick:
> If you supported a /etc/rc2.d script to run
> /home/amnesia/Persistent/startup/startup.root (using sudo*) and
> /home/amnesia/Persistent/startup/startup.user
> anything was encrypted.

First, Redmine is not the preferred place to discuss development of
new features with other Tails developers. The tails-dev@boum.org
mailing-list is.

Second, the general idea of running scripts at login time was
mentioned a few times on IRC recently (no idea if this was the same
person insisting, or something else). I’ve replied several times that
1. this idea has important security implications, and requires quite
some thought, starting with: who has write access to
/home/amnesia/Persistent/startup/startup.root? 2. it would be good
if someone sent a good design + security discussion to
tails-dev@boum.org about it. Else, likely nothing will happen.

#4 Updated by aboules 2014-01-17 12:59:58

jesus! intrigeri!

you (or s/o in #tails) pointed me here.
You do not need to care about r/w permissions (or anything else) of ppl not using your bleeding tails bc it is too inconvenient!
Make that bleeding Tails usable to users!

#10 Updated by BitingBird 2015-04-10 15:58:13

Do we still want to do that? If we persist the language in clear, do we need to do so at install, or can it wait until the first boot?

#11 Updated by intrigeri 2015-04-11 10:04:25

> Do we still want to do that?

I think so.

> If we persist the language in clear, do we need to do so at install, or can it wait until the first boot?

On first boot, the system partition is read-only (see the “a” in “Tails” :)

It might be that the Greeter revamp process leads us to revisit that, at least in theory, but I’m not aware of anyone working on technical solutions to this problem => in the meantime, I’m considering that doing this at installation time is still the most realistic way to go.

#12 Updated by sajolida 2015-04-14 16:22:51

> On first boot, the system partition is read-only (see the “a” in “Tails” :)
>
> It might be that the Greeter revamp process leads us to revisit that, at least in theory, but I’m not aware of anyone working on technical solutions to this problem => in the meantime, I’m considering that doing this at installation time is still the most realistic way to go.

Despite the “a”, I’m not sure to understand what you mean. The mockups
for the new Greeter have included an option to remember the language
settings from there for at least 6 months (probably more than 1 year)
and I know that you’ve seen them.

For example https://tails.boum.org/blueprint/greeter_revamp_UI/#index2h2

• If it is realistic to have this in the Greeter, then I think it would
  be a better suited place.
• If it is not realistic to have this in the Greeter, then this should
  be clearly notified to the people working on the new design and they
  will stop waisting their time trying to design an interface to do that…

#13 Updated by intrigeri 2015-04-15 07:26:05

We’re not putting the same meaning behind “realistic” here, which I believe has lead to some misunderstanding.

I believe that having that option in the Greeter is realistic… it just needs someone to do it. I’m aware someone is committed to implement the new Greeter design, but I have no idea if this commitment includes solving the (potentially hard) technical “the system partition is read-only” problem. Besides, the person who’ll be working on the GTK implementation aspects isn’t very experienced in this other field. Hence my reluctance to assume “oh yeah, no problem, it’ll be done”.

#14 Updated by sajolida 2015-04-15 16:54:46

Fully understood, now indeed.

#18 Updated by sajolida 2015-10-20 08:34:42

To add some more to the discussion, doing this at installation time would leave open the UX problem of changing this setting. Let’s say you’re using Tails to use public computers while travelling but they present different keyboard layout.

#20 Updated by intrigeri 2015-10-23 08:29:22

> To add some more to the discussion, doing this at installation time would leave open the UX problem of changing this setting. Let’s say you’re using Tails to use public computers while travelling but they present different keyboard layout.

The proposed user story seems to take this into account already: “I should be proposed to choose another language and keyboard layout in tails-greeter, still”. Which might invalidate “the conflict between installation vs Greeter” you’ve seen, and the follow-up Redmine changes. I’ll let you check the ticket description again and judge.

#21 Updated by sajolida 2015-10-24 03:56:34

There are two different things in the description of the ticket, one is “once for all” which I understand is proposed to happen in Tails Installer. And the second that you pointed out is “choose another language and keyboard layout in tails-greeter” which implies that this is not made persistent (also linked to the technical limitation that you pointed out in Feature #5501#note-13. I have a problem with this and I think that people should be able to change or erase whatever they made persistent “once and for all”.

It make sense to let them do this always from the same place (more consistent for them, probably less work for us). In my opinion, this would ideally be in Tails Greeter, but could as well be Tails Installer if we don’t do that in Tails Greeter for whatever reason.

Still, we didn’t put this in our roadmap for 2016-2017 (maybe that’s a mistake) but this should anyway be discussed again more in depth, both the UX and the implementation, when we have people availble to tackle this.

#22 Updated by intrigeri 2015-10-31 10:08:44

Thanks for clarifying! I think we agree on mostly everything. I could not forbid myself to think about it, so I’ll sum up the pros/cons I’ve found, in the hope it saves us time when we come back to it later. I think we’ll have to choose between:

a) Go straight to a Greeter-only approach, that works for picking the default, saving it, and choosing one-time exceptions

b) Do the first iteration that’s in the ticket description, and later do (a).

In favour of (b):

• it would be a tremendous improvement for many users, compared to the current situation;
• it’s a lot cheaper and thus much more likely to happen soon: as opposed to (a), it’s a simple matter of Python + GTK programming, that could be suitable for new or occasional contributors, so perhaps it can be done without adding tons of process and overhead around; and it’s such a tiny incremental change compared to what we have now that it doesn’t need (IMO) to block on our lack of UX people, if a coder among us feels like doing it as useful procrastination task one of these days (in practice it’s copying the language/region/formats UI from the Greeter into the Installer, and having the Greeter default to the settings saved by the Installer);
• most of the work needed by (b) is needed for (a) anyway, so even if we want (a) some day, having done (b) first will be a good start;
• with (b), the worst case situation caused by the “once for all” aspect (i.e. “I picked the wrong language at install time so I have to pick the one I want every time I start Tails”) is essentially the same UX that all non-English speakers have to go through right now; in that sense it can be argued that it’s not a regression.

In favour of (a):

• it can be argued that yes, it’s a UX regression that with (b) one can choose something once for all but not easily modify it in a persistent manner later on (I can feel that it’s different than “defaulting to English without having had any choice”, but have a hard time phrasing why);
• if we really want to go through the full UX design + evaluation etc. process even for (b), then doing the entire change once for all is cheaper;
• a (small) part of the work needed for (b) is wasted once we do (a), so better make up our mind and do (a) directly rather than going for an incremental approach;
• doing (b) removes some of the pressure to do (a) so we’ll never do it.

I’ll stop it here, before I spend more time on it than it would take me to just implement (b) ;)

#23 Updated by sajolida 2015-11-01 07:20:40

I’m fine with both. I don’t think that (b) needs a serious UX process. It’s a tiny and temporary improvement and we can document a workaround to modify these setting later on.

I’ll also check with Alan what’s he’s view on (a).