Hi again,
I'm late again, and won't probably be quicker next time... don't expect
quick answers for me for one more month I think.
I reply some of your points below if its not too late.
> >> Spencer:
> >> An auto-prompted walkthrough for the 'Language' section, leaving the
> >> guided configuration experience as an always present link.
> >>
> >
> > Alan:
> > I think that's what we should do, *but* let's make it possible not to
> > have it on the 1st iteration(s).
>
> If there is an auto detect for language preference then the 'Language'
> section can be grouped with the more technical settings, allowing
> 'Storage' to be more prominent[0]. The logic is:
>
> • If the auto detect runs at boot and does not detect a language
> preference then the guided configuration step for 'Language' will
> appear, walking people through selecting, and possibly saving, their
> language preference.
>
> • If the auto detect runs at boot and does detect a language preference
> then the greeter dialog will appear, allowing people to focus on
> configuring storage and/or starting Tails.
>
> In both of these cases the issue of language is addressed before the
> greeter screen we've been discussing ever appears, so it seems
> appropriate to deemphasize the discoverability of the 'Language'
> section.
>
> On the first iteration the greeter loads on boot with the expandable
> 'Settings' section open. The alternative is having no expandable
> section [More on this below].
>
This looks great *while* we actually implement this saved language
setting. That was not necessarily the plan for the 1st iteration of the
greeter, but why not...
> >> When someone wants to edit the settings they are asked to set up an
> >> administrative password. This addresses the security issues
> >> associated
> >> with saving the more technical settings.
> >
> > I don't think that we should do that as there is no such concept of an
> > administrative password in a live amnesic distro like Tails, unless a
> > user choose one, that would be only active for the session.
>
> Though I have to read the persistence documentation more thoroughly,
> doesn't this exclude the passphrase for the encrypted partition, which
> persists throughout multiple sessions? If so, and we have a passphrase
> to access the persistent volume, wont the language preferences be stored
> in this same location? If so, then, to me, we have two user types: 1)
> the administrative user - who saves preferences and uses storage, and 2)
> the passive user - who saves nothing and uses default and/or single
> session preference settings [This designation is solely for argument
> purposes]. If this is the case, then an administrative passphrase is
> what is used to gain access to the persistent volume, right?
>
No. There are two separate sets of privileges:
- the encryption paraphrase that is only used to decrypt the encrypted
partition, if present. I will persist between sessions;
- the administrative password, that can be set whether there is an
encrypted partition of not, and that will *not* persist between
sessions. One can need administrative password (e.g. to install an
additional software) without wanting encrypted storage, and one can
need a persistence storage without wanting to allow any admin access
(more security).
Is that clear?
> Also, .png brought up "make it impossible to know whether persistent
> storage is present".
>
Yes that will probably be implemented at some point.
> Citing TrueCrypt as an example, we could "allow the user to enter a
> specific alternative password that makes the persistent storage appear
> empty, or reveal a small set of innocuous files" in the case that
> "someone is forced to reveal a password".
>
> Basically, will Tails display the presence/absence of storage, or will
> an administrative passphrase form field appear?
>
I guess when that'll be implemented, Tails will always display a
section to unlock encrypted storage *and* a way to create a new one, as
it will be technically impossible to detect whether it already exists
or not.
> > Please share the source files (preferably SVGs) so that I/we can edit
> > them to add graphical examples to our discussion?
> >
>
> Yes. You can find files here[1], let me know if there are any file
> issues.
>
Thanks (I didn't look in detail yet)
> Some questions:
>
> • Close[x] not needed?
> If I boot into Tails, the greeter dialog appears. There is a Close[x].
> If I click it, do I return to the host computer’s boot dialog? Does it
> need to exist? What is the intended function/experience?
>
I don't think it needs to exist.
> • Display/hide configuration settings?
> On the greeter dialog the ‘Settings’ section expands on click and
> displays the ‘Language’ and ‘Privacy’ section contents. If ‘Settings’
> is closed on load, the “Check & Go” intention is lost. If ‘Settings’ is
> open on load, closing the ‘Settings’ section serves no purpose and the
> included privacy settings [the more technical options] might be unwanted
> to some people. If the Settings[x] exists, saving the dialog preference
> could resolve these issues. However, saving the dialog preference might
> be a security issue. Should we keep the Settings[x] or just always
> display the info?
I'm all for always letting the settings expanded and have no expandable
section if we have enough space. The attached mockup seems me really
fine to that extend.
> If we keep the Settings[x] are we saving the dialog
> preference of it being open/closed? If we save the dialog preference is
> the state of the content included?
>
I don't think we want to save the dialog preferences yet, but some
might be saved at some point. Perhaps we'll need three sections of
settings then:
- language, that are saved unencrypted;
- privacy settings that can be saved;
- session settings (that are only relevant for one session).
But all that saving of privacy settings needs more designing that is
not only UX and that should be in my opinion be a 2nd step (else we'll
never release the new greeter...)
Cheers
