Re: [Tails-dev] [Tails-l10n] Please review doc/experimental

Borrar esta mensaxe

Responder a esta mensaxe
Autor: sajolida
Data:  
Para: The Tails public development discussion list
Asunto: Re: [Tails-dev] [Tails-l10n] Please review doc/experimental
intrigeri:
> hi,
>
> sajolida wrote (03 Apr 2012 19:25:56 GMT) :
>> I already pushed to the doc/experimental branch a first batch of
>> docs for the upcoming release.
>
> Great! I reviewed all these new pages, liked it very much, and have
> a few minor fixes I should push.
>
> General note: it seems like these new pieces of documentation contain
> many links to numbered sections or sub-sections in other pages, such
> as "startup_options#index2h1". This seems very fragile to me: I doubt
> many of us will think of grep'ing through the wiki to adapt such links
> after doing a change that shifts section numbers. IIRC there's an
> ikiwiki plugin (maybe in contrib/? maybe written by pabs?) that allows
> to give section headings *named* anchors, in a way that I don't
> precisely remember, but that might help solve this problem.


Yes, I'm aware of that issue and I already tried this plugin
(headinganchors) to solve it. It is not configurable and creates anchors
like this `id="Warning_about_USB_sticks_and_solid-state_drives"`. I
don't like it for the following reasons:
- the text of the head might as well change, such errors would become
broken links in the wiki, but there might be external links as well
- the URL can become super-long and mixed in case, but that's a
aesthetics problem I guess

Another option would be to create anchors by hand when needed. But then
the anchors would not be created automatically for every headings. We
could do:

<a id="anchor"></a>
Heading
=======

or

<h1 id="anchor">Heading</h1>

I'm not sure which option is the best, the plugin or the handmade
anchors. What do you think?

>> - doc/first_steps/usb_installer
>
>> This does only document the "Clone & Install" option so far.
>> How important do you think it is to document the other options in
>> time for Tails 0.11?
>
> I think the upgrade options can be postponed to right before 0.11.1.
> But we don't know how far from 0.11 this time will be,
> so I suggest writing these bits before it's a real emergency.


Ok, I'll try to do it for 0.11 if I have time.

>> - doc/first_steps/startup_options
>
> The screenshot does not display the widgets that allow the user to
> choose their preferred language and keyboard layout.
> Is this intentional?


Nope. But I double-checked and it doesn't appear on my virtual machine!
Maybe that's a side effect of the "VirtualBox guest modules are only
built for amd64" bug. I'll try again with the RC1 once I got one.

>> - doc/first_steps/startup_options/administration_password
>
> I'm not convinced by "to start Tails" in "Then click on the Login
> button to start Tails". I've seen a more accurate reference to the
> GNOME Desktop in some other new page, so I guess we can allow
> ourselves to write something less wrong here too :)


Done, I changed it to "start the GNOME Desktop".

>> - doc/first_steps/persistence/warnings
>
> When I read this:
>
> Remember also that secure deletion do not work as expected on USB
> sticks. See the corresponding documentation. Read how to delete the
> persistent storage instead.
>
> I think this suggests the "delete the persistent storage" page deals
> with secure deletion of that storage area. However, the first set of
> instructions given on that other page "choose Applications ▸ Tails
> ▸ Delete persistent storage, and click on the Delete button." does not
> support secure deletion yet, and the other sets of instructions either
> let me totally doubtful, or just don't work. See other problems in
> this area later on.


Ok, see 29ad316.

> About "The programs included in Tails are [...] audited for their
> security. This may not be the case of all the packages available in
> Debian": the way the "security" word is used here results in
> a sentence that is largely overstating what we are really doing.
> And follows "Other programs than the ones included in Tails may be
> subject to security holes that Tails do not protect you from", which
> is oversimplifying as well IMHO. Maybe go beyond the binary "security"
> flawed concept and explain that:
>
>   * Even "secure" software may be unsuitable to use in an anonymity
>     context (e.g. leaks IP address).
>   * Tails is an integrated system and injecting random stuff into the
>     mix may make the end result behave in totally unpredictable ways
>     that may, or may not, match the expectations one puts into Tails
>   * Installing additional packages is likely to turn your customized
>     Tails into something Tails developers cannot, or don't want to,
>     support.


What about:

« To protect your anonymity and leave no trace, Tails developers select
and configure with care programs that work well together. **Installing
additional programs may introduce unpredictable problems and may break
the protections built-in Tails.** Tails developers may not want or may
not be capable of helping you to solve those problems. »

> Is "permanent storage" used on purpose?


Not at all. I corrected all of them.

> "Only the files that you specify are stored." --> I'd rather say "the
> files and folders".


Done.

>> - doc/first_steps/persistence/configure
>
> "and open the Permanent folder" --> maybe you want us to change this,
> but currently, it's called "Persistent". The rest of this paragraph
> gets it right.


Of course.

> "Note that those packages are not automatically reinstalled when
> starting a new Tails working session." --> I suggest stating why one
> may want to activate this feature, in addition to its limits. Same for
> the next (APT Lists) feature.


Done, see b0bd883.

>> - doc/first_steps/persistence/use
>
> Looks like "the Permanent folder" strikes back.
>
>> - doc/first_steps/persistence/delete
>
> "Creating a new persistent storage on top of an old one makes it hard
> for an attacker to recover the files of the old persistent storage
> using data recovery techniques" --> Why? Because you suppose the old
> LUKS header to be overwritten by a newer one? If this is the only
> reason, I don't think we can seriously base anything on this. E.g.
> the modern partitioning tools we're using (namely: udisks) try to be
> clever wrt. sector alignment, and e.g. I would not bet Wheezy's udisks
> (in Tails 2.0), will create a new persistent storage exactly at the
> same place as Squeeze's udisks (in Tails 0.11) did.


Ok, you're right. Please see 301e40b.

> 1. Erase Tails
> 2. Securely clean all the available disk space
>
> --> I think #2 only works if there's a filesystem on the target USB
> stick, which is not true after following #1.


Ok, I see two ways of solving that:

1. Add a step that create a partition with a FAT file system after
erasing Tails. That can be done with the Disk Utility in Linux and it
seems like some versions of diskpart can format partitions too [1]. That
would also makes sense since when you buy an empty USB stick it usually
comes with a FAT filesystem and user might expect this from our claim
that erasing Tails from the USB stick allows to « use it for something
else ».

[1]
http://msdn.microsoft.com/en-us/library/bb521584%28v=winembedded.51%29.aspx

2. Add a step linking to "Create an encrypted volume" on the whole USB
stick before doing "Securely clean…" and be done with it.

>> While writing the doc on the persistent storage I also felt the need
>> to maybe work in better collaboration with the people writing the
>> GUI. It would be good to make more consistent the terminology and
>> style between our custom GUI and our documentation.
>
> Sure. Feel free to suggest whatever improvement you can think of.
>
> I did not know one may use the "storage" word as if it can be counted,
> as in "create a persistent storage". I thought a "storage volume",
> "storage area" or "storage container" can be counted, but *some*
> storage cannot. Did you double-check the (more concise) way you are
> using it is correct? If it is, I'm happy to adapt the GUI accordingly.


You're right again. It's not correct to say "a persistent storage". I
decided to use that term instead of just "persistence" because I thought
it was better to talk about a somehow concrete object than a more
abstract notion.

Maybe I can replace it by "persistent volume". That's the term used by
the Disk Utility and we already used it in "Create and use encrypted
volumes".

>> But I'm not sure whether the timeline still also us to do so now
>> that we passed the deep freeze.
>
> From the release process side, I think improvements in terminology and
> style consistency can still be pushed into the various new GUI.
>
> Great work!


Thanks.

--
sajolida