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. _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
