On May 8, Adobe submitted a takedown notice to SourceForge.net requesting that the rtmpdump project be removed from their site. SourceForge.net removed the project this past week. For more details, see the original Slashdot post, an updated Slashdot post, and a new post from Linuxcentre.
Reading deeper into the takedown notice, we see that Adobe believes rtmpdump “can be used to download copyrighted works” and lists some pages on Channel 4 as examples. The takedown notice also states that Adobe “is the developer of technological protection measures that protect content from unauthorized copying and distribution”. This suggests rtmpdump was targeted because it circumvents technological protection measures. A post on the XBMC forum confirms that Channel 4 uses RTMPE, an encrypted version of RTMP, used to transmit video with Flash. The post also links to a Replay Media Catcher page discussing how Adobe forced them to remove RTMPE support. Though the takedown notice doesn’t state it explicitly, we can be fairly sure from these points that Adobe is targeting rtmpdump because it allows you to download content transmitted using RTMPE.
The major implication of this takedown notice is that Adobe has definitively told us that a fully-compliant free software Flash player is illegal. This is because RTMPE is part of Flash, circumventing RTMPE is illegal (in the US at least), and Adobe will never give a key to a free software project since they cannot hide the key. As a result, Flash cannot truly be a standard even if we ignore the codec patent problems.
Adobe’s takedown of rtmpdump reminds us that Adobe does not fully support open standards. As a result, web designers and anyone else who cares about an open web should steer clear of Adobe technologies, in particular Flash. Adobe was given the choice of supporting open standards or appeasing big media and they chose big media. Make no mistake, Adobe is an enemy of the open web.
Are the rtmpdump guys finding alternate hosting (outside the US)?
There are several problems with adobe’s approach:
1) there is no “encryption key”. there is, however, a magic constant (actually, three). the first is “Genuine Adobe Flash Player 001”; the second is “Genuine Adobe Flash Media Server 001” and the third is some unpronounceable random crud which you can get by looking at http://lkcl.net/rtmp/RTMPE.txt
2) there is no “protection”. RTMPE is an algorithm that uses industry-standard crypto primitives, magic constants and publicly-available information (the SWF file) to do two things:
a) provide end-to-end secrecy, just like SSL
b) link knowledge of the size and a hash of the SWF file to the connection.
adobe claim [translation: lie to their customers, thus exposing themselves to lawsuits] that this “validation” process _guarantees_ that only someone with the SWF file (that was publicly accessible and publicly downloadable from a web site) can download the content. what they imply from that is that only someone who _executes_ the SWF file can download the content, which is blatantly false.
from the algorithm: if anyone knows the SWF file’s hash and its size, they can use the algorithm to access the content. executing the SWF file or even having it _at all_ is irrelevant.
3) if you want to get arsey about it, and say that the words “Genuine Adobe Flash Player 001” are an “encryption key”, then you have a problem, because there is further input into the “validation” algorithm: the SWF file itself.
that makes the SWF file also an “encryption key”.
… whoops.
you can immediately work out the implications, here, for yourself, but here’s some of the more hilarious ones:
* how can you claim that a key is secret, yet make it publicly available on the internet?
* if you want to keep this “key” secret, surely you should go after all web browser distributors, and everyone who has HTTP cacheing technology, DEMANDING that they “protect” – remove – SWF files from caches.
this latter is quite easily achieved. you just block *.swf files.
> a) provide end-to-end secrecy, just like SSL
… except without the man-in-the-middle protection.
Eh. We’ve known Adobe is evil for a long time, and Flash sucks. But the mindless drones will still keep on using it, even despite this blatant dishonesty. Not enough people are left who are awake enough to care.
And to answer the earlier question, yes, rtmpdump is now being hosted by the mplayer team. http://rtmpdump.mplayerhq.hu
The rtmpdump code has been completely rewritten in C, resulting in 1/2 the memory and CPU use of the original C++ code, fixing all the portability issues of the original code, and also cutting the load time down by more than half. It now runs well even on limited-resource systems like Android G1 phones. The code has been restructured to make it easily usable as a standalone library, and support for server-side functionality is also available now in the SVN trunk.
Just a rant, I like RTMPDump – quite a lot actually. I believe it is the only way to download music from MySpace. I’ve seen other RTMP downloaders, some completely broken, and some that only download a specific flavor- but not MySpace, you need the rtmp:// link and rtmpdump to do that. I created a *.bat file to aid with the process of supplying an rtmp stream to download from, a front-end, but it’s still cmd-based and not that good, a much better front-end is required. also, it should also be combined with in network traffic-logging interface with no requirement for a rtmp stream resource, and which will log the connection, download the stream and display info and whatnot.. that’d be a dream. it’s sad we live in such a horrible world where information is withheld, and the general public swallows it without question, they don’t ‘need’ all the technical do-what, or all the premium features on their HDTV set, they just want cable.
there’s an easier way BRuc
download STRACE from Microsoft’s site
run it and you will see the urls where these “streaming” media files come from
there is no difference between the process streaming and downloading
the data moves from computer A to computer B, via many other computers
it’s computer B’s choice whether to save the data for later or not
nothing computer A can do to control that
making it “inconvenient” is not control, it’s a lame form of “coercion”
adobe relies on peoples’ 1. lack of technical knowledge (i.e. knowing that the data can be easily saved), 2. lack of legal knowledge (people are easily intimidated by threats of frivolous litigation) and their general laziness.
it’s a shame that people believe adobe when adobe tells them adobe software can “protect” content. it cannot. the data is being sent from A to B. it’s the nature of the internet.
not every user is dumb nor lazy, and the truth will be told, no matter what tricks adobe tries to pull.
+1
+1
Hi !!! Good job!