RIAA’s YouTube-dl takedown ticks off developers and GitHub’s CEO

It's easy for an individual site to break youtube-dl, and it happens often. Awareness/distribution don't matter if:

A) there is no central repository for updating the project//distributing updates B) threat of legal action deters maintainers from the project

Source: I added a custom YouTube player to my app several years ago, and, actually, besides my own reverse engineering, youdube-dl sources were quite helpful with figuring it all out. It didn't play those "protected" videos though.

https://gitlab.com/ytdl-org/youtube-dl/-/blob/master/youtube...

When I think of what it's like being an engineer (regardless of field), I think of the distance between "isn't the solution as simple as...?" and what the project actually looks like after a year in production after encountering the full domain of things that can go wrong.

Though youtube-dl also simply does more than what you're assuming. And ctrl-f for "drm".

I still think it's debatable whether youtube-dl constitutes circumvention of effective controls or not. This is the relevant definition:

> a technological measure “effectively controls access to a work” if the measure, in the ordinary course of its operation, requires the application of information, or a process or a treatment, with the authority of the copyright owner, to gain access to the work.

I'm not intimately familiar, but is youtube-dl cracking the rolling cipher, or using the keys that YouTube provides? I believe there is a very valid argument that using youtube-dl is not evidence of circumvention of effective access control systems. There are a plethora of other reasons one might want to use it. One perfectly legitimate example is if you want to watch a video in 1080p without constant buffering, but you aren't on a network connection that can support that. You're basically using your hard drive as a much, much larger buffer. You can often even play the videos with the same browser that opened YouTube, so it really does become effectively cached content (albeit a cache external to your browser).

I think they would also have to demonstrate that downloading one of those videos is a copyright violation. You could argue that as long as the video is available, it should be valid for you to cache those videos. If I'm going on a plane, or I know my internet is going to be out, is it really a DMCA violation for me to download those videos and time shift my viewing to when my internet is out?

> Through the use of the rolling cipher, YT does not restrict access to the the download URL. It simply changes the URL periodically. The rolling cipher is thus not an effective access control. For example, when Google promises YT account holders Google can prevent users in a certain geographic region from accessing a video, does Google use a rolling cipher in the Javascript player as the access control.

I disagree with this part. As much as I don't like it, I can't find any way that the rolling cipher is not "effective access control". I linked the definition above, but to the layman (and these laws were written by laymen, so you do have to bear in mind their intent) periodically changing the download URL is an effective access control because they can't bookmark it and go back to it later. We can argue that using the Developer Tools is "in the normal course of operation", but I think you're extremely unlikely to get a judge to agree that opening the Developer Tools is "in the normal course of operation". It's normal to us, but it is not normal for the US as a whole.

In short, I think anything that you can't bookmark a download for probably counts as "effectively controls access". I'm sure other industries feel the same way; oil execs say what they're doing is slightly different than what the law stipulates, doctors says what they did doesn't exactly match up with what malpractice law requires, etc. The only person who's opinion matters is the judge, and they probably aren't an expert.

As an overall summary, I think we're more likely to succeed by poking holes in the RIAA's case. Youtube-DL is under no legal obligation to prove anything; the RIAA as the plaintiff is responsible for proving all of the facts they assert. As long as we try to combat that with our own assertions, they can simply try to poke holes in those. It seems much more difficult to prove that youtube-dl's usage is legitimate than it is to poke holes in one of the assumptions underlying the RIAA's lawsuit. If this is legitimate use, youtube-dl wins. If this is not circumvention, but an alternate access mechanism, youtube-dl wins. If you can prove that rolling ciphers are not an effective control measure, youtube-dl wins. I think the most likely of those options is demonstrating that youtube-dl is fair use (I wonder if there are any accessibility reasons to use youtube-dl; that would hamstring the RIAA, as they'd be caught between the ADA and the DMCA. They either have a valid DMCA complaint but YouTube is liable under DMCA, or they don't have a valid complaint because youtube-dl is required to meet ADA specifications). I don't even have to think very hard to come up with a few non-infringing reasons why someone would use youtube-dl. The RIAA then has to prove that youtube-dl is "primarily designed ... for the purpose of circumventing a technological measure", rather than for the variety of non-infringing reasons one might use youtube-dl.

May I introduce you to GitTorrent?

https://github.com/cjb/GitTorrent

Rather than getting mad at companies for complying with the law of the country they operate in, why not support organizations like EFF that are actively working to change the DMCA?

https://www.eff.org/issues/dmca

However German laws are essentially: "Once you are notified of copyright infringing/illegal content, you have to remove it, lest you lose your protection as a service provider and become responsible for the content."

A DMCA takedown notice would be such a notification.

On the upside you don't need to do anything if you don't have reason to believe the content is illegal in any way (unlike with DMCAs where you pretty much always have to remove first).

On the downside it's a bit easier to get into trouble as a provider if you chose to let something stay online.

I would no longer expect FDroid now to keep doing this if they risk a DCMA letter that takes out their entire repo.

And I would assume a shitton of users use yt-dl code through another GUI application, rather than directly through an EasyInstall/virtualenv/whatever. And will most py repos still dare to host/link this code if the risk is a DMCA letter to their ISP?

A tarball of _ancient_ DeCSS code has some value because you can use it to "decss" _all_ content made _before_ a certain date (e.g. most physical DVDs). So it makes sense to preserve the tarball in any method possible.

A tarball of an _ancient_ youtube-dl version is absolutely useless because the youtube HTML will have changed a million times in the meanwhile. You will not be able to use it for anything, neither for old nor for new content. Publishing/preserving youtube-dl tarballs is an absolute waste of effort.

The RIAA here is targeting existing project developers, and possibly also users. Trying to scare them away. Not trying to censorship old tarballs of the code which will quickly become useless.

The codebase was not the useful thing about this project: it was the constant upkeep and whack-a-mole-ing of the various site changes over the 1000+ supported sites.

This event may spark renewed interest and help, but my money is on "slow death" as support for sites and videos decays.

And even then, where are users going to search the most recent version? You will definitely not preserve the same number of users if you switch from yt-dl being "one apt-get away/one FDroid install away/one pip install away" to "one bittorrent search/wget from shady .ru website". And let's not talk about how will people contribute. The project could be as good as dead.

That way only the fork get periodically DMCA'd, which will be way easier to recover from : just create another fork with the tests

The RIAA generally doesn't have any involvement in video games, other than where its members license music to games (i.e., GTA), and they generally wouldn't have any grounds for being part of the proceedings you've described if their involvement was just the music licensing.

I can see the ESA being a huge dick in these proceedings, because it's their job to do that, but the RIAA literally wouldn't care as long as somebody paid the music licensing fee (for that low volume of users the licensing fee would generally be less than $100 annually, all inclusive).

I've been on the other side of an RIAA negotiation, and they were very easy to work with. We theoretically owed them millions of dollars for several years of unlicensed music streaming, and they waived the statutory penalties they were legally entitled to in exchange for us agreeing to pay a few hundred dollars of royalties a year to stream their members' music. All told, we paid less than $2500/year for streaming licenses for all of the Big 3 labels and a dozen or more smaller labels.

You can look up how much the RIAA and MPAA spent on campaign contributions. It wasn't a billion dollars.

And "campaign contributions" are only one path to victory. You could also go the route of getting Wikipedia et al to do what they did for SOPA.

In a few years it'll be normal for new developers to view a software project and a GitHub project as the same thing because the entire process from creating the project to publishing it (on Azure most likely) will happen via GitHub.

Saying that no one is dependent on GitHub is like saying a mechanic isn't dependent on their tools. Moving away from GitHub is like a mechanic walking out of the garage with a single crescent wrench (the git repo). Then you find out no one else sells any of the tools you know how to use and that the only option is to rent them from someone else (Atlassian or GitLab).

...which many entities would love to do. If it were illegal to extract data any way but through an official API, with a TOS and fees and everything, that would make a bunch of dying business models so much more viable.

You really can't.

>> I've found a way to download videos right from the domain googlevideo.com

I assure you, you really didn't.

Just remove the range parameter in the URL.

Has this been substantiated?

Or do you have a competing tool? Let me guess. Someone will ask for an alternative and another will suggest..

However, at the time it was theorized that in the event the maintainers had found a fundamental flaw, disclosing that flaw by issuing a patch would immediately jeopardize all preexisting truecrypt containers by revealing a method for breaking them. That would be untenable, and so the only alternative would be to shut down the entire project and recommend no further use of the software - as was done.

A subsequent audit did not identify any such security flaw, so the prevailing theory is now that the maintainers were forced to stop work by a governmental agency. It's considered safe and now known as veracrypt.

However, the question I have is whether a single crowdsourced security audit would be capable of finding a flaw that it took the developers themselves years (decades?) to identify.

> Using TrueCrypt is not secure as it may contain unfixed security issues.

Not Secure As. Whether this holds any weight, only the maintainers would know.

More info: https://grahamcluley.com/truecrypt-hidden-message/

It's mostly because I remember filesystems from my university time and trying to implement one in a file myself. Continuously adding data is fine, but when you remove data either you leave a "hole" in the file and have to keep track of the "empty" blocks, or you shift everything to fill the hole. Off-by-one errors corrupt files.

Those are all resolved problems for filesystems, but additionally, I learned the hard way (performance) that SQLite wasn't good as a production db. The situation here is different of course (db access isn't very frequent), but I can't quite shake it.

Maybe I'll dig into the internals to understand what kind of optimisations they made. The wiki and bug-tracking are definitely a plus though.

Its long been known that the way to defeat piracy is to offer a better service. Its what Steam did, its what Netflix did.

Ironically, the fragmentation of those ecosystems is bringing it back. Piracy is the ultimate invisible hand on the entertainment distribution industry.

Ironically, by using youtube-dl en masse to "stick it to the RIAA" they may have inadvertently dug its grave instead.

Reminds me of What color are your bits: https://ansuz.sooke.bc.ca/entry/23.

In this case, I would not be surprised if Google was ultimately driving the push to get rid of youtube-dl using the RIAA as a proxy, both for PR purposes and because the RIAA has a semi-plausible claim to legal standing.

Youtube has ramped up its consumer abuse policies lately, such as the begging screen that demands unauthenticated users log in and requires four clicks to dismiss, and it would not be even remotely surprising if Google is also working to get rid of tools that allow people to watch YouTube videos without being subjected to advertising abuse.

From a strictly code based POV, it is intended to download protected objects with tests to ensure that protections are circumvented and the correct material can be retrieved. At the same time, removal of this code probably disables downloading of the majority of YouTube, and on top of that if there is no official collaboration on it, it'll be outdated within days.

Friedman would certainly be removed by Microsoft if he jeopardized GitHub's legal protections by defying the mandated process, to say nothing of the potential of creating personal legal liability, both criminal and civil.

youtube-dl remains freely available off-GitHub (not to mention on the local disk of anyone who ran `git clone`). I just used it 10 minutes ago. There is no public good served by defying the law here, and there is no reason to put the whole kit and kaboodle on the line over it.

tl;dr, ignoring the DMCA process isn't just a "somewhat risky move". If we're going to break out the pitchforks, let's at least point them in the right direction: write your Congresscritters and tell them you want to see copyright law reform.

It OBVIOUSLY reasonable to have three private corporations owning the majority of modern musical output... and they even have a little club where they discuss pricing! How quaint...

The outrageous thing is why the fuck we as a society defend these corporations, when they have a literal monopoly on what they’re selling, and the monopoly is guaranteed by the government of every western country

My point was someone needs to basically rebuild the tool as a completely seperate repo. Breaking DRM is a really bad idea