On Tue, Apr 22, 2014 at 11:10 AM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
On Tue, Apr 22, 2014 at 05:02:23PM +0200, Daniel Martà wrote:
Hello everyone,
My name is Daniel and this summer I'll be working on consensus diffs [0], heavily based on proposal 140 [1]. This should allow for quicker and scalable consensus udpates, which will have more weight as the consensus grows larger. I've never gotten involved in Tor before, so I'm really looking forward to this summer.
My intention is to use a simplified ed format as described on proposal 140, but I am open to alternatives and suggestions. As far as the diff creation algorithm, I plan on using a dynamic programming algorithm for the Longest Common Substring problem. Like before, comments are very welcome.
The proposal (140) doesn't appear to discuss the client fingerprintability aspect of this: they reveal the last time they used Tor (if recentish). Say you're a mobile client that gets a dynamic IP address. With this, you reveal that you probably aren't or maybe are the same person that was last seen over there at that particular time.
If there's a problem here, then it's a problem that already exists because of Tor's use of the If-modified-since header during consensus downloads.
The problem should be less severe in 0.2.4.x, with the addition of directory guards: the source of one's directory info is now one's guards, and they have a pretty good idea of when you were last online anyway. Proposal 236 would narrow the additional value of this information even more. Though we might want to amend proposal 236 so that you get one guard but several directory guards; having a single source for directory information is less robust than having a few. (I'll follow up on another thread about that.)
Additionally, it might be a good idea to close this information flow a bit harder. Our best bet seems to be limiting the age of the consensus that we're willing to ask for a diff from. Any other ideas?