Hacker News Reader

Comment by decasteve | Hacker News Reader

> ...intent is factored into the law.

What gets lost or missed is the underlying intent of the protocols and tools being used to share content. An http server serves files independent of the client/user-agent–that's how the web works. If a work is published this way then that's the expectation. If YouTube and the RIAA want it to work another way, then use a different protocol/medium and put the content behind a login and limit access.

I'm not saying people should be free then to republish/share copyrighted works. Just that we are free to use tools to retrieve files that have been served openly via the web.

View on HN

Right, but even when offering free resources to the public you still maintain the manner in which they are accessed and distributed.

It's not as clear as let's say access to a public park on private land. But the idea would carry weight that youtube may control the manner in which their publicaly accessable website may be accessed.

Let's say you can access via the YouTube app which does not require an account, and now you reverse engineer that app to bypass the app all together. It's a bit like cutting a hole in the fence around the playground.

I'm not a fan of what happened it's just clear to me why it happened.

This was indeed bound to happen. The discussions we have are what's needed to decide how the internet/web moves forward. And there's a bit of cake eating and having it too from both sides.

There's an expectation from the publishing/serving side of the equation that the content is being served to a proprietary app or a web browser that works a particular way. With the browser being one of Chrome, Firefox, etc., along with Google's YouTube apps.

On the user side, especially those who understand how the content is served, that the browser is not the only abstraction allowed. Google themselves run bots to scour the internet employing all sorts of tricks to access and index content. There's a fundamental way in which the http protocol works and its content served that is client agnostic. Everyone, Google Search most of all, have benefitted from this.

Making tools other than browsers illegal will fundamentally break the internet in my opinion.

> An http server serves files independent of the client/user-agent–that's how the web works. If a work is published this way then that's the expectation. If YouTube and the RIAA want it to work another way, then use a different protocol/medium and put the content behind a login and limit access.

They don't use HTTP. HTTP is used to bootstrap the player, not to feed the content. The content itself is served over another protocol such as RTMP and that protocol is a streaming protocol (it sends chunked data) and it wasn't intended for downloading files and writing them to disk as a singular binary blob. Obviously it can be used that way but it's fair to say services like youtube-dl are using the protocol in ways it wasn't originally intended to be used rather than content owners serving content on a protocol that was always designed for distributing files.

It's a bit like recording something on VCR from an RF signal; there's nothing technically stopping you from doing that as recording a TV show is technically equivalent to watching it. But equally you can't blame TV networks for using RF to air their broadcasts knowing that risk is there.

The problem is any delivery system you can dream up for enabling consumers to view a recording will have some unintended method for copying said content. Even if it is as low tech as someone physically sat in a cinema with a handheld camcorder (how many movies have been leaked online that way?!)

This is why I keep coming back to the point that you can't use science to argue a legal issue; they ultimately serve different purposes. Science can prove something can be possible, the law is there to argue if something should be allowed to happen (putting aside for one moment the variety of differing opinions about morality et al). So if you have an issue with the youtube-dl take down then you need to treat it as a legal problem rather than a misunderstanding of a technical solution.

> They don't use HTTP. HTTP is used to bootstrap the player, not to feed the content. The content itself is served over another protocol such as RTMP and that protocol is a streaming protocol (it sends chunked data) and it wasn't intended for downloading files and writing them to disk as a singular binary blob. Obviously it can be used that way but it's fair to say services like youtube-dl are using the protocol in ways it wasn't originally intended to be used rather than content owners serving content on a protocol that was always designed for distributing files.

Not true at all, most YouTube videos are offered as plain webm files.

Also, keep in mind that recording TV's is legal.

> Not true at all, most YouTube videos are offered as plain webm files.

It's been a while since I've written a video streaming scraper but it used to be quite common for a file to be served over HTTP but that file was a small "shortcut" type file to an RTMP stream. So a webm file wasn't the content itself but instead a pointer to where to stream the content from.

I'd imagine the same would still be true for YouTube since, like most other video streaming services, YouTube can adaptively switch bitrate depending on the bandwidth available to the end user. That seamless switching can't be done with a HTTP GET of a singular video file but it can happen effectively with a chunked streaming protocol.

> Also, keep in mind that recording TV's is legal.

Yes but with caveats, depending on the country.

Though it is worth noting the only reason America and UK law is so relaxed regarding VCR usage is because corporations making video recorders were taken to court by film studios and won their case. So once again it comes down to presenting a legal argument rather than a technical one.

This hasn't been the case in a long time, most streaming sites no longer do RTMP unless specialised cases, because of scaling and ease of scaling. They're mostly HLS or equivalent now.

Ah yes, I'd forgotten about HLS (doh!). But even there HLS, while based on HTTP, is still very different to the kind of GET requests the GP (or however many posts down it was now) suggested when they talked about downloading a file.

HLS is not about downloading a file, it's about downloading chunked data. It wasn't intended (though it can't be prevented) that the chunks would be used to recreate a video in full, unlike with a stream of bytes from a HTTP GET which are very much intended to be recreated in full at the receivers end.

HLS really only uses HTTP transport as headers to circumvent many firewalls (and in fact you can do this with RTMP too, eg RTMPT) but aside from that it's a completely different beast to GET.

Reply on news.ycombinator.com