Talk:Protected Streaming

Not DRM

I am sorry to say, but I have the suspicion that RTMPS/RTMPE are NOT any kind of DRM technologies.

They are implemented such as to avoid the man-in-the-middle attack, or eavesdropping. Since the player gets (or has; supposedly the former, however) all the necessary information for decryption, anyone having access to the player can just decrypt and, as such, save the stream to their storage medium.

In contrast, we have the (for me, still unexplored and thus probably obscure) concept of Flash Media Rights Management, as of here: http://www.adobe.com/products/flashmediarightsmanagement/

I would like (and will) be bold, if necessary, but it'd also be nice to see some opinions. crusher (talk) 12:45, 12 May 2009 (UTC)[reply]

it's not DRM. see http://lkcl.net/rtmp/RTMPE.txt - "Analysis Section". RTMPE is purely an SSL-like algorithm and a way to make sure that the recipient of the content happens to know a hash of, and the size of, the SWF file that is *expected* to be executed in the user's browser. To clarify: you download the SWF file from the site; you calculate its hash; you calculate its size, and that alone is enough information to be able to get an RTMPE-compliant server to give you the content. in other words: purely from publicly accessible information alone, you can get the content. that's not a copyright protection mechanism, that's a con. Lkcl (talk) 21:50, 24 May 2009 (UTC)[reply]

It doesn't work, but no DRM technology works. What makes it DRM is what it's *attempting* to do, not whether it actually achieves its goal. It's attempting to stop you from having a usable copy of the stream on your hard drive. That's DRM. 216.59.252.65 (talk) 15:12, 20 October 2009 (UTC)[reply]

well, then it fails miserably at that, too. Lkcl —Preceding unsigned comment added by 217.147.94.29 (talk) 18:04, 21 February 2010 (UTC)[reply]

DRM is designed to manage the rights to own/access digital content (Digital Rights Management). For any content to be truly protected by a DRM technology, the paradigm is that the content itself must be encrypted, to be decrypted using a key that (presumably) the user will purchase in some form of transaction, and which will be used by the consuming program (player) to decrypt the encrypted content. RTMPE is an encrypted connection, used to verify that the SWF object being used to consume the content is "allowed" to consume it (play it for the user). The content is not encrypted at all and therefore RTMPE cannot be called a DRM technology. —Preceding unsigned comment added by 81.98.164.179 (talk) 12:43, 2 June 2010 (UTC)[reply]

rtmpe has no protection against man-in-the-middle. rtmps does, assuming the remote server has an X.509 certificate and the client actually validates it correctly. But rtmpe doesn't use certificates, it uses an anonymous handshake so it has no way to protect against MITM. And given the other goofs Adobe has made in this area, I wouldn't bet that their certificate validation is any good either... Highlandsun (talk) 18:41, 10 April 2010 (UTC)[reply]

The name "Protected Streaming"

Using capitals for the article title "Protected Streaming" implies it's a proper noun or is otherwise a tradename. Google can't find any mention on adobe.com of the use of "Protected Streaming" as capitalized words, and the USPTO doesn't list any trademark by this name. Adobe does use it repeatedly as a generic description of a feature offered by some of their products. I recommend renaming this article to "protected streaming" or "protected streaming (Adobe Flash)". --Underpants 00:49, 24 May 2009 (UTC)[reply]

no - the page should be called RTMPE, because that's what it is. it should be mentioned in that page that adobe call it "Protected Streaming". Lkcl (talk) 22:11, 24 May 2009 (UTC)[reply]

There may not have been any "Protected Streaming" name in May 2009, but they are certainly advertising it as an entity in its own right, as of late 2010. E.g. this document (among many others) is returned by the above Google search now. Highlandsun (talk) 20:04, 23 July 2011 (UTC)[reply]

Hard to understand

The focus of this article seems to be more about how bad the technology is rather than what it is. This makes it difficult to understand, and there's the risk that most of the content gets thrown out as a matter of Wikipedia policy. I also don't like the use of the term "SWF file", as it seems ambiguous. I understand that SWF may contain audio and video media, and this could lead to confusion about what is being validated. I don't know if it's the right word, but I'm going to call it an applet.

So far as I can tell, we start with the assumption that the virtual machine (Adobe's Flash Player) is trustworthy. The virtual machine describes the applet to the server (by means of a digest), and if the server recognises the applet and is satisfied that that applet is also trustworthy, then the server will send content to that applet via the virtual machine.

adobe's VM trustworthy? *ROTFL* Lkcl —Preceding unsigned comment added by 217.147.94.29 (talk) 18:05, 21 February 2010 (UTC)[reply]

If the virtual machine is not trustworthy then it may misrepresent the applet as one that the server trusts. In this case the server can be fooled into sending content anyway. In this case it is possible to modify the applet or the virtual machine itself to capture and/or redistribute the content sent by the server.

Is this correct? --212.44.20.129 (talk) 18:28, 31 December 2009 (UTC)[reply]

it's irrelevant / moot. it doesn't matter if the virtual machine is trustworthy or not, because you have to use a communications network to talk to the VM. you can't otherwise communicate between the server and the virtual machine: the only way to do that would be to have the VM actually running on the server, and, duh, that defeats the entire purpose of trying to distribute data to multiple sources. so it's the PROTOCOL which has to be trustworthy, not the virtual machine. and my analysis shows that the protocol "encryption" is a steaming pile of far-flung cow-dung, so much so that i have difficulty using or encouraging people to use the word "encryption" or the word "security" when mentioning RTMPE. lkcl —Preceding unsigned comment added by 217.147.94.29 (talk) 18:10, 21 February 2010 (UTC)[reply]

The article focuses on the failure of the technology because that forms the bulk of the publicly-available information about it. Adobe have released very little information about it, beyond a few marketing claims that have been disproved by the research cited in the article - which leaves us with little to talk about other than that research. While the technology is widely used by many major contemporary video distribution systems, and hence is notable, we can't say very much about it without engaging in original research or technical cruft. It would be straightforward for me to write up a detailed explanation of how it works based on the research, but that's straying a little too close to original research for my taste. I think the best thing to do is let this one sit a while until more sources become available. Alternatively, somebody could write a larger article and merge this into it (I had a look for somewhere to put it, but found nothing); in that sense, the issue could be described as a shortage of articles about video distribution technologies. Asuffield (talk) 01:33, 7 March 2010 (UTC)[reply]