Re: Proposal: MapAddress wilcards [*]

[grarpamp <grarpamp@xxxxxxxxx>]

> 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.