> If somebody submitted a clean short patch for this, we'd probably > put it in.
For simplicity, I'd definitely go with making the '*' match any and all levels to the left of its placement, inclusive. *.google.com would match a.google.com, b.a.google.com, z.<...>.google.com. Noted because combining my #2 and #3 would be easier. #1 of course would match the google.com 'host' and need to remain that way anyways. And because your 'tor controller' paragraph indicates an extant API for the more exotic... I need to look at those functions you mention :) Though I doubt users would need more than the catchall patch above. The '**' was only there if counting levels, as in #2, was thought to be useful. Probably not. One last thing I thought of for the future was point to multipoint mappings: *.google.com=*.google.com.<exit1>.exit *.google.com=*.google.com.<exit2>.exit ... Would provide a set of exits to try to use for whatever matches the left side. And it quite possibly would not 'do the right thing' from a user point of view. Perhaps the first exit that is up gets the traffic, but if it goes down, don't switch because that would look like 'traveling' which would be bad. Unless the user could be notified and switch it with their logins. So I left it out earlier. Sort of more specific than 'only use <country> exits for my surfing', 'use these exits for this site'. > TrackHostExits <host/dom list> Man page indicates that this does: for each item in the list, track that item independently to whatever exit Tor picked. Ok, so, new... TrackHostExits <host/dom list> [rulenum] TrackHostExitsTogether <0|1> [rulenum] 0 - each list item tracks its exit independantly, the current default 1 - all list items follow the same, autochosen, exit The [rulenum] allows multiple statements to be configured. For when the Together option = 1, and you want independant threads tracking each list, to possibly different autochosen exits. Oops, more simply... TrackHostsExitTogether <host/dom list 1> TrackHostsExitTogether <host/dom list 2> And ok, so, new... TrackHostsExit <exit> <host/dom list> Track and tie the entire list to an exit. Probably not as dynamic [control interface] or capable as the general MapAddress proposal/interface, but serves the same purpose as it. Perhaps as a simpler rc config interface. > I don't imagine that ordinary users would ever touch this sort of > feature, because it requires them to: > a) know about the .exit notation It took me a fair bit of time to find and figure out MapAddress. Now that I know it, it is invaluable. I was asleep and left out some important use cases, likely much more common than blocking... Sites that pick language and featuresets depending on their idea of your geolocation. Sites that refuse to create accounts, or delete preexisting valid accounts, if the user 'travels'. Ebay is one such site that dislikes travelers. Placing these gotcha cases in the torfaq, etc, would help users be aware of them and introduce the .exit workaround... as in my #1, and hopefully in this new feature. I put this to the or-talk for the users there in case they run into this. > b) know how to find a suitable exit relay. Users could pick a relay by country from perhaps one of the torstatus pages and then say: MapAddress *.google.com=*.google.com.<exit>.exit I think there was discussion around letting operators denote their country in their descriptors. So vidalia and the like may one day filter and display those, with or without regard to the geoip db. Had something to do with selecting countries, dunno.
