Cause merry mayhem by voting for rtmpdump as "Best Multimedia"
Nominating rtmpdump for "Best Multimedia" project had the desired effect
of getting it up as a finalist. Vote here for rtmpdump:
Why I, Adobe, Should Stop Peddling DRM
DRM does not work and you, Adobe, were foolish enough to drink the
cool-aid. DRM does not work for many reasons:
DRM and mass-distribution are mutually exclusively incompatible.
A maths joke i saw once goes, "Security tends to zero as the number of
idiots tends to infinity". The thing is: it's true! It only takes one person
to screw up, and it's Game Over.
Do a maths experiment. Take any number (1,000; 1,000,000), and put
it through this formula: Probabilty = (1-(1/N)) to the power of N.
What you're doing is this: if the probability of DRM _not_ being
bypassed by one person is 0.999999, and you have a million such
people, the probability that DRM remains secure against a million people
is 0.999999 multiplied one million times. It comes out, every time, at around
36.7%. The moment that you go up by another factor of ten in the number
of people, but leave the "bypassing" probability the same (e.g 0.999999
multiplied ten million times), you can see instantly that things fall apart.
In this simple example (0.9999999 multiplied ten million times)
the probability of DRM remaining secure is:
0.05%. That's Zero Point Zero Five Percent. near as damnit: zero.
Can you see, Adobe, how DRM is therefore clearly mathematically
incompatible with mass-distribution?
Water flows downhill. If you add in difficult prohibitive measures
which restrict peoples' choices and freedom to choose, they simply go with
the next easiest option.
Money talks. If you add in expensive "we don't trust you" hardware,
the cost of the extra silicon, and the requirement to have more expensive
CPUs running the paranoia distrusting encryption system... all that happens
is that people go, "why is this more expensive compared to this cheap
Korean trash? and what is this my friends say about having to throw away
all their existing older equipment?"
Let's say that you decide to make actual secure
DRM instead of "fake" secure DRM, by utilising actual passwords
(e.g. PIN numbers), and putting in place Public Key Infrastructure.
All you've done is increase the barrier to acceptance, and again
increased the cost! People will forget their passwords. They'll ask
their friends to record the show and send them a copy.
The complexity of deployment of DRM increases the time-to-market
of a solution, making it uncompetitive.
From every perspective, DRM is a failure. From a simple mathematical
perspective, DRM is a failure. From a psychological perspective,
DRM is a failure. From a technical perspective, DRM is a failure.
From a financial perspective for the users, DRM is a failure. In a
competitive market, DRM is a failure.
The solution: you just have to go with the flow, accept the reality
and work with people's desires and abilities and financial
budget, providing them with the easiest and affordable
technical solution to get them their content and the multimedia
interaction that they desire. By being the easiest to work with
(which other than your support of DRM, Adobe, it does have to be
said that your products are by far and above the easiest way to
present multimedia) you automatically gain market share.
The sooner you, Adobe, and your customers, accept this reality, the
quicker that everyone can get down to the business of developing
exciting technology (such as RTMFP) that is actually useful
RTMP is an important network protocol which is utilised to communicate
audio and video. Adobe, you have no right to restrict internet communication
or to tell people how they can and cannot communicate, or in what format,
and can go fuck yourselves if you think that you can bully people into
submitting via a blunt instrument called the "Digital Millenium Copyright Act",
a law which should never have been allowed to have been bought into
U.S. law in the first place.
RTMPE is an extension to RTMP to include encryption of content.
A clean-room specification is available here.
Please distribute freely and widely. Please implement and distribute
free software source code implementations even wider.
Note to Adobe: fuck you and your attempts to call the use of industry
standard crypto primitives "proprietary".
Download rtmpdump 1.9 Source code
Source code of rtmpdump v1.9 is available here.
A lovely November 2009 "Friday 13th" release.
Download rtmpdump 1.6 Source code
Source code of rtmpdump v1.6, with the get_iplayer application removed
(because i don't like the idea of providing people with the means to rip
off copyright content), is available here.
There is also a bittorrent tracker running: here's the rtmpdump v1.6 torrent
Unpacked source (for the adventurous)
Why would I remove get_iplayer yet still provide the source to rtmpdump?
get_iplayer is utilised to make copies of copyright material.
encouraging people to do that is stupid.
by contrast: rtmpdump is one of the VERY few free software
implementations of a really important networking protocol,
implementations of which I have been hunting down and looking for,
for a considerable amount of time.
my interest in RTMP is to encourage the creation of free software
real-time audio/video communication software, and, as you can see
from e.g. Red5, there do exist implementations,
just very few of them.
Red5 only contains a server-implementation (in java).
The python project rtmpy aims to be a free
software implementation of an RTMP library, whilst Tape intends to be a full
streaming server (in Python). rtmpy is in active development.
There is a java client implementation of RTMP, called Flazr.
As of 2nd June 2009 (just two weeks after Adobe issued the take-down notice),
Flazr also has RTMPE support.
Congratulations to Peter, and thank you to Adobe: none of this would have
remotely happened, if you hadn't brought RTMPE to people's attention.
SWFDec has a partial and experimental implementation of RTMP.
swfdec is client-only.
Gnash has a partial and experimental implementations of RTMP.
Gnash has both client and server, sharing the same common source. Cygnal
is making particularly good progress, as a server: video can already be
streamed from it, with real-time video planned for Q3 2009.
libRTMP by boxee contains an RTMP client library, and was used as
the basis for rtmpdump.
haxeVideo is a server implementation of RTMP in Haxe.
crtmpserver is a server implementation of RTMP that has implemented
(as of 25th may 2009) the RTMPE protocol.
Mammoth, formerly known as OpenFMS, is a server implementation
that has implemented an RTMPE-compatible algorithm known as
"H264-compatible and DH handshaking".
RubyIzumi is an implementation of an RTMP server in Ruby.
Throwing out the baby with the bathwater, by going after free
software developers with a DMCA take-down notice, is just stupid.
Translation: "Adobe - get fucked".
For fits and giggles, here are a few fun items involving proprietary
Applian caved in and agreed:
Translation (sing along if you like): "Adobe come and geeet uuus, Adobe ..."
Is the RTMP protocol documented anywhere?
Yes. Just not by Adobe.
Here is a list of web sites that document the RTMP protocol:
Translation: "Adobe - go fuck your proprietary implementation"
Is this server in the United State?
It's in Maidenhead, UK. So, no. It isn't. Translation: "Adobe - fuck off".
Analysis of RTMPE
RTMPE is definitely not a "Copyright Protection" mechanism.
An analysis of RTMPE (see "Analysis" section)
shows that RTMPE does nothing more than what SSL already does
(provide end-to-end secrecy, except without the protection against
man-in-the-middle attacks - RSALabs on DH, para 5)
and simply mathematically links a publicly-downloadable and
publicly-obtainable SWF file to the connection.
Bottom line: All the information required to obtain the content is
publicly available. There is no "security".
If the information isn't publicly available (such as the SWF file to
be executed in the web browser) then the content cannot be obtained,
Unfortunately, this leaves Adobe in the shit, if they've been
claiming that SWF verification is somehow "secure". Anyone reading
this who has bought into Adobe Technology on the basis of "security"
or "protection" is advised to initiate legal action against Adobe,
seeking compensation and damages for deceiving them about the level
of "protection" of their Copyright material.
From Adobe's Web Site:
"We have resolved a dispute with Adobe Systems Incorporated, [...], by agreeing
not to circumvent any Secure RTMP Measures developed by Adobe."
Well, that was stupid of you - you lent weight to Adobe's belief that you
were actually doing any circumventing, and to their belief that there is
anything "secure" about Adobe's RTMP "measures". So, Applian - go right
ahead and put RTMPE right back in, because you will still be complying
with your agreement with Adobe. The minute that they actually put any
secure RTMP measures in, then you might get left behind, compared to all
of the Free Software implementations that are being created, but hey: you
can always fix that by just releasing the source code of your application
and then contacting the Software Freedom Law Centre, if you ever hear from
Smaxe java client, for research purposes.
Hmm, that means he can't apply to the softwarefreedom.org for help if he
gets smaxed with a DMCA takedown notice, can he.
'(swf verification) ensures that only your SWF or AIR files can
connect to your application or content on Flash Media Server'.
This is false. The correct interpretation is:
"if anyone can obtain the publicly-available SWF or AIR file (or a hash of it,
and knows the SWF or AIR file's size) they can also connect to your application
Translation: "Adobe, you fucked yourselves, royally, without anyone's help."
Are there any 'encryption' keys in RTMPE?
No, there are no encryption keys in RTMPE. There are however three
magic constants which are used as input. And, remember, also, the publicly
accessible SWF file - the one which you put on the web site to view the
content - is used as input to the algorithm as well (or, at least, its
hash and its size).
So if you want to get genuinely stupid, and consider the sentence
"Genuine Adobe Flash Player 001" to be a quotes key quotes, then
by that definition, so is the publicly accessible SWF file also a
quotes encryption key quotes.
This raises some hilarious implications:
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.
Actually, all Free Software HTTP Proxy and Web Browser projects should
not risk being subjected to DMCA takedown notices and should block all
swf files, just to be on the safe side.
... after all, it's not like they can analyse the content being streamed
by the SWF file, because that would require either reverse-engineering
the SWF file on-the-fly in order to find out if it uses RTMPE, or setting
up a complex system of analysing network traffic (again, which would
be, like, illegal, like, cos you'd have to, like actually identify RTMPE
and would need to, y'know, know the algorithm?).
Presumably, though, on detection of RTMPE, then, well, by that
time, it's too late: the browser will have already received and be
executing the SWF file. So, presumably, right, like that joke computing
language which had a "GO FROM" statement and an "IF THEN ELSE UNLESS"
construct, you'd have to somehow undo the past, and, presumably, if that
wasn't possible, try to hide the fact that you were unable to predict
the future, by deleting incriminating evidence from the user's machine
and then crashing it.
Who else is hosting the RTMPE source code?
Anyone else who would like to be added to this list, contact me via the
methods shown on my main page. You will
be expected to indicate that you do not encourage copyright infringement.
Bittorrent sites hosting torrents for the rtmpdump v1.6 source code.
These have sprung up instantly, the moment that the slashdot article
appeared online. Ain't ya just gotta love that "fuck you, Adobe" attitude...
Authoritative Opinions on Adobe's actions
Even my seven-week-old daughter is able to give her valuable and authoritative
opinion of Adobe's decision to use the DMCA to restrict Software Freedom: