Intervention: How We Tracked Streams
In June 2016, a major consumer outburst erupted on several online forums concerned with Spotify. Users were beginning to notice that their Spotify client was running amok and had suddenly started to record large amounts of junk data on their solid-state drives (SSDs), which could potentially slow down—if not destroy—their storage capacities.1 As the news spread, reports of ever-larger examples of trash generation began to roll in. Journalists at the tech website Ars Technica ran a test and found that their Spotify clients were unwittingly writing five to ten gigabytes of data per hour on their computers—even when the clients were put in idle mode.2 In cases where the program had been running for months, users reported having terabytes of junk dumped on their hard drives.3 Blog outlets were calling the debacle an “assault on user’s storage devices,”4 a case of excessive “data gobbling,”5 and an issue which was “quietly killing” the lifespan of hard drives.6 It quickly became clear that Spotify had unwantedly turned the computers of thousands of users into garbage dumps. Instead of momentarily diffusing music, the program was spitting out digital trash.7
What happens when someone clicks play on Spotify? It is a simple question, yet it is tricky to answer from a technical viewpoint. As we stated in our introduction, one guiding metaphor for this research has been to “follow” streamed music files as they are shuffled across the web. But such an effort is negated by the basic logics according to which streaming operates. First, data is not technically transported—as in being moved from one location to the next—when information is streamed. Instead, data is copied and multiplied. Thus, the question of how streamed files “move” is not only a matter of tracing changed data locations but an issue of tracking how data proliferates. Second, streamed music does not simply concern the replication of audio data. Hundreds, if not thousands, of other types of data transmission occur every time content is streamed. And while it is possible to single out and isolate specific audio content in such floods of data traffic, it makes little sense to do so, since streaming is inevitably bound up in much larger computational processes. The streaming of music, then, is not simply a matter of transportation; it is an intricate data traffic solution that involves connecting multiple actors, networks, and infrastructures that span the globe.
As the example of Spotify’s unwanted generation of trash data illustrates, these data transmissions can sometimes have hidden or unintended consequences. In order to explore the nature of such streamed data processes, we set up an experiment that allowed us to monitor the data transmissions that are triggered by a “click” (or play) on Spotify. The experimental setup was simple: By using an open-source program called Wireshark, we were able to eavesdrop on data traffic that occurred between one of our personal computers and the internet when Spotify was used. This allowed us to map what streamed data traffic looks like close up, zooming in on its contents and characteristics.
One of the world’s most popular network protocol analyzers, Wireshark is used by programmers to troubleshoot problems in network traffic. The program was first created in 1998 and has since been developed by an impressive 1,316 open-source contributors (and counting). According to its founders, Wireshark “lets you see what’s happening on your network at a microscopic level.”8 The program does this by logging and intercepting the transmission of packets—that is, the small units of data that are sent within a network when a computer is hooked up to the internet. This enables a study of the origin, destination, and characteristics of the data that passes to and from selected computers. For this reason, network protocol analysis tools (or “packet sniffers,” as they are also called) are frequently used for diagnosing network problems, detecting network intrusion attempts, gathering network statistics, and evaluating the effectiveness of security systems, such as firewalls or spam filters. These tools thus play an important role within the day-to-day business of maintaining and upholding the functions of the internet.
Software programs like Wireshark are also popular with malicious hackers, since they enable sniffing out and eavesdropping on every computer that is hooked up to the same Wi-Fi network. Because these programs translate and present the details of all transmissions occurring between two or more nodes on a computer network, they can be used to spy on unprotected Wi-Fi cohabitants. This is usually done when the program is set to “promiscuous mode,” a feature that is available on many network protocol analyzers. Promiscuous mode can be used to gather sensitive information—such as passwords, private email details, credit card numbers, browser histories, and cookies with saved login credentials—from unsuspecting targets, provided that the information is not encrypted.
In our experiment, we did not collect such private communication details concerning other people’s internet use. Rather, we repurposed Wireshark as a digital research tool for “listening in” on our personal streamed data traffic.9 In other words, the intercepted traffic only concerned our own Spotify streams and no one else’s. “Eavesdropping,” biolinguist John L. Locke suggests, “is a deeply biological trait with ancient roots. Few if any species do not eavesdrop—even plants do it.”10 By drawing on this deeply rooted practice of willfully overhearing conversations between others (in our case, computers), our interventionist exercise thus consisted of trying to capture the conversations taking place when music is streamed on Spotify. This gives insight into a sphere of digital communication that is rarely observed by humanist scholars. As Wendy Chun has described it, packet sniffers reveal how “your computer constantly wanders without you.”11 By this, Chun refers to the ways in which computers constantly do stuff without our direct knowledge and how data moves in ways that are not seen at the interface level. Packet sniffers thus challenge the idea that computers are under our control and only act at our request; they reveal the hidden—and sprawling—transmissions that occur within internet networks. In order to understand Spotify as an (organizer of) infrastructure, one has to take such network connections and actors into account.
Consider the scale of data that passes through a service such as Spotify. In 2016, Spotify product manager Ali Sarrafi reported that the company handled more than thirty-eight terabytes of incoming data per day, while permanently storing more than “70 petabytes of … data about songs, playlists, etc.”12 To give a sense of how much data this is, consider that seventy petabytes is roughly equivalent to 930 years—nearly one millennium—of high-quality video. In 2016, Spotify’s backend system was said to be capable of singlehandedly pushing “more than 700,000 events per second halfway across the world,” where an “event” (as we described in chapter 2) refers to any action being performed by a user on the Spotify client, such as adding a song to a playlist.13 In order to cope with such data traffic, Spotify has long hosted a fleet of over twelve thousand servers, distributed in four data centers in Stockholm; London; Ashburn, Virginia; and San Jose, California.14 Since 2015, however, the company has increasingly shipped its data through Google Cloud Platform, which involves using not only Google’s global cloud/storage data centers but also other Google services, such as virtual machines and database management systems.15 In addition, Spotify is hooked up to at least five internet exchange points (IXPs) located in Frankfurt (DEC-IX), Stockholm (Netnod), Amsterdam (AMSIX), London (LINX), and Ashburn (EQIX-ASH). The service is also attached to several content delivery networks (CDNs) and subscriber networks—that is, broadband or mobile providers—which speed up and shorten the distance to their users.16 Each time Spotify is used, traffic is dynamically pushed through these data channels within a split second, depending on where the connection is best.17
What knowledge could we gain about these complex arrangements between cloud providers, internet hubs, and CDNs from using Wireshark? On the evening of May 15, 2017, we intercepted Spotify’s network traffic first by using one recently registered Spotify Free account and then by using one old Spotify Premium account. The premium account belonged to one of us researchers and had been in use for many years, while the new account was registered that evening with a personal email address. During the data capture—which lasted for only twenty minutes on each account—we listened to a series of songs, much as one normally does when using Spotify. All plays were triggered manually, and five songs were played in total.18 While the network traffic was being intercepted, we used the Mac’s Activity Monitor to make sure that no programs other than Spotify were active. The traffic was also filtered so that we only monitored ports that Spotify was using: 80, 443, and 4070.19 The data was first stored in the pcapng format, which enables a dynamic reading of the data in Wireshark, and was later exported to Excel and Google spreadsheets for analysis.
In total, 1,618 Spotify-related packets were captured during the session with the Spotify Premium account, and 11,653 packets were captured during the session with the Spotify Free account. The most likely reason why so many more packets were sent to and from the free account was that this data was collected first, which implies that the music had already been cached (i.e., temporarily stored) on the computer’s hard drive by the time we intercepted the data transmitted via the premium account. In addition, two advertisements (one still image and one video ad) appeared during the free session, which caused more data to be sent and received. In many cases, the captured packets turned out to be simple “Can you read me?” requests, that is, short “hello” messages that allow computers to acknowledge one another’s existence in case information should be transferred between them in the future. We also found that a long list of erroneous packets had been captured on both of the accounts. In fact, 38 percent of the premium data traffic and 4 percent of the free traffic consisted of failed transmission control protocol (TCP) packet transmissions. These failures were never noticed at the interface level during the data collection; the client never froze, and the music played without lag or interruption. Yet the fact that so many erroneous packets appeared reveals how states of breakdown continuously underlie the seemingly well-functioning interfaces of software programs.
Even if Spotify appeared to be running smoothly, hundreds of minor malfunctions were taking place in its network transmissions. For instance, during the premium session, the Spotify client made 213 attempts to establish contact with an IP address located in San Francisco, without any success. Similarly, during the free session, 215 failed attempts to communicate with an internet protocol (IP) address in New York City occurred when the Spotify account was intercepted. For the purposes of this intervention, we will not get into the details of why these packet transmissions failed. Nor do we claim that failed packet transmissions are exclusive to Spotify. The reality is the opposite: they represent a highly common element in general network traffic. The point is that network protocol analysis tools enable considerations of how “technology cannot exist without failure.”20 Even in cases when Spotify appears to be functioning seamlessly, what Federica Frabetti calls “quasi-failures” might still lurk below the surface.21 Tools such as Wireshark, we argue, can thus be used as entryways for studying the sometimes-troubled communication attempts that take place between computers, as well as the moments when software breaks down and misbehaves.
Figure 2.7
Screenshot of Wireshark in action. Black rows indicate failed TCP packet transmissions.
As Nicole Starosielski notes, a simple “click” on a computer commonly activates vast infrastructures whereby information is pushed through routers, local internet networks, IXPs, long-haul backbone systems, coastal cable stations, undersea cables, and data warehouses at the speed of light.22 The characteristics of such infrastructural connections could also be gleaned from our eavesdropping session. In detail, the data traffic that was intercepted during the experiment could be isolated to twelve different actors located in Europe and the United States, of which only one belonged directly to Spotify:
Figure 2.8
List of actors that were found when we eavesdropped on Spotify’s network traffic in May 2017.
AOL and Level 3 are two of the world’s largest Tier 1 backbone network providers, supplying nodes through which a large portion of the world’s internet traffic is connected. The US-based—and sometimes controversial—Level 3 was acquired by CenturyLink in 2017 and is active in more than sixty countries and controls over ten million miles of fiber-optic cables.23 This is equivalent to about four hundred trips around the world.24 Several of these fiber-optic cables are subaquatic and link Africa, Asia, Europe, and North America. The company also runs 350 data centers with fifteen thousand CDN servers across the world.25 Through these cables and data centers, Level 3 has provided network access to several large content providers, such as Pandora, Netflix, and Grooveshark, as well as more delicate customers such as the US Department of Defense.26 During our eavesdropping session, however, it did not appear as though the primary role of Level 3 was to enable Spotify’s transmission of music. Rather, Level 3’s IP addresses appeared to be hosted by the Rubicon Project, an online advertising firm that has managed Spotify’s programmatic ad sales since 2016, in competition with other actors such as Turn, Appnexus, Audience Science, and MediaMath (to which we will return in chapter 4).27
The actual music that was streamed to our computer during the experiment instead appeared to have origins in Google Cloud Platform’s data centers in Ashburn, Stockholm, and Mountain View, California. As mentioned in the previous chapter, Spotify’s music transmissions are based on the Ogg Vorbis codec, a free open-source solution for lossy audio compression that stands in direct competition with the proprietary—and much more commonly used—MP3 codec.28 Most of the packets that were sent between Google’s data centers and our computer contained Ogg Vorbis–labeled data. These packets were also encrypted with the help of a free, open-source software protocol called TrIPE (or Trivial IP Encryption).29 (Interestingly, we were able to listen to these distorted versions of music by playing the encrypted files in the program Audacity.) By using TrIPE and Ogg Vorbis, Spotify gains access to encryption and compression technologies without having to pay costly proprietary fees to build its software on top of them. This cost-saving practice is a common thread in the company’s software and infrastructure management. “At Spotify we love open source,” Noa Resare, one of Spotify’s “free software mediators,” proclaimed in 2014.30 The Spotify client, for example, has benefitted significantly from the labor put into more than three hundred different open-source projects.31 Spotify thus resembles a hybrid of proprietary and open-source software solutions. When looking at the codecs and software on which the service runs, it becomes obvious that Spotify is neither self-built nor self-maintained and instead relies on a vast network of actors for its service to function—another indication that the notion of an enclosed platform is inapt. By hunting among the collected data packets, our eavesdropping session allowed us to study the traces of such actors and to consider their economic and political effects.
From the collected data, we also learned that our Spotify client had been interacting with two different CDNs: Akamai and Amazon CloudFront. As Stephen Graham and Simon Marvin noted in 2001, CDNs are constructions that bypass congested internet infrastructures and instead establish parallel network traffic routes that—against a fee—allow information to reach its destination at a higher speed.32 Such parallel networks have clear political dimensions. They often run between high-priority cities around the globe (such as capitals) and frequently target areas with a high density of corporate activity. In fact, Akamai has been singled out as providing a private network infrastructure that serves to enhance the unequal distribution of global network connectivity.33 Because of their practice of selling high-quality internet access to selected customers, CDNs are also known for sidestepping net neutrality orders and regulations, thus counteracting the basic and open end-to-end principles of the internet.34 Given that we recorded our session in the heart of Stockholm—the most populous city in the Nordic countries—it should come as no surprise that Spotify’s data traffic was routed through such CDNs. Yet our experiment exemplifies how a task as mundane as listening to music on Spotify may trigger complex entanglements with internet infrastructures that are tightly linked to controversial debates around digital policy making, network neutrality and the freedom of the web.
“Unlike telegraphy and telephony,” Tiziana Terranova once wrote, “the communication of information in computer networks does not start with a sender, a receiver and a line, but with an overall information space, constituted by a tangle of possible directions and routes, where information propagates by autonomously finding the lines of least resistance.”35 “This,” she further argues, “produces a space that is not just a ‘space of passage’ for information, but an informational machine itself—an active and turbulent space.”36 The inconstant, improvisational, and mutable qualities of online information transmissions imply that network traffic is constantly in flux. Therefore, it is not certain that a play on Spotify will activate the same data centers, backbone providers, CDNs, and advertisement brokers mentioned in this intervention. Rather, any snapshot of Spotify’s infrastructuring unavoidably links to a position from which the snapshot was taken. Instead of being read as a general depiction of the kinds of data transmissions that a Spotify click triggers, the results of our eavesdropping session must therefore be read as highly situated and context dependent.
The scholarly significance of this intervention is thus not to make general claims regarding how Spotify organizes its data infrastructure but rather to provide an example of its complexities. As Brian Larkin notes, infrastructures play a dual role: they are things that “enable the movement of other matter” while simultaneously also constituting “the relationship between things.”37 As both things and relations, then, Spotify’s data infrastructures connect, prompt, and link together various distributed elements across large geographic distances. While this experiment has far from exhausted the kinds of infrastructures that a service such as Spotify relies on, it has provided some insight into the lively, complex, and sometimes downright-failing network transmissions that a simple click can generate. When pushing play on Spotify, music is heard—amid a cacophony of other data.