Re: [Tails-dev] [Electronic Frontier Foundation/The Tor Proj…

Delete this message

Reply to this message
Autore: intrigeri
Data:  
To: julien.voisin
CC: The Tails public development discussion list
Oggetto: Re: [Tails-dev] [Electronic Frontier Foundation/The Tor Project] Update by jvoisin to proposal: Tails Server
jvoisin wrote (16 Apr 2012 19:24:07 GMT) :
> I have just updated (again) my proposal according to
> intrigeri's feedback.


Great. We're getting closer :)

> 1. Check configuration presence


> When Tails boots, it will at some point check for the presence of
> a storage media containing a Tails server configuration, using GPT
> partition's label.


I'm not convinced. Do you mean a specific partition label should be
used for Tails server persistent partition, that would be different
from the label used for regular Tails persistent partition?
This means adding support for this second label to every
persistence -related program we have. Doable, but perhaps not the best
idea ever.
Or maybe you mean something else?

> 2.2 LAN
> 2.5 Authentication


My last comments about this were not taken into account. These two
paragraphs are still full of unclear, incomplete, or patently
wrong information.

> But, because tails-server can only be created from tails, generated
> certificates fingerprint could be stored in a ~/.tails-server folder
> on the client : Any certificates found there would be added to
> iceweasel on as soon as Tails has opened the persistent volume and
> found this preset.


It should be made explicit the ~/.tails-server must be made persistent
on the "client" USB stick *before* configuring a Tails server stick.
This looks far from being perfect from a usability PoV, so something
should lead the user through the whole process.

... or support added to change the persistence configuration of
a *running* Tails (difficult).

> Tails server configuration GUI
> I'll do the Tails server configuration GUI if time permits


See my previous comments.

> Timeline


I'd like to see something *useful* as soon as possible. That means
having a way to run a *service* ASAP. This is the "start a gobby
service" part. Waiting for the 6th iteration to see something useful
does not please me at all.

So, how to enable early adopters to do so ASAP?
The service and HS setup GUI can wait.

As suggested on IRC one month ago, early adopters may have to paste
the hidden service directory and Gobby service config into the Tails
server persistent area themselves, we don't care, as long as they can
*use* the resulting service. But how does Tails server know what
service it shall start? This is probably one of the first problems
that should be solved to produce something useful. Maybe even skip
that one too, to start with, and just drop a shell script into the mix
to get things moving fast and soon.

What do you think? Can you please try to rethink the timeline in such
a user-oriented way? A nice way to do this is to write it from the
user point-of-view: "As a user of Tails greeter, I should be able to
do this and that". I suggest you start by rewritting your current
timeline like this, in the very same ordering, and you'll realize it's
currently organized in a way the user can't do much before the 6th
iteration. Then, you can start the deep reworking the timeline,
splitting tasks, to change this entirely.

To end with, you integrated the bi-weekly milestone idea I suggested.
This is great, but I'd like to be sure we agree this milestone must be
*working*, *testable*. Do we?

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc