Opened 8 years ago

Closed 14 months ago

#4333 closed enhancement (wontfix)

Mark Exit Relays on Vidalia's Tor Network Map

Reported by: ancientmariner Owned by: sirop
Priority: Low Milestone:
Component: Archived/Vidalia Version:
Severity: Normal Keywords: archived-closed-2018-07-04
Cc: chiiph Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The Tor Network Map in Vidalia makes no distinction between Exit and Non-Exit Relays. Since this is a characteristic that has a large impact on the performance of the Tor Network, Relays should be distinguished according to their status as an Exit or Non-Exit Relay.

Child Tickets

Attachments (1)

plain_map.png (161.5 KB) - added by sirop 7 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by sirop

Owner: changed from chiiph to sirop
Status: newassigned

comment:2 Changed 7 years ago by chiiph

Cc: chiiph added

comment:3 Changed 7 years ago by sirop

I am looking now at Marple Widget: there are about thirty relays in Germany but only four are displayed on the Marble Widget, I have not looked up what kind of algorithm is in the code to display these four relays only.

So how exit relays should be marked? With an special icon? Just with a different [coloured] font?

Changed 7 years ago by sirop

Attachment: plain_map.png added

comment:4 Changed 7 years ago by sirop

BTW, i like
setMapThemeId("earth/plain/plain.dgml");
more than setMapThemeId("earth/srtm/srtm.dgml");
See plain_map.png .
plain.dgml has less distracting information like landscape or altitude.

Would be also nice to have only the country's capital as a placemark and maybe a few other bigger cities in order to have more space for painting relay/router placemarks.

Will have a look at it these days.

comment:5 Changed 7 years ago by sirop

1 Just checked that if we do not change lon and lat
as in

void
TorMapWidget::addRouter(const RouterDescriptor &desc, const GeoIpRecord &geoip)

where geoip is always the same for the same country, Marble only shows no more than four relays
for a country.

  1. To mark exit relay is not difficult, could be something like:
       const QPixmap *pmIcon=new QPixmap("path/to/icon");
       const QFont *pmFont=new QFont();
       const QColor *pmColor=new QColor(1,2,3);
       GeoDataStyle *pmStyle= new GeoDataStyle (*pmIcon, *pmFont, *pmColor);
       PlaceMark->setStyle(pmStyle);
    

comment:6 Changed 7 years ago by sirop

It seems to me that in order to place router placemarks properly, one has to know an optimal polygon/rectangle for each country.
These data is already there -- see void VectorComposer::loadOverlays() of Marble,
but not associated with the countries' names.
So i found world bordes data in KML format at https://groups.google.com/a/googleproductforums.com/d/topic/gec-tools/rNjNRYbaWSI/discussion .

Extracting the polygons and finding appropriate rectangular for each country would be my next step.
Correct me if i'm on a wrong way.

comment:7 Changed 7 years ago by chiiph

So the idea would be to distribute this KML with Vidalia? It may be a really good solution but I'm not completely sure.

What do you think about something like this: having a checkbox (or something similar, may be a toggle button somewhere) named "Mark exit nodes", and when checked you display something like what Google displays to mark locations (of course we should use some other image with the correct license). This way it does not matter the country size, the actual point the user wants to see is bellow the image. If there are too many markers near each other, the user can zoom in and the markers will stay the same size.

Another option would be to contact the Marble developers on IRC, they are really nice people. And see what they think about this issue, they may have a way to do exactly this already but we are not looking in the right place.

comment:8 in reply to:  7 ; Changed 7 years ago by sirop

Replying to chiiph:

This way it does not matter the country size, the actual point the user wants to see >is bellow the image. If there are too many markers near each other, the user can zoom >in and the markers will stay the same size.

At the moment we see only 4 placemarks -- more precisely: only 4 annotations for routers' placemarks -- even if we zoom in. We may change the font size of the annotation and see, maybe, 6 or 8 annotations but no more than that.
The problem is that we have only one pair of (lon, lat)-GeoCoordinates for each country. If we know the size of the country or an optimal inner rectangle for each country, we may paint all routers' placemarks and avoid their overlapping.

Another big question is whether our GeoIP-Server will be permanently up some day?
If so, we'll get descriptors which geo-resolve IP's down to city level and not like now only down to country level.
But connecting to GeoIP-Server is additional traffic and IPs resolved to city level might have little informative gain for the user.

That's why i came up with this kml file. We do not even need the whole of it, only a subset: countries' names and corresponding rectangles. Then the file will get even
smaller.

Another option would be to contact the Marble developers on IRC, they are really nice people. And see what they think about this issue, they may have a way to do exactly this already but we are not looking in the right place.

Marble developers and users are hier http://forum.kde.org/viewforum.php?f=217 .
Torsten Rahn, for example. But I do not know how to formulate the question as not to appear too stupid.

comment:9 in reply to:  8 Changed 7 years ago by chiiph

Replying to sirop:

Replying to chiiph:

This way it does not matter the country size, the actual point the user wants to see >is bellow the image. If there are too many markers near each other, the user can zoom >in and the markers will stay the same size.

At the moment we see only 4 placemarks -- more precisely: only 4 annotations for routers' placemarks -- even if we zoom in. We may change the font size of the annotation and see, maybe, 6 or 8 annotations but no more than that.
The problem is that we have only one pair of (lon, lat)-GeoCoordinates for each country. If we know the size of the country or an optimal inner rectangle for each country, we may paint all routers' placemarks and avoid their overlapping.

Sure, I guess we just have to see how that solution looks like and judge whether it's good or too much.

Another big question is whether our GeoIP-Server will be permanently up some day?
If so, we'll get descriptors which geo-resolve IP's down to city level and not like now only down to country level.
But connecting to GeoIP-Server is additional traffic and IPs resolved to city level might have little informative gain for the user.

That's why i came up with this kml file. We do not even need the whole of it, only a subset: countries' names and corresponding rectangles. Then the file will get even
smaller.

There is no geoip server anymore, we use tor to resolve ip to country, and tor uses a geoip file that is distributed with it.

Another option would be to contact the Marble developers on IRC, they are really nice people. And see what they think about this issue, they may have a way to do exactly this already but we are not looking in the right place.

Marble developers and users are hier http://forum.kde.org/viewforum.php?f=217 .
Torsten Rahn, for example. But I do not know how to formulate the question as not to appear too stupid.

You can find them on IRC Freenode channel #marble. If you don't ask someone something because you are afraid of looking stupid then you need to solve that, because it doesn't matter if you look stupid, if you have read the docs and actually tried to answer something yourself but you can't, asking is not wrong (even if the answer is really simple/stupid/whatever).

comment:10 Changed 7 years ago by sirop

comment:11 Changed 21 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:12 Changed 14 months ago by teor

Keywords: archived-closed-2018-07-04 added
Resolution: wontfix
Status: assignedclosed

Close all tickets in archived components

Note: See TracTickets for help on using tickets.