In a free market it is important that when you are displeased with a supplier that you truthfully tell that supplier why you are displeased (ideally very vocally) and are actively considering alternatives. It is one of the few early-warning signals that might change their behaviour.
But ideally, just stop giving them money immediately and tell them, but mention that you are willing to change your mind if they change their behaviour. And if they vascillate too often between what is right and what is profitable, inform the entire system even if it is a great personal expense. As long as it benefits the system, you will come out okay in the end.
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?
May I introduce you to GitTorrent?
Also relevant if you go the p2p route:
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".
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
Thus, for most videos, there is no need to circumvent any technological measure, e.g., a so-called "rolling cipher" for the video signature. Section 1201, specifically referenced in RIAA's letter, requires that the circumvention software be "primarily" designed for circumvention. It's arguable youtube-dl is not primarily designed for downloading the minority of YT videos that use the rolling cipher, or whatever "protection" Google may choose to offer the minority of YT accounts that want to use YT as a distribution channel for commercial content, e.g., VEVO.
With the rolling cipher, Google tries to ensure all HTTP requests sent by the user are made via its own Javascript player. However this still does not stop anyone using a popular browser with Developer Tools or the equivalent (such as Microsoft's own Edge browser) from obtaining the download URL and using any TCP client the user chooses to perform the download. Nor does it stop any user from observing the download URL via other means, e.g., users observing the TCP traffic entering their personal networks.
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.
The point of the rolling cipher is that you can't access the video without running their JS. youtube-dl did exactly that, just as any user agent would.
Not sure about that. The RIAA approach over the last few years doesn't seem very well researched or well thought out. They seem to more go after "targets of opportunity" + add in coercion wherever possible.
That's just my impression anyway.
This issue is silly to me because the YT videos I am interested almost never use the rolling cipher. I cannot be the only one. If the user is someone who wants to consume commercial content from VEVO and the like via YT, surely she is also content to do so using Google's Javascript player and submitting herself to ads and tracking that web browsers enable.
IMO, there is more to YT than what the RIAA's members contribute.
Now, if they had designed a system where the key could only be operated once/for a given timeframe from a specific left hand glove, then the intent would be clear (IOW DRM container like widevine or fairplay). But the intent of making it from cumbersome to impossible for right handed, broken armed, or disabled people, or just missed the bus and being late, to use the key would be very clear also.
What’s clear to me from this overall SNAFU is that they’re after the eyeballs. The content only matters as an eyeball attractor.
I’m wondering if in the EU youtube-dl could fall under protection for interoperability.
You can see the Mona Lisa but you cannot take a photo of the Mona Lisa without previous consent of the Louvre.
You can, they just ask you to responsibly not use a flash.
https://c8.alamy.com/comp/F0948J/tourists-photographing-mona...
This specific painting is public domain, you could copy it to your heart’s content.
> I think a better analogy is: Handing someone a key to unlock a door to watch an artwork and then taking the (a copy of, a photo of) artwork with you.
I kinda get your point, but it’s completely non obvious that the key from YouTube has any sort of such value: it’s just a string of chars, it could just as well be some homegrown encoding, tracking system, or error check+. A ticket has clear information about its validity in space and time. I’d argue that the alleged protection is so lousy as such that it could very well be dismissed as being one, whereas a ticket+museum or video+drm you cannot get the content out of the container, at least not easily so, and it’s very obvious that it’s there to prevent that, with enforcement of metadata on the key (e.g cert/key with time, device or account id, pubkey signature, ...)
I seem to recall a legal provision (might be DMCA even) that says if the protection scheme comes to be trivially bypassed then the circumvention clause doesn’t hold water, in essence codifying protection obsolescence and making e.g DeCSS ultimately legal, but I can’t find the reference to that.
+ I’d argue it’s actually more akin to the second one.
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.
2017: https://tyrrrz.me/blog/reverse-engineering-youtube
2015: https://github.com/bitnol/CipherAPI
2014: https://gist.github.com/kl/9070523
2014: https://api.w3hills.com/ytcipher
Regarding the "bookmark" comment, there is no way to "bookmark" any YT download URL because all YT download URLs (not just ones that have a changing signature) include timestamps; as is typical of download URLs on video sites, they have an expiration. Generating URLs that expire is not done as a means of copyright-related "access control"; the purpose has to do with caching.
RIAA depends on it being debateble. Debatable means you get to spend hundreds of thousands of dollars arguing over it in court. Sine the RIAA’s members business model depends on it, they are willing to spend whatever it takes. No one else is.
This isn't all that different from the fact that sites which prominently support free speech attract all the extremists, because that's the only place they have.
Did it though? Sure, the Streisand effect caused more distribution of youtube-dl, but that's never really been an issue. Open source software as widely used as youtube-dl is mirrored in a hundred different places.
The issue here is what does future development of youtube-dl look like? It sounds like the rolling cipher stuff is going to have to go if development is to remain on Github, and that's a win for RIAA.