[atlas] Probe location obfuscation

At least where I’m located, MaxMind (and other IP-to-location databases, if
there are other ones in the game) don’t get any closer than the country.
Regarding the Atlas-set location, I just checked and it turns out that the
location pin is right down the street, but I know for a while in the past I
had it about a 15 minute drive away for political reasons - the wrong flag
was appearing on the info page.

On Fri, Mar 26, 2021 at 1:52 AM Steve Gibbard <scg at gibbard.org> wrote:

> I have a file that I generate a few times a day with the MaxMind locations
> of all the probe addresses.
>
> It would be pretty trivial to run that against the official probe
> locations and generate a list of suspicious locations, but I don’t
> generally bother as I’m not sure what I would do with the data.
>
> When I’ve spot checked differences, Maxmind has seemed more frequently
> correct than the Atlas data (at least for eyeball networks), but both are
> far from perfect.
>
> I suspect you’d find the latency method below to be pretty inaccurate as
> well.  If latency from a known-location probe were low, that would tell you
> something definitive, but if it were high it might just be telling you that
> the local ISPs in a region don’t talk to each other locally.  Maxmind et
> al. have hopefully already done a bunch of that work.
>
> -Steve
> Global Traceroute
>
> > On Mar 25, 2021, at 6:02 AM, Massimo Candela <massimo at us.ntt.net> wrote:
> >
> > [possibly OT]
> >
> > In 2018 we found 18 probes which were located so far from reality that
> the collected RTT towards targets of known locations was faster than the
> speed of light (I remember we did something about those). I suspect there
> are some cases more, just below speed of light. But not so many, I believe
> the vast majority of the probes are all set properly.
> >
> > With software probes there is also the problem of less users reporting a
> location at all (I don't have numbers, based on an observation in a past
> experiment. It may no longer be the case).
> >
> > I don't remember if there is something similar already in place, but I
> would suggest a process like:
> > - if a probe doesn't have a location, set a location calculated by
> latency measurements AND ask the user to review the result at is first
> convenience;
> > - for all the probes currently having a location, use latency
> measurements to mark the one possibly wrong and ask the user for update.
> > - overall, use latency measurements to periodically review the probe's
> location. RTTs can be used to mark obviously wrong locations, without being
> too restrictive.
> >
> > For RTTs above a certain amount (the usual 10ms?), deactivate the RTT
> validation so users are still able to place probes in exotic locations.
> >
> > I don't think there is a use case for obfuscating probes more than at
> the city level. And if there is, these probes should be tagged as such.
> >
> > Ciao,
> > Massimo
> >
> > On 25/03/2021 13:00, Ponikierski, Grzegorz via ripe-atlas wrote:
> >> I would add to it additional problem that some hosts obfuscate probe
> location even more. For example you can find probes which in reality are
> located in US but are marked as CN or probes which are in reality in
> Wisconsin but are marked in California. Of course these are extreme cases.
> I guess most hosts just put a pin with probe location just somewhere around
> where it's locate as long it's in the same city. I don't remember, as a
> host of 3 probes, to get any precise recommendations how to mark probe
> location. Personally I just put a pin in city district where probe is
> locate.
> >> Regards,
> >> Grzegorz
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20210326/79822f5a/attachment.html>