Tails

#10 Updated by BitingBird 2015-01-26 14:49:09

sajolida wrote:
> Thanks for the draft. I pushed a few commits to doc/5636-accessHD so make sure to fetch them.
>
> Here are a few comments:
>
> * Use dotted lists when doing enumerations to make them more scanned to the eyes. Here the first class=“caution” could be changed into a list. Bonus points: it will break your sentence which is more than 25 words right now.

done

> * The last part “an application is compromised, this can lead to de-anonymisation” would benefit to be a bit more explicit. Is it that an compromised application could access the data on the disk and from that de-anonymize you?

no idea, i asked intri to list the problems and he said that.

> * Do a git grep on the wiki to find the usual and more technically correct version of “you need to select the administration password startup option”. Reuse is the key!

done (I think)

> * Check the GDSG for the correct version of “left panel”: https://developer.gnome.org/gdp-style-guide/2.32/gdp-style-guide.html

ok -> corrected to “left pane” although I find it weird

> * Use class=“caution” only for dangerous things. Your last three items should be class=“note” probably.

done

> * I’m not satisfied with “a bit more complicated”… Permissions problem can be fixed by opening Nautilus as root. If we don’t want to explain that, what about saying something about requiring administration rights?
> * Regarding LVM, what happens by default? what happens if you run vgchange -ay do we want to document that? shall we point to external documentation?

I didn’t fix both those points, because it’s also intri’s input and I don’t know.

I also didn’t fetch your modifications, I have nobody nearby to help me and the docs don’t work. Sorry.

#11 Updated by intrigeri 2015-01-26 18:52:22

> sajolida wrote:
>> * The last part “an application is compromised, this can lead to de-anonymisation”
>> would benefit to be a bit more explicit. Is it that an compromised application
>> could access the data on the disk and from that de-anonymize you?

> no idea, i asked intri to list the problems and he said that.

Right, unless the data on disk is not identifying (unlikely, taking this data as a whole), then it can be used by an exploited application to de-anonymize the user.

>> * I’m not satisfied with “a bit more complicated”… Permissions problem can be
>> fixed by opening Nautilus as root. If we don’t want to explain that, what about
>> saying something about requiring administration rights?

Sounds good. I assume it can be done with a light amount of additional work, so maybe doesn’t need another ticket and can be handled on this one.

>> * Regarding LVM, what happens by default?

Nothing useful when a PV appears (e.g. after unlocking a dm-crypt volume that hosts a PV).

>> what happens if you run vgchange -ay

Then the VG and all LVs in there appear. Maybe they can even be mounted from GNOME Disks (not sure).

>> do we want to document that? shall we point to external documentation?

I think that this would be worth another ticket, but the work done on documenting the simple cases seems already useful in itself.

#13 Updated by sajolida 2015-02-01 15:57:10

intrigeri suggested that this blocks Feature #7143 when mentioning shared folders from a virtual machine.

#14 Updated by sajolida 2015-02-01 16:29:26

You apparently didn’t merge my changes into your local branch before working on it again. So I’ll redo your changes manually, since now this is blocking Feature #7143.

#15 Updated by BitingBird 2015-02-01 16:47:35

Sorry, I was waiting to have a git expert at hand before working on this again :)

#16 Updated by intrigeri 2015-02-07 12:44:54

BitingBird wrote:
> Sorry, I was waiting to have a git expert at hand before working on this again :)

I’ve had a look, and it seems that you could “simply” merge the upstream branch into yours, and then resolve the conflicts (basically everything conflicts since you’ve been working on the same paragraphs in parallel).

#17 Updated by BitingBird 2015-02-08 15:57:30

Reseted my branch, I’ll work on your further comments.

#18 Updated by BitingBird 2015-02-08 17:12:03

intrigeri wrote:
> > sajolida wrote:
> >> * The last part “an application is compromised, this can lead to de-anonymisation”
> >> would benefit to be a bit more explicit. Is it that an compromised application
> >> could access the data on the disk and from that de-anonymize you?
>
> > no idea, i asked intri to list the problems and he said that.
>
> Right, unless the data on disk is not identifying (unlikely, taking this data as a whole), then it can be used by an exploited application to de-anonymize the user.

So… sajolida, you want to change the phrasing?
>
> >> * I’m not satisfied with “a bit more complicated”… Permissions problem can be
> >> fixed by opening Nautilus as root. If we don’t want to explain that, what about
> >> saying something about requiring administration rights?
>
> Sounds good. I assume it can be done with a light amount of additional work, so maybe doesn’t need another ticket and can be handled on this one.

Changed the sentence, but I’m not sure what level of details to give.
>
> >> * Regarding LVM, what happens by default?
>
> Nothing useful when a PV appears (e.g. after unlocking a dm-crypt volume that hosts a PV).
>
> >> what happens if you run vgchange -ay
>
> Then the VG and all LVs in there appear. Maybe they can even be mounted from GNOME Disks (not sure).
>
> >> do we want to document that? shall we point to external documentation?
>
> I think that this would be worth another ticket, but the work done on documenting the simple cases seems already useful in itself.

I can open another ticket for that.