For many, Web 2.0 is about democracy, user-generated viral marketing, social networking, and sharing “public goods”. This has led to a large number of audio/video content distribution/sharing sites - such as YouTube for video sharing, Myspace for indie artist discovery, Pandora/Lastfm etc for music discovery/online radio, Imeem/Myspace for social networking, and a gazillion others. With this new “network as a platform” model, Adobe’s Macromedia Flash Player, with its market share at 96% of Internet-enabled desktops in mature markets, is the natural choice for content distribution.
Let us ignore the case of user-uploaded copyrighted content or illegal bootlegging websites for now. While everyone’s talking about AllofMp3.com & YouTube, no one seems to have talked about the incredible amount of copyrighted content that is readily & “freely” accessible through services like online radios that haven’t implemented media delivery via Flash Players/objects securely.
The following are the top 3 issues with the way Flash is used by these content-distribution services:
1. Using HTTP to fetch audio(MP3) or video(FLV) content. Macromedia does provide secure alternatives like Flash Communication Server and the closed-source RTMP protocol (say over HTTPS) to stream sensitive content. However, few sites use it. HTTP allows a simple web proxy controlled by a user to log all the URLs generated by the online radio Flash object. Ironically, most of these sites have highly randomized URLs to deter easy access, but since they appear in clear text on the wire, they can be replayed easily to get the copyrighted original-resolution audio or video.
2. ActionScript driven client-side DRM. This is a bad idea for at least 2 reasons. Firstly, client-side security is a bad-idea in general, since it assumes a well-behaved client. Secondly, the Flash SWF is now an open object format, and SWF decompilers have been available for quite some time now. SWF objects are essentially the various UI content (bitmaps, vectors, etc) packed together, and the ActionScript bytecode that describes the relationship between these components, and the timing & algorithmic information for the Flash movie. So, the decompilers, umm.. not disassemblers, actually give the original highlevel ActionScript source code as was fed to the Flash compiler including the variable/object names etc. All design secrets like the randomization algorithm used for the URLs, passwords, etc are thrown wide open.
3. Using local PIE-SOL objects to store DRM information. Another brain-dead idea. Online radios for copyrighted content naturally have to operate under restrictive licenses. So they implement restrictions that say limit the number of times a listener can skip to the next song in an hour, or prevent the listener from skipping back and replaying the previous song etc. The secure place to store skip counts and other session information is on the server. However, the more popular choice is the local SOL object readable from the Flash object. Unfortunately, the SOL format has also been reverse engineered, and editors are available that can tamper with this information easily. Infact, SOL objects can be deleted to lose all the skip/play counts and other session DRM history and start afresh.
It is important to note that this blog is not pointing out new weaknesses, rather drawing attention to the fact that various simple security best practices for media content distribution are being widely ignored. This leaves libraries of copyrighted content potentially at risk.