Comcast Unveils Its New Traffic Management Architecture

Late on Friday night, Comcast filed an overview of its new traffic management arrangements with the FCC. This is the long term replacement for its controversial practice of using forged TCP Reset packets to limit the use of peer to peer protocols.

The new system appears to be a reasonable attempt at sharing limited bandwidth amongst groups of users. Unlike TCP RST spoofing, it doesn't explicitly discriminate against some applications, and it doesn't threaten protocol developers with interoperability problems and uncertainty about network behavior.

Comcast's objective here is still largely to prioritize non-P2P traffic above P2P traffic. But the criterion they use is the amount of data a cable modem sends during each 15 minute period, which is a much fairer rule than examining the traffic protocol. The way deprioritization works is simple: high priority machines get to send data, and if there is any transmission capacity left over, the low priority machines get a share of that.

EFF is proud that our work helped to expose Comcast's misadventures in network management last year, and we're pleased to see Comcast returning to congestion management practices that are transparently disclosed and avoid protocol discrimination.

The new traffic management setup should not be confused with the 250 GB/month cap which Comcast announced last month; the two will exist side by side.

[Read the entire post]

DRM for Streaming Music Dies a Quiet Death

Yet another nail has been driven into DRM's coffin, this time for streaming audio (PCPro has a nice overview of the state of DRM for digital music).

Two of the leading on-demand streaming music sites, iMeem and LaLa, are not using DRM on their audio streams, instead sending the music as MP3s dusted with a dash of obfuscation. This is significant because both sites have been licensed by all the major record labels -- the very same record labels that were just last year pushing Congress to require DRM on all noninteractive webcasts. So it looks like the RIAA companies have changed their minds, dropping DRM requirements for the on-demand streaming music services.

This should put an end to legislation to mandate DRM on noninteractive webcasters. After all, why should these webcasters be in a worse position than the free, on-demand music services like LaLa and iMeem?

This also undermines the argument that DRM for music is necessary for subscription services. If the major labels have given up DRM for free, ad-supported (correction: iMeem is ad-supported, LaLa is free for a first listen of a track, 10 cents for repeat listening), on-demand streaming services like LaLa and iMeem, there's no plausible reason to insist on DRM for paid subscription services like Rhapsody and Napster 2.0. After all, there's no reason to think that those who prefer commercial-free subscriptions like Rhapsody are more likely to "pirate" streams than those who prefer ad-supported services like LaLa iMeem.

LaLa and iMeem each take slightly different approaches to streaming music. LaLa uses HTTP to download each requested song as an MP3 to your browser, but relies on aggressive "no-cache" headers and pre-expired date stamps to suggest that your browser not make a copy of the file on your hard drive. Using a packet sniffer to capture the entire HTTP session, however, easily reveals the complete MP3 embedded right after the HTTP headers.

iMeem also downloads and caches each requested song, but sends the MP3 as the audio track of a Flash Video file. This FLV file is typically saved (cached) on your hard drive as an obscurely named temporary file, which is overwritten when you request your next song (we mentioned iMeem's approach back in January, and it's essentially unchanged). Copy this temp file, however, and you can easily extract the audio track from the Flash video, saving it as a stand-alone MP3 file.

(The location of this TemporaryItems folder, and its equivalent on other operating systems, varies significantly depending on operating system and version. On some operating systems it's buried deep within the directory hierarchy, but it can be found automatically with standard tools.)

While the light obfuscation used by iMeem and LaLa might create a "speed bump" of inconvenience for users who want to keep the MP3 files, it doesn't rise to the level of a "technical protection measure" protected by the DMCA. In short, this is yet another example of why there is no legitimate business case for DRM on music -- it doesn't prevent piracy and it's not necessary to enable "new business models" like subscription or ad-supported music. (Of course, as the movie industry has demonstrated, DRM can still be valuable for impeding competition and putting the brakes on disruptive innovation. But it's hard to see how the law should protect those goals.)

[Permalink]