Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

IME, most YouTube videos do not use any technological measure to prevent using any TCP client, not simply Google's Javascript player compbined with a web browser, to download the video. Moreover I have observed that for most YT videos Google's player uses "progressive download", i.e., a number of successive HTTP requests with incremented Range headers, not "streaming".

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.



I believe a court in Germany has already ruled on the rolling cipher being a technological restriction (and that is referenced in the complaint). The point of the technological measure (together with TOS) is to make the intent clear. youtube-dl could probably have been fine without implementing the cipher decryption function but since it did and had a test suite to check and flag if it doesn't work, it made itself a target.


Any standard user agent would "circumvent" the "protection" in exactly the same manner. If Firefox used that page as a test case for its JS engine, would that make it primarily designed for circumvention?

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.


Well if it actually went to a court case, I'm sure either RIAA's lawyers or the defence lawyers would subpoena Google to disclose the split of downloaded videos between protected and not protected videos and then we'd actually know. It is likely RIAA would have already done some sense check of usage already using metered PC panels before even stirring up this particular hornets nest.


> It is likely RIAA would have already done some sense check of usage already using metered PC panels ...

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.


Agree with 2nd sentence.

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.


I’m failing to see how handing a key to someone along with the address to the door it unlocks communicates any intent about that someone to unlock the door with his left hand only, and never with his right one.

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.


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.

You can see the Mona Lisa but you cannot take a photo of the Mona Lisa without previous consent of the Louvre.


> 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.


> 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.

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.


Inside the source of the Javascript player (base.js) was a function to transform (update) the value of the video signature (s) parameter. All you had to do was look at base.js and duplicate the string operations used to produce the updated s, whatever they were. No need to use Javascript. yt-dl chose to use Python. Only a minority of videos used this "technological measure". Most videos on YT do not require a continually updated s; the value of s stays the same.

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.


> I still think it's debatable

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: