KEN MCCALL:
> HI Alan,
>
> Inline below . . .
We only do inline here :) Top posting is a pretty bad practice in our
context.
> On Jan 21, 2015, at 03:38 PM, Alan <alan@???> wrote:
>
>> On Wed, 21 Jan 2015 16:39:19 +0000 (GMT)
>> KEN MCCALL <kemccall@??? <mailto:kemccall@icloud.com>> wrote:
>>> Who is the target audience (persona)? An non-technical email user? A
>>> journalist with motivation? (Maybe this has been defined already, but
>>> I'm highly motivated and don't understand some things here).
We never explicitly defined persona for Tails. I think that both your
examples ("non-technical email user" and "journalist with motivation")
are valid for sure. I would also add something about more expert users
needing an environment that's both flexible and feature-full. For
example quite a few Tails contributors do all their work from Tails,
maybe those would be "privacy technologists" or something like that...
I know that people from Tor started defining persona for their website,
but I'm not sure whether they finished this work. You can see that on
their mailing list archives:
https://lists.torproject.org/pipermail/www-team/2014-January/thread.html
If we feel the need to define that more precisely for Tails, then we
might reuse some of their work.
>> "The PELD's target user is the average user in terms of computer
>> literacy; he or she does not necessarily control fully the computer
>> being used. Examples would be a public computer in a library, coffee
>> shop, university or a residence. We assume that the target user does
>> not want to do any of the configurations (at least with respect to
>> security and anonymity) of the various applications and tools used
>> themselves, either because of insufficient knowledge, lack of interest
>> or other reasons. The PELD MUST provide strong anonymity with no need
>> of advanced configuration whatsoever. It MUST be made as difficult as
>> possible for the user to unknowingly compromise anonymity."
>
> Kind of what I figured. On a side note, the sentence "It MUST be made as
> difficult as
> possible for the user to unknowingly compromise anonymity." seems out of context
> for the section 2.1.5 Target user.
Indeed.
>>> "Persistence" is a term that seems to be jargon (or perhaps specific
>>> to the Unix/Linux world?). It threw me for a loop and I'm a technical
>>> person. "Persistence" being an act versus describing an object (it is
>>> persistent). It's an encrypted area, or encrypted volume, secure area
>>> (or something more common), I'm uncertain thinking about it at this
>>> late hour, but another term is in need IMHO. Also, it's something
>>> that only exists on a thumb drive or some sort of USB storage,
>>> correct? This may affect the name or necessitate additional
>>> descriptions of some sort. Perhaps some mouse-over help may be in
>>> order? Just a thought.
>> You're suggesting "Encrypted storage area"?
>
> Yeah, I think "Encrypted storage area" meets the target use needs. Do you want
> or is it necessary to advise them first that they need a storage device installed?
I agree with you that the terminology around "persistence" might be
improved. To give you a bit more of background, the term "persistence"
comes from the world of live systems: when you shut them down everything
disappear. Everything except this "persistence" (something that
"persists" the shutdown). When we introduced this feature I decided to
call it "persistent volume" as much as possible, because I felt (like
you did) that "persistence" was a property but not an object.
But after some time we realized that in the context of Tails, it is
actually more relevant to the user to know that this data is encrypted.
That's why we renamed it in some places to "encrypted persistence" or
"encrypted persistent volume" like on:
https://tails.boum.org/doc/first_steps/persistence/
But maybe we need to push this even further and drop the idea of
"persistent" as "storage" also carries the same idea.
The only thing that I'm not very happy with in "encrypted storage area"
is that it's even longer that the current canonical "persistent volume".
Still, as of now "persistent volume" is used in many many places and
changing this would be quite a lot of effort, so we shouldn't do that in
a rush and only with a good reason to do so. Or at least it doesn't make
sense to change this on the Greeter only and not everywhere else.
>>> The phrase "You don't have encrypted persistence, want to configure
>>> one?" This would change based upon the above. Perhaps, "Currently,
>>> there is no encrypted storage area. Do you want to make one? There
>>> are pros and cons." (Pros and cons hyperlinked to info.?)
>>> The icon titled "unlock" should be titled "Unlock". A small UI
>>> consistency issue.
Thanks for correcting this, all of this sound much more correct.
But I feel the need to clarify a bit the process here. The mockups sent
by tchou were very draft mockups to change the structure of the
interface. We usually review the wordings as well, once we decided on a
broad structure but here it hasn't been done. I also refrain myself from
correct things too early as the overall structure might change a lot and
my work get lost.
Still, I think that it is very valuable to start discussing the
terminology as early as we can.
--
sajolida
