Relics from the P2P file-sharing wars

This blogger was recently disconnected from a New York hotel  network with a cryptic error message:


Nothing adds up here. p2pnetworking.exe? EXE extension indicates a Windows application—which is not the operating system running on the machine. Even more surprising was the reference to Kazaa (note the misspelling above,) which inspired a trip down memory lane.

The 2000s called; they want their file-sharing wars back.

After Napster

Kazaa was a popular peer-to-peer file sharing application which came to prominence as part of the second generation of P2P designs. It was Napster that kicked off the first-generation, putting MP3 and file-sharing in the limelight, exceeding 20M users at its peak. That success was short-lived. Napster became a lightning rod for litigation by a floundering recording industry, which found a convenient scapegoat for its declining revenue. (It would not be the first or last time that RIAA tilted at wind-mills.) Napster also had an intrinsic weakness: its design fell short of being truly 100% distributed. There was a point of centralization, a single-point-of-failure in Napster the company itself. While users downloaded files directly from each other, indexing and search of content was handled by servers operated by the corporate entity. That gave RIAA all leverage required in arguing that Napster can and should be held accountable for any infringing uses of its platform.

Future developers of file-sharing applications would not make that mistake again. First came Gnutella from the developers of WinAmp, which had been recently acquired by AOL. Its release lead to  awkward moments for the parent company, courting a merger with the content-rich Time Warner at the time. AOL tried putting the genie back in the bottle, but it was too late. Along came many more: Kazaa, Morpheus, eDonkey. These optimized the network topology by taking into account that not every user has the same bandwidth available. Instead of treating all nodes equally in democratic spirit, they deliberately capitalized on powerful machines on high-bandwidth connections, promoting them to “supernodes” responsible for coordination.

Users embraced the new generation of P2P applications— at least until the apps morphed into delivery vehicles for dubious adware and spyware bundled with the installers in some semblance of a business model. Network administrators on the other hand hated P2P with a vengeance because of the massive bandwidth consumption. At first it was colleges that started banning Napster. They claimed the prerogative of fairly distributing network capacity, although RIAA nastygrams no doubt also played a part in scaring the typically tech-illiterate and clueless administrations into policing their own student body. Later the crusade was taken up by ISPs on a much larger scale, with Comcast getting in trouble with FTC after it was caught manipulating BitTorrent traffic.

False positives

That brings us to this mysterious error message from the hotel network.

Kazaa has folded a long time ago. Its official client only ran on Windows. P2P moved on to third-generation designs best exemplified by BitTorrent. But somehow the network monitoring software used by this hotel retained the vestigial traces of the great War On File Sharing from early 2000s. Lying dormant all this time were heuristics on the watch for dreaded P2P traffic, ready to banish those users from the network for their transgressions. (That ban lasted approximately 24 hours in this case.)

As with all unmaintained software, these rules can go haywire when the world changes. It turns out that in this case the omniscient network monitor misidentified Google Hangouts video-conferencing for P2P file sharing. A quick search shows the offending traffic pattern cited in the error message— UDP traffic to port 19305— is among the documented ports associated with Hangouts application. Similarly a reverse DNS lookup for the destination IP points to “” domain, which is a Google domain as expected.

Protecting users from themselves?

By itself a false-positive in a network monitoring application is not exactly news. Such heuristics are notoriously unreliable and subject to errors. For starters a given protocol is often implemented by multiple pieces of software written independently of each other. Some may be open-source, others proprietary, yet others “adware” supported by bundled applications. If they are implementing the protocol faithfully, they will look very similar to an external observer watching bits on the network. Just because a machine is emitting network packets that looks like the one emitted by Kazaa does not mean it is Kazaa running on that machine.

Putting aside that conceptual problem, what makes this example truly egregious is the alarmist language in the message and vindictive approach taken by the hotel against would be file-sharers. What is being achieved by singling out P2P applications? “Online activity flagged as malicious.” Malicious towards whom? Certainly not the owner of the laptop. If the hotel has taken on the paternalistic role of protecting customers from dubious software on their own device, where do we draw the line? Should they also start performing deep-packet inspection or blocking known malicious websites?

For that matter, the response after detecting P2P activity is disproportionate. If the network management system can identify file-sharing traffic (it obviously can not, but let’s grant the premise) why not specifically block those connections? Why retaliate by keeping users completely off the network for an extended period of time? Even if we grant the premise that hotels somehow owe it to their guests to protect them from their own malware- which, let’s be clear, file sharing software is not– quarantining the user completely does not further that objective. Redirecting users to a web page that explains risks involved or offers assistance with removing the offending malware is a more constructive approach.

Searching for a motive

Because the standard it’s-for-your-own-good excuse does not hold up to scrutiny, we need to look deeper for motives. There are two usual suspects.

“Network management”

This is a euphemism for allocating scarce bandwidth fairly between users with competing interests. This was the putative excuses colleges/universities initially offered for blocking Napster: with everyone downloading music, the application was consuming significant chunk of campus bandwidth. It is also the original excuse ISPs resorted to when explaining their throttling of BitTorrent. P2P was particularly embarrassing for ISPs because it revealed one of the worst-kept secrets of Internet service in the US: while an ISP may advertise 10Mbps speeds to subscribers for a given price, it does not have anywhere near the capacity to provide that speed to all subscribers at the same time. As long as few are maxing out their connection, customers may indeed attain speeds near that advertised upper-bound. But if everyone gets busy downloading music at once, no one gets close to seeing anything close to the effective bandwidth they were mislead to believe they were paying for.

A cafe or hotel providing wireless access to guests faces a similar problem of apportioning its outbound bandwidth, and here there is even less expectation of guaranteed service. Internet access is an incidental amenity not unlike a swimming pool; unlike an ISP selling broadband Internet, it is not the main line of business for the establishment. There is something to be said about fair allocation of scarce bandwidth and preventing one person from consuming a disproportionate share.

But such limits are by definition content-agnostic: a 5MB file occupies exact same number of bits whether it is downloaded off P2P network or streamed from iTunes. There is no justification for singling out a specific protocol, much less one specific application such as Kazaa for exclusion.

Contributory infringement

Avoiding legal headaches related to copyright infringement may be another  motivation to block file-sharing. This blogger is not a lawyer and will refrain from commenting on the creative theories of liability required to hold a hotel responsible for what guests download on the network.


There is another possibility of course: this “feature” of the hotel network is an ancient relic of a different era. In that less-enlightened time, organizations and businesses were cowed by RIAA/MPAA lawsuits into policing the activity of their own users, forking over for ineffective and blunt network management technologies to demonstrate their commitment to the higher cause of copyright enforcement. Times may have changed. Yet those “features” built into the network keep cropping up in unexpected ways.



Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s