- Tested with Firefox 2.x, Opera 9.x , MSIE 6.x:
- Firefox: by far the fastest browser, super-tolerant of all XML data, bleeds memory like a cow in the slaughter house
- Opera: draws map icons progressively, FAILS to reload the (changed!) XML data when hitting
the 'Reload' button, the JS engine silently fails to load the XML data if the external XML
file has more than about 575 data items.
- MSIE: has the absolutely ridiculous idea that non-plain ASCII data (like Umlauts) in XML files
warrants failing/crashing JavaScript, and logging absolutely useless and misleading error messages,
while the other browsers have no problems reading/displaying international/high-ascii characters!
- So you don't know what an ASN is?
- The data used is a shifting window of the last 24 hours, updated every 15 minutes.
- More than 98% of current locations are geo-coded automatically, with no human review.
A few high-traffic/highly visible ASNs have received manually coded geolocation data by us,
because automatic discovery yielded less than acceptable results.
- The map input depends on an on-disk cache of ASN whois info pulled from ARIN/RIPE/LACNIC/APNIC
by SpamShield, watching smtp/mail activity in realtime.
20% of records in the current map are not in that cache due to manual overrides
of abuse contact data, suppressing WHOIS records from being looked up.
- In the "Also show ASNs with unknown locations" map, these ASNs have been placed at random
locations in the North Atlantic.
- About 8-10% of ASNs that we have whois data for will just not yield geolocation data.
This is due to several factors:
- Wide varieties of data and country-specific address formats: ARIN,APNIC,LACNIC,RIPE all do things differently!
- Inconsistently/Badly entered data by ASN registrants (address lines that throw City, Postal Code and
country all in the same line become just about impossible to parse!)
- Google Maps' API will just not return valid geolocation data, no matter how much we strip
down the accuracy of the data we present.
- In the "Also show ASNs with unknown locations" map, these ASNs have been placed at random
locations in the North Atlantic.
- Even "valid" location data (according to Google Maps' API) is wrong in the real world - about 3-5% of the time!
- Google Maps' geolocation engine
is not as perfect or consistent as one might expect: it performs particularly bad
when presented with plain country names, like: "Yugoslavia", "Norway", "Spain"
(after attempting to get location info with more detailed address/city-level data unsuccessfully),
This yields us seemingly "valid" geolocation data that is not exactly where we'd expect it to be!
- Just because the registrant of an ASN (ISP,Institution,Agency) has entered a specific address as location
data into their record, doesn't mean their network is at that location.
Indeed, some ASNs (like 701/UUnet/Verizon Business) span entire continents.
Only the first parsable address found in an ASN record is used.
- New, 2007/08/06: Some entities (Like RoadRunner and Comcast - broadband cable providers in the US) have dozens of
ASNs, all registered to the same address. We're now detecting and aggregating
data for multiple ASNs belonging to the same registrant.
- Geolocation data with low accuracy (a Google Maps indicator value, as well as locations requiring
address data reduction on our side to get a valid geolocation from Google) is randomly 'fuzzied' -
to avoid all markers solely posessing 'country'-level accuracy from piling on top of one another (See Russia).
- Comments? spamworld-comments@spamshield.org (address strongly spamfiltered :)