Live data from Hacker News

YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

twitter.com

71–80 of 166 posts

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#71

Earlier quoted context omitted.

> I believe YouTube limits your bitrate if you don't pass a specific calculated value It's starting to become Widevine bullshit all over again.

It's their platform. They can do with it what they want.

They've also chosen to be a monopoly.

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#72
post #42

This isn't really JS, it's a purpose built evaluator that's only for evaluating a particular script on YouTube, assuming a huge list of things are true about how YouTube JS is written. Ex. Its got a hard coded list of methods for String, and it doesn't respect prototypes. It only supports creating Date instances, and won't work if you override the global Date. It parses with regexes and implements all operators with…

Ok, we've changed this title to shrink the scope of the interpreter.

Submitted title was "YouTube-dl has a JavaScript interpreter written in 870 lines of Python".

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#73

Earlier quoted context omitted.

I'm trying to get the thread model here. Is the concern that Youtube will inject JS into the payload which tries to break out of the youtuble-dl js sandbox using some zero day in whatever js engine they would use instead?

Embedding a whole js engine and then interopping with it from python would be non trivial. Good luck fixing any bugs or corner cases you hit that way. The V8 and spidermonkey embedding apis are both c++ (iirc) and non trivial to use correctly. Having full control like this +simple code is probably lower risk and more maintainable, even if there's the challenge of expanding feature set if scripts change. The alternati…

Fwiw there are python bindings for QuickJS and Duktape:

https://github.com/PetterS/quickjs

https://github.com/stefano/pyduktape

https://github.com/amol-/dukpy

I can't speak to the quality of those bindings, but they do seem maintained.

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#74
I do wonder why YouTube does not try harder to make it difficult to do this computation meant to prove you are a legit YouTube web client. Providing an easy-to-find, simple JS function interpretable with 900 lines of Python is like they don't try at all. They might as well do nothing.

Or is their goal just to make youtube-dl not 100% reliable? Or to be able to say "look, you are running our code in a way we did not intend, you can't do this because you are breaking the EULA"?

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#75

Earlier quoted context omitted.

I'm trying to get the thread model here. Is the concern that Youtube will inject JS into the payload which tries to break out of the youtuble-dl js sandbox using some zero day in whatever js engine they would use instead?

Embedding a whole js engine and then interopping with it from python would be non trivial. Good luck fixing any bugs or corner cases you hit that way. The V8 and spidermonkey embedding apis are both c++ (iirc) and non trivial to use correctly. Having full control like this +simple code is probably lower risk and more maintainable, even if there's the challenge of expanding feature set if scripts change. The alternati…

apparently yt-dlp is somehow calling out to a js engine if available

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#76
post #36

Earlier quoted context omitted.

Quoted post unavailable.

> you also think billionares should be taxed more That's... quite a response in defense of a tool intended for breaching TOS and performing copyright infringement. Can you clarify exactly who it is and isn't OK to steal from, again? I'm struggling here.

> As a matter of policy (as well as legality), youtube-dl does not include support for services that specialize in infringing copyright. As a rule of thumb, if you cannot easily find a video that the service is quite obviously allowed to distribute (i.e. that has been uploaded by the creator, the creator's distributor, or is published under a free license), the service is probably unfit for inclusion to youtube-dl.

Does using a different User Agent instead of a typical browser amount to copyright infringement in any jurisdiction?

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#77
post #74

I do wonder why YouTube does not try harder to make it difficult to do this computation meant to prove you are a legit YouTube web client. Providing an easy-to-find, simple JS function interpretable with 900 lines of Python is like they don't try at all. They might as well do nothing. Or is their goal just to make youtube-dl not 100% reliable? Or to be able to say "look, you are running our code in a way we did not i…

They do make it harder from time to time. In fact yt-dlp's interpreter has been broken for a month or so now and the devs finally gave up and told users to just install PhantomJS (which itself hasn't been updated since 2016 and probably has bugs / vulns of its own, but whatever).

https://github.com/yt-dlp/yt-dlp/issues/4635#issuecomment-12...

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#79

Earlier quoted context omitted.

It's their platform. They can do with it what they want.

Many channels would be more than happy to enable download options, if possible. Hell, how is Creative Commons licence they totally give you option to select, work in case of videos that can't be downloaded in any way?

But would the channel owner be happy to enable download options if $0.09 per GB downloaded was subtracted from their ad revenue?

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#80
post #7
post #2

What purpose does it serve?

I'd have to read up on the specifics as well, but I think basically Youtube uses a lot of obfuscated, rapidly and automatically changing Javascript code to fetch the video data. A project like youtube-dl has to run this code to be able to download videos, because that's what's happening in the browser as well.

If you start a youtube video and then pause it and resume a few days later, you'll notice that the youtube page plays for ~30 seconds (ie. whats buffered) and then the page refreshes. I'd guess this refresh is to pick up the new javascript and any updates to the HTML code.

It's kinda annoying if you have a lot of youtube tabs open for a long time and come back to them.

Post reply on HN