Ask HN: It's impossible to stop someone from downloading a stream, correct?
7 comments
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).
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).
>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.
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.
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?).
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?).
> 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.
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.
Not all streaming services are DRM-free, though.
This article [0] is 13 years-old, I wasn't able to find a better source with a quick search, but e.g. Netflix, Amazon Prime and Disney+ AFAIK have DRM, and there's a whole scene of crackers around this, if you check Torrent-sites, you can probably find the aliases of the ones that are currently active.
Looks like you're lucky PBS has pretty lax security.
[0]: https://betanews.com/2007/08/09/netflix-drm-cracked-with-fai...
This article [0] is 13 years-old, I wasn't able to find a better source with a quick search, but e.g. Netflix, Amazon Prime and Disney+ AFAIK have DRM, and there's a whole scene of crackers around this, if you check Torrent-sites, you can probably find the aliases of the ones that are currently active.
Looks like you're lucky PBS has pretty lax security.
[0]: https://betanews.com/2007/08/09/netflix-drm-cracked-with-fai...
It is improbable to the point of impossibility, and somewhat worse than you've outlined.
To stop just me a device/service that prevented dling a stream would need:
-strong end-to-end encryption, otherwise you'd just grab the packets to recreate the stream, then save it.
-to be self contained, otherwise you'd just grab the stream from the audio/video output.
-to be tamper-proof, otherwise you'd just bypass the software by messing with the hardware.
To stop just me a device/service that prevented dling a stream would need:
-strong end-to-end encryption, otherwise you'd just grab the packets to recreate the stream, then save it.
-to be self contained, otherwise you'd just grab the stream from the audio/video output.
-to be tamper-proof, otherwise you'd just bypass the software by messing with the hardware.
True, it's an ideological difference not a technical one.
My question is basically, "That basic procedure can always be performed and there's nothing that can be done to prevent it, right?" Isn't the distinction between "streaming" and "downloading" ultimately just about how the video data is delivered? The server is incapable of ensuring that the client doesn't save it to permanent storage, and a "cooperative" client can always be modified by the person who controls it to save the data, assuming it's physically connected to a storage medium.
Am I missing something fundamental that allows there to be a hard distinction between streaming and downloading?
NB: I don't have any moral qualms with providing streaming video, I just think that the business folks wish that there were a technical distinction that, AFAICT, does not exist.