[pwg]

You are not missing anything.

Streaming is merely a subset of "downloading" where the data is decoded and displayed on screen as it "downloads" generally without also being saved into permanent storage.

From the servers viewpoint, it is merely pushing bits to a client.

The client is merely receiving bits from a server (and receiving bits from a server is downloading).

And, yes, given a technically competent user owning the client, the client can be modified to save the downloaded stream data to storage.

Much of the streaming work is "security by obscurity" -- the systems only provide security because the end user either: 1) lacks the technical knowledge to save the data or 2) lacks the desire to do so (presuming they do possess the technical knowledge).

[DATACOMMANDER]

>Much of the streaming work is "security by obscurity" -- the systems only provide security because the end user either: 1) lacks the technical knowledge to save the data or 2) lacks the desire to do so (presuming they do possess the technical knowledge)

That's what I thought. I do think that a streaming video provider can provide added value, especially for live streams--e.g., by providing adaptive bit rates--but the terminology itself has a strong "wishful thinking from the business side" smell to it.

[Nextgrid]

The only way to (somewhat) prevent this is if you control the client, like games consoles and phones. Even then, with enough effort it can be broken, see the PlayStation hacks and iOS jailbreaks.

At the end of the day, if you're pushing data to a client they can save it, and if you provide the client but the user still has physical access to it they can still crack the restrictions enforced by the client and get the raw data stream.

DRM merely makes this more difficult (and sometimes causes problems for legitimate users) but can never make it impossible (until quantum cryptography becomes mainstream maybe?).

[pwg]

> never make it impossible (until quantum cryptography becomes mainstream maybe?)

Even in the 'quantum cryptography' world it still has a hole. In order for the client to "use" (i.e., view, play, etc.) the encrypted stream, the client needs:

1) the encrypted stream data

2) the key necessary to decrypt the data (because without the key, the client can't decrypt the data in order to play/view it).

Item #2 is where the breaks will always occur, even with quantum cryptography. An attacker does not have to break the cryptography, they just have to find where the key exists that allows decryption and once they have that key, they can decrypt as they like (at least for that stream, assuming one-off encryption for that one stream).

If you give people a locked box, and you also give them the key necessary to unlock the box, some number of them will use the key to unlock the box, even if you tell them not to do so.