Re: [Tails-ux] Terminology for the web assistant: different …

Delete this message

Reply to this message
Author: sajolida
Date:  
To: Tails user experience & user interface design
Subject: Re: [Tails-ux] Terminology for the web assistant: different kinds of Tails
intrigeri:
> sajolida wrote (07 May 2015 09:23:00 GMT) :
>> intrigeri:
>>> Just my 2 bits of technical/roadmap background info: it *might* become
>>> the case that very important Tails features depend on persistence
>>> being setup, e.g. https://labs.riseup.net/code/issues/7675 ("Persist
>>> entropy pool seeds")
>
>> What do you mean by "important" and "depend" here?
>
> Here we go:
>
>> Will Tails not work properly without them?
>
> No.
>
>> Will Tails be less secure that it is today without them?
>
> No, but the current situation is pretty shitty in this respect, so
> being as secure (without that future persistence feature) as Tails is
> today doesn't mean much.
>
>> Will people who activated them benefit from additional security?
>
> Yes.
>
>> I'm thinking also about a possible persistent Tor state. That is not
>> necessarily something visible, but that makes Tails to connect faster to
>> Tor and a bit safer because you're keeping your entry guards. Would this
>> be in the same family of features?
>
> Exactly.


Ok, so I understood correctly.

>>> -- although it's not clear yet what we'll do, and
>>> it might be that we want to actually persist that piece of data even
>>> without persistence being set up, somehow (yes, I know).
>>>
>>> I've no idea if/how such a change impacts the discussion we're having
>>> here, I'll let you folks judge.
>
>> The question that we need to answer here is whether the fact that those
>> new features exist (most probably in persistence but maybe outside) will
>> affect what we advertise as "Tails" and "Tails with persistence". I
>> understand better their implications to be sure about that.
>
>> Note that this might as well affect our setup tools. Because if it
>> suddenly becomes insecure or buggy to use Tails without persistence,
>> then we should do better at enforcing setting up persistence during the
>> installation process.
>
> Indeed.
>
>> And also what about people using DVDs?
>
> I've no idea. Perhaps we'll have to ask for user input when no
> persistent entropy pool seed is found.


The same wouldn't be applicable to the Tor state persistence. So we
probably have to think about that in a more general way.

>> Or, how are we going to explain to people that they need
>> a passphrase for something that doesn't protect any user
>> visible data?
>
> I don't understand what this passphrase would be used for.


The entropy pool and the Tor state are not visible by the user: you can
use Tails with or without it and your experience doesn't change. Only
some invisible security properties do. But if this data is stored in the
encrypted persistence (I bet that the Tor state should and the entropy
pool might), then we might end up in a situation where the user doesn't
need persistence for anything else but those invisible security
features. Then we would have to ask them for the passphrase of the
encrypted persistence only to gain this extra security.

This is what I'm referring to when saying that it might be awkward to
ask for a passphrase that is not protecting any user visible data.

If we decide to go this way, then we might have to be upfront about it
and explain more of the technical details. Maybe we can explain that we
need to store some, let's say "cryptographic information", in
persistence and that the user gains security by activating them.

Then our discourse about persistence would change ("use persistence to
store private date, custom configuration, and get additional security").
But we wouldn't have to change how it is called.

Those are rough hypothesis of course...

--
sajolida