Ask HN: It's impossible to stop someone from downloading a stream, correct?

[DATACOMMANDER]

I just want to make sure I'm not missing something. By "[download] a stream" I obviously mean "save video that you're streaming to permanent storage". I'm doing an interview project that involves working with a "streaming as a service" (terminology?) provider, so I thought I'd go to PBS's website and download some video to use in the project. I found that all of the video there is only available to "stream", and in fact uses a video player and "streaming as a service" provider that's in the same space as the company I'm interviewing for. Five seconds on google revealed a "PBS video downloader", which I assume just locates the video segments in the browser's temp folder, stitches them back together, and saves them to a location that won't be cleared on reboot.

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.

[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?).

[klingonopera]

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...

[Rannath]

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.

[phillipseamore]

True, it's an ideological difference not a technical one.