intrigeri:
> Hi,
>
> adrelanos wrote (02 Jul 2013 23:04:43 GMT) :
>> As per "[Tails-dev] documentation contribution process too
>> bureaucratic?", I'd prefer just to create todo discussion page, [...]
>> [Using git patches for this kind of stuff, for me, takes more time than
>> editing like three or four such chapters.
>
> Whatever you prefer (and that actually can be reviewed and merged
> without too much silly efforts), but please propose changes to the
> *source* of the page, not to the rendered output. One does not submit
> binary patches to the *compiled* Linux kernel, and there are good
> reasons for this :)
Glad to do that. I have to write wiki markdown anyway if I want to post
it to a discussion/todo page.
>>>> 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.
>
> Sure. Perhaps that's a good enough reason to re-purpose the whole
> section. But still, one can't tell in the introduction that it's about
> one thing, and then talk (surprise!) about the other. See what I mean?
Agreed.
[I don't think I can come up with a solution and I don't think writing
an obvious, non-surprising, simple technical design is in scope of the
design. If one wants it like a school book, beginning from no knowledge
about linux/anonymity/security/privacy, that's something I consider a
good thing. At the moment one who want to get into this topic in
general, will have to read a lot stuff from a lot different sources.
While reading the first things, this person always won't understand many
things, which get clearer over time. Even in a school book, you can't
expect to understand some random chapter by reading just that very
chapter. Ideally, the required knowledge to understand that chapter was
covered in an earlier chapter.]
>>>> 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".
>
> I don't think so, but perhaps I missed something.
> What's the answer to these questions, then?
With the assumption that [1] is still accepted as it was earlier in this
thread, it's as it follows.
> Are such fingerprinting possibilities a serious problem?
As per the new proposed fingerprinting design chapter, the answer is,
for example, either:
- "Yes."
- "For (censorship circumvention mode/bridge users), yes."
Now its a stylistic question whether you expect the design (which
includes fingerprinting) to be read already or if you add some required
knowledge block above or if you link to other connected design chapters.
In response to...
> What kind of efforts and compromise should be made to prevent these?
Responding to...
>> Tails runs HTP through Tor, so the fingerprintability should be
limited to traffic flow only. It should be noted that HTP only fetches
the HTTP header, so fingerprinting based on the known traffic pattern
when fetching the full page of any of the members of Tails' HTP source
pools is not possible.
Since traffic flows over Tor, its the job of Tor (and the censorship
circumvention tool) to prevent, that the ISP can guess what's inside
that stream. If they fail at this, its a severe upstream bug. Hence, no
network fingerprinting issue. The web fingerprint is not of concern,
since (censorship circumvention mode/bridge users) are not affected as
in successfully fingerprinted and access denied.
Responding to...
>> Our initial time guess based on the Tor consensus is probably easier
to fingerprint, though: a fresh Tor is started, and restarted again
right after the consensus has been downloaded.
When the fingerprinting design is accepted as proposed, the answer is:
not a design goal, since no (censorship circumvention mode/bridge users)
are affected. Probable also, patches still welcome.
[1] Hence, I think, you will like Tails's network fingerprint detection
resistance (from ISP perspective) , at least to the extend, that it
beats DPI boxes at least as good as pluggable transports do.
