Traceroute at least three of the sites you regularly visit. Do it from all of the locations you regularly connect from. Save the trace in a file, and make a map of the routes, indicating the network providers that show up every time. Identify who the major tier 1 providers are in your life. Identify the networks your traffic crosses in the course of your daily life. Figure out whose hands the data about your life goes through on a regular basis. Look for patterns from your network-browsing habits through analysis and graphing of your network traces.
I traced four websites that I frequently visit:
ouiouioui.space (my homepage)
nts.live (online radio)
home.nyu.edu (university page)
stackoverflow.com (developer community)
I chose two networks/locations for tracing that I spend most of my time at:
university wifi (+ mobile network comparison in same location), at Washington Square/Manhattan
home wifi (+ mobile network comparison in same location) in Brooklyn
I wrote two custom tracerouting tools to automate the process as far as possible:
tracer.py: combined traceroute and isp-lookup/geoip for given list of urls, returns json-txt file
mapper.ipynb: matplotlib based tool using basemap to create traceroute maps from json-txt file
server footprint from home
I live in Brooklyn. This is where I spend the few hours that I am not on the floor at ITP.
Looking at the footprints I observed that connecting to my homepage (which I registered in Europe with Squarespace) from my homw wifi causes the trace to bounce back and forth between EU and US - until finally reaching the US - and the routes my signal travels on are owned by Time Warner Cable and Akamai Technologies:
The route looks similar when using a mobile connection, but with different providers: Zayo Bandwidth and Level 3 Technologies stick out, Akamai Technologies comes up again as ISP in Europe:
Looking at another footprint (nts.live), Time Warner Cable dominates the servers in the US:
The same trace with mobile emphasizes again Zayo Bandwidth for mobile-networks:
Connecting to NYU and Stackoverflow does not yield too many interesting results, both stay more or less close to or entirely in New York. The only strange behavior comes from trying to traceroute Stackoverflow on mobile - it does not allow to traceroute, the signal gets stuck in a local private network (in all locations).
Here the connection to Stackoverflow via wifi which travels to Denver and then comes back to New York:
server footprint from ITP/NYU
ITP/NYU is situated at Washington Square in Manhattan. Here I spend most of my time, logged into NYU wifi or the mobile network.
Comparing the traces of the two wifi-networks (home and university), the paths through the servers look different for my homepage - in the US the network provider is not clearly identifiable, NYU provides the last visible trace before it goes to Europe. There GTT Communications comes up as a provider:
The trace for nts.live shows a connection to Europe that does not come in the map from my home wifi, the network provider that pops up is Hibernia Networks Netherlands. Why? It might have to do with NTS having multiple IP-addresses, maybe the server was more easy to access from NYU. Maybe. I can only speculate at the moment. Anyway, here the map, accessed from NYU wifi:
On mobile the connection stays in the US (and again in the hands of Zayo Bandwidth as ISP):
To make it short - this is all very interesting! My online life is in the hands of very few network providers, they vary depending on which type of network I am connected to - and the routes vary sometimes substantially, detours to Europe are not always explainable for me. I really enjoyed understanding much more of this physical layer of the internet and how every request from a laptop of phone travels around the globe at -literally - light-speed.
I thoroughly enjoyed building custom tools in python for it and dive a little bit into data visualization with matplotlib and basemap - although I encountered quite a few challenges on my way: nested dictionaries are great, but need a logical setup, building tools takes way more time than actually collecting and visualizing the data.
Let’s finish this blogpost with a screenshot from parts of the json-data (a little bit obscured):