On Friday 30 November 2007 08:13:18 you wrote: > > > 2. setconf ExcludeCountryCodes > > 3. setconf IncludeCountryCodes > > Hm. Most people I've talked to care about the position in the path too -- > they don't just want to skip a given country entirely, they want to only > skip it at the beginning, or the end, or something like that. > > And what would IncludeCountryCodes do? Only use relays from those > countries in all positions in the circuit? Yes, a bit half-baked. Disengaging gently from auto-pilot: ExcludeExitCountryCodes US,DE StrictExitCountryCodes 1|0 ExitCountryCodes US,DE EntryCountryCodes US,DE StrictEntryCountryCodes 1|0 # For non-entry and non-exit servers RelayCountryCodes US,DE StrictRelayCountryCodes 1|0 So that the user can see what servers are being excluded by these choices: getinfo servers/[countrycode] - giving network-statuses getinfo names/countrycode - giving an fp list maybe. um, that's it. > > > > > @downloaded-at 2007-11-29 19:45:13 > > @source "86.59.21.38" > > @geoip US Boston X-ordinate Y-ordinate > > The "router annotations" you describe here are added locally by the Tor > that receives the router descriptor. They're not published in any signed > way. If we were to add the countrycode into the server descriptor, then > we would have to trust the server to write the correct countrycode into > his signed descriptor, and if we decided he was lying our only recourse > would be to not list that descriptor. > > If we want to provide the countrycode info for each router, signed by > authorities, we could put it into that router's entry in the networkstatus > consensus -- that's my "Option B" in Section 4.2. > Ah. Whoops. > But I'm still not very happy about putting it in the networkstatus, > since the IP to GeoIP mapping will be relatively static, so we'll be > wasting a lot of bandwidth as caches mirror redundant information, > and as clients fetch information they already know. > This is the definiitely the big downside with centralizing the geoip data to the authorities. That said, tt would be just an extra three bytes per status (including the space) if you were to provide country code, roughly 4-5K at current volumes. If country code is enough for the near future then this might be the way to go. The x-y co-ordinates could then be an opt field in the network-status document, if a client needs them. Again imvho the merits/demerits of centralizing come down to whether country code is enough in the immediate future for the feature's goal - if it is then the security advantages [reduced partitioning opportunities] of keeping it to the authorities may outweigh the small(?) bw penalty it incurs. Given that bw is something to conserve, perhaps a few wasteful bytes from the network-status could be removed for 0.2, e.g.. the '-' and ':' in the date and time stamps. Maybe the status flags could be abbreviated? These two alone would make enough room for country code and co-ordinates! ;-) I know what a hack that would be to code around, but... > Since most of the answers won't change from hour to hour, the obvious > solution is to only ask questions about the ones you don't already know > the answer to -- which is exactly what Vidalia already does. > > But I haven't thought of a better way yet. Perhaps we'll have found one > by the time we get around to switching from "Option A" to "Option B". :) > > Thanks, > --Roger
Attachment:
signature.asc
Description: This is a digitally signed message part.