Not true at all, most YouTube videos are offered as plain webm files.
Also, keep in mind that recording TV's is legal.
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.
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.
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.