Sajolida,
On 01/22/2015 10:08, sajolida wrote:
> KEN MCCALL:
>> HI Alan,
>>
>> Inline below . . .
>
> We only do inline here :) Top posting is a pretty bad practice in our
> context.
Inline can quickly become messy, though I will refrain from top posting
unless the context calls for it. Thanks for the heads up :)
>
>> 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.
Isn't the target, then, everyone?
>
>>>> "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.
