Re: [Tails-dev] todo/network_fingerprint

Delete this message

Reply to this message
Autore: adrelanos
Data:  
To: tails-dev
Oggetto: Re: [Tails-dev] todo/network_fingerprint
intrigeri:
> Hi,
>
> adrelanos wrote (01 Jul 2013 15:34:26 GMT) :
>> Anyhow, my best try:
>
> Thanks!
>
> Note, however, that it's a pain to manually diff the current source of
> this section with the interesting mix of Markdown and HTML
> you've sent.
>
> A Git patch against the current source of the page would be much
> easier to review and comment on than what follows. FYI, we have
> guidelines that should help making such contributions in a useful way:


As per "[Tails-dev] documentation contribution process too
bureaucratic?", I'd prefer just to create todo discussion page, add
which chapter to change (its just like ~12 lines in total for this very
chapter), add the original (for wiki history/comparison), then propose
my changes on that page.

[Using git patches for this kind of stuff, for me, takes more time than
editing like three or four such chapters. And I'd argue, that requiring
git patches for this kind off stuff, would result in less contributions,
because less contributors are able/willing to use it for this kind of
stuff and is overall not the right tool for this kind of stuff. But this
meta discussion perhaps better fits into the other "[Tails-dev]
documentation contribution process too bureaucratic?" thread. Feel free
to quote me on it if necessary.]

>    https://tails.boum.org/contribute/how/documentation/

>
>> I propose the following a a replacement for the Fingerprint chapter here:
>> https://tails.boum.org/contribute/design/#index4h1
> [...]
>> From the point of view of the local network administrator,
>
> I feel sad the ISP isn't mentionned anymore. Any good reason for this?
>
>> If the censorship circumvention option (implemented as bridge mode) or
>> possible future Tails detection protection option is enabled, we want
>> the network fingerprint detection resistance, at least to the extend,
>> that it beats DPI boxes at least as good as the censorship circumvention
>> tool (implemented using pluggable transports) does.
>
> OK, this paragraph can certainly be used somewhere in this document,
> but the section you're patching is about distinguishing Tails users
> from other Tor users, so I doubt censorship circumvention fits right
> in there.


Then I must have got something wrong. This was in response too:

>> What is also open to decide for you, is whether you like to improve the
>> network fingerprint (from ISP perspective) when these problems start
>> having real world impacts (censors start censoring based on Tails
>> network fingerprint) or precautionary.
> I think we're trying to be proactive about making it harder to detect
> Tails users who use bridge mode. <snip>


I think fingerprinting and distinguishing Tails users from other Tor
users is interconnected a lot. There is lower motivation to fix
fingerprinting issues if Tails networking is still functional in a
hypothetical world without banning-whole-public-Tor-network vs more
motivation to prevent fingerprinting issues if those can even prevent
pluggable transports from working.

> Also, I'm not sure patching the *implementation* notes is
> the best place to put such a declaration of intent. I'm not sure how
> things could be better arranged, but it for sure looks possible!


No idea. Anyone feel free.

> Also, I'm not sure why "Other possible fingerprint issues on the LAN
> or ISP exist but we believe they would be harder to detect"
> disappeared, since it seemed quite to the point and on-topic to me.


(I tried to be dense, most times I link too many related things.)
Anyhow, let's keep it. When I get a chance (spam filter) I get this
sentence back in.

>> And there https://tails.boum.org/contribute/design/Time_syncing
>> /#index5h1 I'd remove:
>
>> "Tails developers still need to think thoroughly of these questions: are
>> such fingerprinting possibilities a serious problem? What kind of
>> efforts and compromise should be made to prevent these?"
>
> I don't understand why. Did we decide that the "Tor restart on
> startup" thing is a non-issue? It seems contradictory with the stated
> goal of defeating DPI.


I was mostly refering to "Tails developers still need to think
thoroughly of these questions" - I think these questions are, with the
new design decision (should this become one), answered. In meaning of,
"you don't have to think through it anymore, since this has been answered".