It doesn't work like that since certain videos use obfuscation methods that random cat videos don't.

I was under the impression that those obfuscation methods were exclusive to certain YouTube partners, including the RIAA members. If youtube-dl stopped supporting that method, it would still be a useful tool for the bulk of its use cases and the RIAA would no longer have any leg to stand on since it'd no longer be able to download their members' videos.

There's no need to keep that code in the main yt-dl codebase if it is for special cases.

You could imagine a siloed yt-dl plugin called crack-riaa with separate tests, hosting, etc.

If yt-dl detects the obfuscation, it could fail with an error message point to the plugin's documentation.

That would only move the problem. That plugin would still need a Git repository, an issue tracker, tests, and an update mechanism. Or are you trying to say you don't care if this specific part of yt-dl gets deleted from the internet by RIAA?

It decouples the thorny part of yt-dl from the mainline and reduces risk of complaints in the future.

I do care if this part gets deleted, that's why I think it should be hosted somewhere more reliable than GitHub. There are other options which aren't as polished, but may be better for hosting risky code like this, including self hosting.

This code needs to be underground.

In my experience many videos have it, not necessarily ones associated with the RIAA (or perhaps the overzealous[1] content detector just thinks there's some of their content in there), so it's definitely necessary to decode the algorithm for youtube-dl to work on not just RIAA content videos.

IMHO giving the client both the key and the algorithm to decode the content should not count as any form of protection, but the lawyers don't care...

[1] https://news.ycombinator.com/item?id=16075325

Breaking copy protection is only illegal if you do not have a license to the work. Removing the protection breaking code isn't necessary, and everyone needs to stop pretending that it is.

This same clause of the DMCA is the suspected reason for py-kms's reinstatement after a takedown: it's perfectly legal to break the Windows license scheme if you already own a license to Windows.

Since this affects only tests, they could easily change the relevant scripts to download a list of test videos at runtime. I bet the RIAA github-scrapers would not "see" it. Just serve statically a rot13-encoded list of URLs from pastebin or something, and Bob's your uncle.

Based on what I saw in past discussions, I'm pretty sure that the takedown was not a run-of-the-mill scraper-based takedown (it makes no sense to be taken down just for linking to videos which, at best, is what any scrapers would have seen in the original test code). It was very much an intentional, manual one with actual lawyers behind it.

There are multiple sides to "defending" a project like this. One of them is avoiding to trip the run-of-the-mill scrapers. The takedown was serious but we don't know what triggered the lawyers' attention in the first place. IMHO a simple runtime obfuscation would remove that particular attack vector, once coupled with some plausible deniability (i.e. deleting all downloaded data once tested). At that point, YTDL is still on RIAA's generic shitlist (which will require other mitigations to survive) but at least doesn't get flagged every week by a scraper.

I suppose a developer that wants to make sure that it works with certain DRM schemes can add cases of their own, locally, without pushing the change.

feel free to file an issue and tell them that, but clearly it does work in this case.