Hello png,
> Yes, it’s fine now. Also the -dev list archives are back.
>
> I read through the archives to date, and it looks the topics so far have been primarily about user interface isses as opposed to the whole user experience— is that intentional, or just how things have gone so far?
This is simply how far things have gone so far on the list I would say.
We have had some discussions about UX itself at the Tails Hackfest
earlier this year, in particular after Amaëlle Guiton's talk.
One of the outcomes of these discussion were that installing Tails in
particular is too complicated for the average person. And that we should
work on an easier way to download, verify and install Tails.
One of the ideas is thus to rewrite this part of the website, to have a
screencast (we need volunteers for this one btw), and to propose a
Firefox extension which would make the verification easier.
If you have any specific suggestions or ideas, or if you are interested
in contributing somehow to this effort, please do not hesitate to talk
about it :)
> I wanted to bring up a high-level user experience issue driven by the widespread availability of low-cost x86 tablets running Windows and Android. It seems to me that a $100 tablet is cheap enough to dedicate to Tails— so wouldn’t it be useful to allow users to install to an internal drive?
I don't think that Tails should be installed. It is simply not possible,
by design, to ensure that a magnetic drive medium forgets [0] and thus
installing seems out of the question.
However, there is a ticket which aims at investigating how to get Tails
to work on handheld devices [1][2]
But the problem here is a technical one: for now, Tails supports only
x86 processors, and most of these devices use ARM processors instead.
> And of course there should be UI features as needed, such as the default activation of an on-screen keyboard and persisting more user preferences on the assumption that a device with Tails permanently installed is more likely to belong to a specific user.
>
> On another matter, I am curious as to the reasoning for requiring two different passwords for a session in which persistence and an administrator password is desired. Wouldn’t it be easier to use the persistence key as the admin password? Or is there a security problem there?
>From a technical point of view, these passwords can't at should not be
the same. One is the administrator password, which allows you to install
software for a particular session for example, and to accomplish other
administrative tasks. The other one is the password of the encrypted
persistent partition and .. if this partition would have the same
password as the superuser.. your data would not be secure at all anymore :)
Cheers,
u.
[0]
https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Secure
Deletion of Data from Magnetic and Solid-State Memory explains the issue
[1]
https://labs.riseup.net/code/issues/7543
[2]
https://labs.riseup.net/code/issues/6064
